Content deleted Content added
m Open access bot: doi, hdl added to citation with #oabot. |
Citation bot (talk | contribs) Alter: template type. Add: year, website, s2cid, doi, journal, date, newspaper, authors 1-2. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Whoop whoop pull up | Linked from User:UBX/Userboxes/Wikipedia | #UCB_webform_linked 17/42 |
||
Line 26:
The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence.{{cn|date=October 2022|reason=This is most likely incorrect, as at least Internet Explorer had very prominent cookie warnings and required explicit permission to accept any.}} The public learned about cookies after the ''[[Financial Times]]'' published an article about them on February 12, 1996.<ref name="B3JMd">{{cite news|last=Jackson|first=T|title=This Bug in Your PC is a Smart Cookie|newspaper=Financial Times|date=1996-02-12}}</ref> In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. [[Federal Trade Commission]] hearings in 1996 and 1997.<ref name="UjTred" />
The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk [[electronic mailing list|mailing list]]. A special working group within the [[Internet Engineering Task Force]] (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by [[Brian Behlendorf]] and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default.<ref name="RFC2109">{{Cite
RFC 2965 added a <code>Set-Cookie2</code> [[HTTP header|header field]], which informally came to be called "RFC 2965-style cookies" as opposed to the original <code>Set-Cookie</code> header field which was called "Netscape-style cookies".<ref name="AGgFj">{{cite web |url=https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |title=Setting Cookies |date=June 19, 2009 |website=staff.washington.edu |access-date=March 15, 2017 |archive-url=https://web.archive.org/web/20170316175133/https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |archive-date=March 16, 2017 |url-status=live}}</ref><ref name="V1mES">The edbrowse documentation version 3.5 said "Note that only Netscape-style cookies are supported. However, this is the most common flavor of cookie. It will probably meet your needs." This paragraph was removed in [http://edbrowse.org/usersguide.html#cook later versions of the documentation] {{Webarchive|url=https://web.archive.org/web/20170316024448/http://edbrowse.org/usersguide.html#cook |date=2017-03-16}} further to RFC 2965's deprecation.</ref> <code>Set-Cookie2</code> was seldom used, however, and was [[deprecate]]d in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world.<ref name="StateMgmt">{{cite web|last1=Hodges|first1=Jeff|last2=Corry|first2=Bil|title='HTTP State Management Mechanism' to Proposed Standard|url=http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html|website=The Security Practice|access-date=17 June 2016|date=6 March 2011|archive-url=https://web.archive.org/web/20160807062741/http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html|archive-date=7 August 2016|url-status=live}}</ref> No modern browser recognizes the <code>Set-Cookie2</code> header field.<ref name="TASE4">{{Cite web|title=Set-Cookie2 - HTTP {{!}} MDN|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie2|access-date=2021-03-08|website=developer.mozilla.org}}</ref>
Line 49:
==={{anchor|SameSite cookie}}Same-site cookie===
In 2016 [[Google Chrome]] version 51 introduced<ref name="T8177">{{Cite web|url=https://www.chromestatus.com/feature/4672634709082112|title='SameSite' cookie attribute, Chrome Platform tatus|website=Chromestatus.com|access-date=2016-04-23|archive-url=https://web.archive.org/web/20160509064447/https://www.chromestatus.com/feature/4672634709082112|archive-date=2016-05-09|url-status=live}}</ref> a new kind of cookie with attribute <code>SameSite</code>. The attribute <code>SameSite</code> can have a value of <code>Strict</code>, <code>Lax</code> or <code>None</code>.<ref name="oCqyo">{{Cite journal|url=https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00|title=Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00|last1=Goodwin|last2=West|first1=M.|
The Same-site cookie is incorporated into [https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07 a new RFC draft for "Cookies: HTTP State Management Mechanism"] to update RFC 6265 (if approved).
Line 157:
The <code>Domain</code> and <code>Path</code> attributes define the scope of the cookie. They essentially tell the browser what website the cookie belongs to. For security reasons, cookies can only be set on the current resource's top ___domain and its subdomains, and not for another ___domain and its subdomains. For example, the website <code>example.org</code> cannot set a cookie that has a ___domain of <code>foo.com</code> because this would allow the website <code>example.org</code> to control the cookies of the ___domain <code>foo.com</code>.
If a cookie's <code>Domain</code> and <code>Path</code> attributes are not specified by the server, they default to the ___domain and path of the resource that was requested.<ref name="uMnRY">{{cite
Below is an example of some <code>Set-Cookie</code> header fields in the HTTP response of a website after a user logged in. The HTTP request was sent to a webpage within the <code>docs.foo.com</code> subdomain:
Line 168:
</syntaxhighlight>
The first cookie, <code>LSID</code>, has no <code>Domain</code> attribute, and has a <code>Path</code> attribute set to <code>/accounts</code>. This tells the browser to use the cookie only when requesting pages contained in <code>docs.foo.com/accounts</code> (the ___domain is derived from the request ___domain). The other two cookies, <code>HSID</code> and <code>SSID</code>, would be used when the browser requests any subdomain in <code>.foo.com</code> on any path (for example <code>www.foo.com/bar</code>). The prepending dot is optional in recent standards, but can be added for compatibility with RFC 2109 based implementations.<ref name="gxcF2">{{cite
====Expires and Max-Age====
The <code>Expires</code> attribute defines a specific date and time for when the browser should delete the cookie. The date and time are specified in the form <code>Wdy, DD Mon YYYY HH:MM:SS GMT</code>, or in the form <code>Wdy, DD Mon YY HH:MM:SS GMT</code> for values of YY where YY is greater than or equal to 0 and less than or equal to 69.<ref name="QKuwv">{{cite
Alternatively, the <code>Max-Age</code> attribute can be used to set the cookie's expiration as an interval of seconds in the future, relative to the time the browser received the cookie. Below is an example of three <code>Set-Cookie</code> header fields that were received from a website after a user logged in:
| |||