Cookies - Revision history

Tom: /* Security */

2025-09-28T21:40:05Z

‎Security

Tom: /* Third Party Cookies */

2025-01-12T22:21:11Z

‎Third Party Cookies

Tom: /* Security */

2024-02-24T20:06:12Z

‎Security

Tom at 18:00, 27 April 2023

2023-04-27T18:00:05Z

Tom: /* References */

2023-02-23T01:25:16Z

‎References

Tom: /* Cookies Having Independent Partitioned State (CHIPS) */

2023-02-23T01:23:25Z

‎Cookies Having Independent Partitioned State (CHIPS)

Tom: /* Notice and Consent */

2022-07-25T03:10:50Z

‎Notice and Consent

Tom: /* Notice and Consent */

2022-07-25T03:06:02Z

‎Notice and Consent

Tom: /* Notice and Consent */

2022-07-25T02:49:43Z

‎Notice and Consent

Tom: /* Notice and Consent */

2022-07-25T02:49:11Z

‎Notice and Consent

← Older revision		Revision as of 21:40, 28 September 2025
Line 34:		Line 34:

	The web deployments need to handle large numbers of requests, potentially with different end-points. Strong context session cookies need good protection, possibly with encryption.		The web deployments need to handle large numbers of requests, potentially with different end-points. Strong context session cookies need good protection, possibly with encryption.
		+
		+	Starting in 2025 the W3C is seeking to replace cookies with [[Session\|Device Bound Credentials]].

	===Privacy===		===Privacy===

@@ Line 14: / Line 14: @@
     A transaction is verifiable if the user has the option to review the request-URI prior to its use in the transaction.
     A transaction is unverifiable if the user does not have that option.
-    Unverifiable transactions typically arise when a user agent automatically requests in-lined or embedded entities or when it resolves redirection (3xx) responses from an origin server.  Typically the origin transaction, the transaction
+    Unverifiable transactions typically arise when a user agent automatically requests in-lined or embedded entities or when it resolves redirection (3xx) responses from an origin server.  Typically the origin transaction, the transaction that the user initiates, is verifiable, and that transaction may directly or indirectly induce the user agent to make unverifiable transactions.
 ===History===

← Older revision		Revision as of 20:06, 24 February 2024
Line 34:		Line 34:

	A large amount of effort has been expended to block vulnerabilities, like cross-site scripting attacks, that could have been avoided by blocking third party cookies. The monetary benefit of advertising, and user unwillingness to directly pay for the content that they consume has resulted in the current payment structure for the internet. It is not likely that attempts to block third party cookies will make any headway until some other payment mechanism is created. It was true when the browser wars we fought that users paid nothing for the browser while the web servers was expensive and quite profitable. It does not seem that anything has changed with that imbalance in the intervening years. If anything the market value of the user device software has continued to erode while the advertising revenue continues to climb.		A large amount of effort has been expended to block vulnerabilities, like cross-site scripting attacks, that could have been avoided by blocking third party cookies. The monetary benefit of advertising, and user unwillingness to directly pay for the content that they consume has resulted in the current payment structure for the internet. It is not likely that attempts to block third party cookies will make any headway until some other payment mechanism is created. It was true when the browser wars we fought that users paid nothing for the browser while the web servers was expensive and quite profitable. It does not seem that anything has changed with that imbalance in the intervening years. If anything the market value of the user device software has continued to erode while the advertising revenue continues to climb.
		+
		+	The web deployments need to handle large numbers of requests, potentially with different end-points. Strong context session cookies need good protection, possibly with encryption.

	===Privacy===		===Privacy===

@@ Line 1: / Line 1: @@
 =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. See the page [[User Object]] to see the relationship between the various instantiations of [[User Information]] during even a single transaction with a [[user Agent]].
+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. See the page [[User Object]] to see the relationship between the various instantiations of [[User Information]] during even a single transaction with a [[user Agent]].
-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.
+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).
+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).
 But as we will see below, third party cookies have other security vulnerabilities that are potentially more severe.
