Difference between revisions of "Cookies"

From MgmtWiki
Jump to: navigation, search
(Privacy)
(History)
Line 9: Line 9:
  
 
===History===
 
===History===
Starting from the entry on [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie in Wikipedia] we find that Lou Montulli of Netscape ported cookies from Unix to the Mosaic browser to enable an e-commerce application that was requested by Vint Cert, inter alia in 1994. The point was to save state on the client computer rather in the browser. While this was not the only solution to create session state between the user (as a client) and the web site (as a server), it proved to be the most flexible. David Kristal at Bell Labs started the standardization process in April 1995<ref name="kristol">Kristol, David; ''HTTP Cookies: Standards, privacy, and politics'', ACM Transactions on Internet Technology, 1(2), 151–198, 2001 [https://arxiv.org/abs/cs.SE/0105018 arXiv:cs/0105018v1 [cs.SE&#93;])</ref>, the same time Netscape applied for a patent. The IETF issued RFC 2106 in February 1997. By then advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000.
+
Starting from the entry on [https://en.wikipedia.org/wiki/HTTP_cookie HTTP Cookie in Wikipedia] we find that Lou Montulli of Netscape ported cookies from Unix to the Mosaic browser to enable an e-commerce application that was requested by Vint Cert, inter alia in 1994. The point was to save state on the client computer rather in the browser. While this was not the only solution to create session state between the user (as a client) and the web site (as a server), it proved to be the most flexible. David Kristal at Bell Labs started the standardization process in April 1995<ref name="kristol">Kristol, David; ''HTTP Cookies: Standards, privacy, and politics'', ACM Transactions on Internet Technology, 1(2), 151–198, 2001 [https://arxiv.org/abs/cs.SE/0105018 arXiv:cs/0105018v1 [cs.SE&#93;])</ref>, the same time Netscape applied for a patent. The IETF issued RFC 2106 "HTTP State Management Mechanism" in February 1997. By then advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000.
  
 
RFC 2965 added a <code>Set-Cookie2</code> header, which informally came to be called "RFC 2965-style cookies" as opposed to the original <code>Set-Cookie</code> header which was called "Netscape-style cookies".<ref>{{cite web |url=https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |title=Setting Cookies |date=June 19, 2009 |website=staff.washington.edu}}</ref><ref>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] further to RFC 2965's deprecation.</ref> <code>Set-Cookie2</code> was seldom used however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world.<ref name="HTTPStateMgmtToPS">{{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|accessdate=17 June 2016|date=6 March 2011}}</ref>
 
RFC 2965 added a <code>Set-Cookie2</code> header, which informally came to be called "RFC 2965-style cookies" as opposed to the original <code>Set-Cookie</code> header which was called "Netscape-style cookies".<ref>{{cite web |url=https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |title=Setting Cookies |date=June 19, 2009 |website=staff.washington.edu}}</ref><ref>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] further to RFC 2965's deprecation.</ref> <code>Set-Cookie2</code> was seldom used however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world.<ref name="HTTPStateMgmtToPS">{{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|accessdate=17 June 2016|date=6 March 2011}}</ref>

Revision as of 11:04, 30 May 2018

Full Title and Meme

Cookies are chunks of data that are placed in a user agent (typically a browser) that allow a web site to maintain context of user experience, more commonalty called state data.

The problem is the capability to track the user that cookies give to the web site, or a widget hosted on the web site. This capability has been targeted by privacy regulations that are not effective.

Context

Cookies have been targeted as evil primarily due to tracking of the user (the second party) by the web site (the first party) and by other widgets hosted by the web page (the third party).

History

Starting from the entry on HTTP Cookie in Wikipedia we find that Lou Montulli of Netscape ported cookies from Unix to the Mosaic browser to enable an e-commerce application that was requested by Vint Cert, inter alia in 1994. The point was to save state on the client computer rather in the browser. While this was not the only solution to create session state between the user (as a client) and the web site (as a server), it proved to be the most flexible. David Kristal at Bell Labs started the standardization process in April 1995[1], the same time Netscape applied for a patent. The IETF issued RFC 2106 "HTTP State Management Mechanism" in February 1997. By then advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000.

RFC 2965 added a Set-Cookie2 header, which informally came to be called "RFC 2965-style cookies" as opposed to the original Set-Cookie header which was called "Netscape-style cookies".[2][3] Set-Cookie2 was seldom used however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world.[4]

Problems

Security

The first of the Laws of Security says that if an attacker can run code on your computer, it is not just your computer any longer. Ever since JavaScript became necessary to render most web pages, the page that you see on your browser is almost certainly running code that is not under your control. If it's not your computer, an attacker can do anything that the code allows it to do, including just hijacking the computer power for its own purposes. In particular it can save cookies and communicate with any site on the web that is not blocked by a firewall.

Privacy

Recall that the original Warren and Brandeis definition of the right to privacy was the right to be let alone. In the web that would mean the right not to be tracked.

One of the things that web sites are permitted to do by the HTTP protoocol is store cookies within your browser that are normally returned to the origin web site whenever the user sends any request or posts any data to that site. The RFC 2106 recommends that users be aware of the data stored on the user's computer and be given the power to accept or reject that action. Technically this is true of modern browsers, but as a practical matter normal users are not expected to know how to find the controls for the cookie, and certainly not the cookie itself, which is stored in hidden folders and is typically encrypted and at least encoded in non legible format. In the case of first party cookies it can be argued that the user consented to the user experience of the origin site which includes cookies. In the case of advertisement space sold to the highest bidder, neither the user nor the web site has any knowledge of the identity of the code that is running in the iFrame hosting that advertisement. Ad blockers that impact all cookies will likely have adverse impact on the user experience. There is no such justification for code running on the user's computer from some unknown site, especially since the security boundary between an iFrame and the main web page is known to be porous. Blocking cross-site scripting attacks is an art that has been mastered by few web masters. That does not impact the money that web sites can get from hosting advertisements that are sold to the highest bidder, it is just too profitable to host them.

Solutions

References

  1. Kristol, David; HTTP Cookies: Standards, privacy, and politics, ACM Transactions on Internet Technology, 1(2), 151–198, 2001 arXiv:cs/0105018v1 [cs.SE])
  2. {{#invoke:citation/CS1|citation |CitationClass=web }}
  3. 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 later versions of the documentation further to RFC 2965's deprecation.
  4. {{#invoke:citation/CS1|citation |CitationClass=web }}