@@ Line 14: / Line 14: @@
     A transaction is verifiable if the user has the option to review the request-URI prior to its use in the transaction.
     A transaction is unverifiable if the user does not have that option.
-    Unverifiable transactions typically arise when a user agent automatically requests
+    Unverifiable transactions typically arise when a user agent automatically requests in-lined or embedded entities or when it resolves redirection (3xx) responses from an origin server.  Typically the origin transaction, the transaction
     that the user initiates, is verifiable, and that transaction may
     directly or indirectly induce the user agent to make unverifiable transactions.
 ===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 flexible and the most reliable. David Kristal at Bell Labs started the standardization process in April 1995
+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 flexible and the most reliable. David Kristal at Bell Labs started the standardization process in April 1995
 <ref name="kristol">David Kristol; ''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 2109 "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 and it remains as a listed standard in May 2018.
@@ Line 40: / Line 38: @@
 Recall that the original Warren and Brandeis definition of [https://en.wikipedia.org/wiki/The_Right_to_Privacy_(article) 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.
+One of the things that [[Web Site]]s are permitted to do by the HTTP protocol 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 2109 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 [http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/ 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.
+The RFC 2109 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 [http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/ 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 Site]]s can get from hosting advertisements that are sold to the highest bidder, it is just too profitable to host them.
 ===Notice and Consent===
-Since the EU started their ill-considered attempt at controlling tracking with symptomatic relief by controlling cookies, industry has responded with a variety of attempts at meeting the law on symptoms (cookies). Here is one honest example (except that it does not say if data will be shared). I doubt that many users bother to select "Cookie Preferences". <blockquote>Privacy - Cookie Preferences - Terms of Use - This site uses cookies. When you visit our website, we may store cookies on your browser to collect information about you, your device, and your browsing behaviors. Some of these cookies and the information we collect are necessary for our site to work as you would expect. Other cookies, however, are used to collect information that may support our business's marketing campaigns, ad targeting efforts, and ***.com site analytics. Visit the "Cookie Preference Center" to manage your choices. For additional information, you may also review our Privacy Notice.</blockquote>
+Since the EU started their ill-considered attempt at controlling tracking with symptomatic relief by controlling cookies, industry has responded with a variety of attempts at meeting the law on symptoms (cookies). Here is one honest example (except that it does not say if data will be shared). I doubt that many users bother to select "Cookie Preferences". <blockquote>Privacy - Cookie Preferences - Terms of Use - This site uses cookies. When you visit our [[Web Site]], we may store cookies on your browser to collect information about you, your device, and your browsing behaviors. Some of these cookies and the information we collect are necessary for our site to work as you would expect. Other cookies, however, are used to collect information that may support our business's marketing campaigns, ad targeting efforts, and ***.com site analytics. Visit the "Cookie Preference Center" to manage your choices. For additional information, you may also review our Privacy Notice.</blockquote>
 *    Followed by:
 ** button{Cookie Preferences}
@@ Line 67: / Line 65: @@
 ==Solutions==
-Even though this page is written about cookies, it should be clear that cookies function as state variables which is their raison d'etre. Given the [https://en.wikipedia.org/wiki/Representational_state_transfer RESTful] nature of most web sites, maintaining state will continue as their major function. Like any object associated with a user, it will have some sort of identifier that can be used to correlate user behaviors. The solutions range from the original opaque blob whose very existence is unknown to the user, to a highly structured message where the user is expected to understand and act on the information. Before trying to select an appropriate solution, the user needs and expectations should be determined. No evidence has been found that the users' reaction to any of this has been researched. Any information of that sort would be valuable if it can be found or generated.
+Even though this page is written about cookies, it should be clear that cookies function as state variables which is their raison d'etre. Given the [https://en.wikipedia.org/wiki/Representational_state_transfer RESTful] nature of most [[Web Site]]s, maintaining state will continue as their major function. Like any object associated with a user, it will have some sort of identifier that can be used to correlate user behaviors. The solutions range from the original opaque blob whose very existence is unknown to the user, to a highly structured message where the user is expected to understand and act on the information. Before trying to select an appropriate solution, the user needs and expectations should be determined. No evidence has been found that the users' reaction to any of this has been researched. Any information of that sort would be valuable if it can be found or generated.
 * The original RFC 2109 proposed that users be given control of what cookies are stored on their computer. Even though this was never tried by a browser in wide deployment, it is the projected and actual volume of cookies and their opacity to the browser makes that proposal unlikely of success no matter how much work is thrown at it.

← Older revision		Revision as of 01:25, 23 February 2023
Line 132:		Line 132:
	@Adam: Yes, if you're going by the Netscape spec or RFC 6265, whitespace is not permitted in a raw (un-DQUOTEd) cookie value. It does nonetheless work in browsers I've tried, but I wouldn't rely on it. – bobince Feb 8 '13 at 11:29		@Adam: Yes, if you're going by the Netscape spec or RFC 6265, whitespace is not permitted in a raw (un-DQUOTEd) cookie value. It does nonetheless work in browsers I've tried, but I wouldn't rely on it. – bobince Feb 8 '13 at 11:29

−	[[Category:Glossary]]	+	[[Category: Glossary]]
		+	[[Category: Browser]]

@@ Line 57: / Line 57: @@
 ===Cookies Having Independent Partitioned State (CHIPS)===
 Spec (Copied from I2E) https://github.com/WICG/CHIPS  (proposed 2022-07)
 Summary (Copied from I2E) = Given that Chrome plans on obsoleting unpartitioned third-party cookies, we want to give developers the ability to use cookies in cross-site contexts that are partitioned by top-level site (or First-Party Set, where the site uses that feature) to meet use cases that are not cross-site tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). In order to do so, we introduce a mechanism to opt-in to having their third-party cookies partitioned by top-level site using a new cookie attribute, Partitioned.
 ==Solutions==

← Older revision		Revision as of 03:10, 25 July 2022
Line 50:		Line 50:

	A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster'' '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution in 2022 resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.		A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster'' '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution in 2022 resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.
		+
		+	https://www.thedrum.com/news/2021/11/17/half-us-consumers-accept-all-cookies-despite-concerns-about-how-their-data-shared
		+	Data privacy is on the minds of the tech companies, lawmakers and marketers alike. But is it on the minds of the general consumer? And what are they doing about it? A new poll of 1,000 US consumers conducted by YouGov in conjunction with The Drum answers those questions.
		+	* my comment
		+	The way that cookie permissions were handled by the EU is an object lesson on how NOT to legislate privacy. Asking users for consent needs to be carefully calibrated to their tolerance for interruptions.

	===Cookies Having Independent Partitioned State (CHIPS)===		===Cookies Having Independent Partitioned State (CHIPS)===

← Older revision		Revision as of 03:06, 25 July 2022
Line 50:		Line 50:

	A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster'' '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution in 2022 resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.		A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster'' '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution in 2022 resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.
		+
		+	===Cookies Having Independent Partitioned State (CHIPS)===
		+
		+	Spec (Copied from I2E) https://github.com/WICG/CHIPS (proposed 2022-07)
		+
		+	Summary (Copied from I2E) = Given that Chrome plans on obsoleting unpartitioned third-party cookies, we want to give developers the ability to use cookies in cross-site contexts that are partitioned by top-level site (or First-Party Set, where the site uses that feature) to meet use cases that are not cross-site tracking related (e.g. SaaS embeds, headless CMS, sandbox domains, etc.). In order to do so, we introduce a mechanism to opt-in to having their third-party cookies partitioned by top-level site using a new cookie attribute, Partitioned.

	==Solutions==		==Solutions==

@@ Line 49: / Line 49: @@
 ** button{Accept Cookies}
-A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster''  '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.
+A comprehensive review of the contribution of the Cookie Monster to Privacy<ref>Laurie Faith Cranor, ''Privacy - Cookie Monster''  '''ACM 65''' No 7 (2-22-07)pp. 30-32</ref> showed that almost no existing solution in 2022 resulted in the user have any meaningful choice, where meaningful means that the user was given a choice that would allow them to make a decision that they understood the meaning of each option displayed.
 ==Solutions==