Cookies Having Independent Partitioned State (CHIPS)

[DCtheTall]

Guten TAG!

I am requesting a review of Cookies Having Independent Partitioned State (a.k.a. CHIPS), a proposal for opt-in cookie jar partitioning by top-level site.

This proposal introduces a new Set-Cookie header attribute, Partitioned, which servers can use to opt-in to having their cross-site cookies partitioned by top-level site.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/CHIPS
• Security and Privacy self-review²: https://github.com/WICG/CHIPS/blob/main/TAG-S%26P-questionnaire.md
• Primary contacts (and their relationship to the specification):
  • Kaustubha Govind (@krgovind), Google
  • Dylan Cutler (@DCtheTall), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/features/5179189105786880

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): IETF HTTP WG or WebAppSec WG
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/CHIPS/issues
• Major unresolved issues with or opposition to this design: https://github.com/WICG/CHIPS/issues
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[thezedwards]

Would it be correct to frame this as a side channel of the Google Privacy Sandbox being built to support specific usecases?

How is this impacted by CNAME mapping and efforts to muddle 1st party context? Will IDs stored in this storage be accessible to Javascript for 3rd party triangle syncs and therefore any IDs stored in this partition be ~100% open to be used as a cross-site ID? The answers @ https://github.com/WICG/CHIPS/blob/main/TAG-S%26P-questionnaire.md seem to not hide how dangerous this proposal is.....

Have other browsers considered this? It seems there are clear risks from this proposal, that it's a step in the wrong direction for any privacy sandboxes, and the fact that this proposal doesn't seem to even hide that it's a step backwards, it's unclear why this is being proposed, and how this aligns to rhetoric that Google has communicated about the so-called Privacy Sandbox being built into Chromium.

[wanderview]

I believe perhaps there is a misunderstanding about what the quoted text in section 3.5 above says. It does not say CHIPS creates a new side channel. It says that if a previously existing side channel is used to create an identifier, then CHIPS provides a place to store that identifier. This is, however, no different from the numerous other places that can be used to store state on the web platform (and all that storage is being partitioned).

[krgovind]

Would it be correct to frame this as a side channel of the Google Privacy Sandbox being built to support specific usecases?

No, this proposal does not introduce any side channels. The explainer and the S&P questionnaire explicitly discuss potential side channels, and where applicable, solutions for preventing them. We decided to address these head-on, because similar side-channel attacks were discussed in the context of other partitioning work, and we wanted to make sure that these were given consideration

How is this impacted by CNAME mapping and efforts to muddle 1st party context? Will IDs stored in this storage be accessible to Javascript for 3rd party triangle syncs and therefore any IDs stored in this partition be ~100% open to be used as a cross-site ID?

Could you expand upon the attack you are envisioning? By definition, identifiers stored in partitioned cookies are available to the owning domain/host only within the same top-level context that makes up the partition key. This is what prevents their use for tracking across sites.

Have other browsers considered this?

Yes. In fact, Firefox and Safari are currently either shipping or discussing partitioning of third-party cookies. In short, there is cross-browser alignment that this is a useful semantic for the web, the differences are in the syntactical/deployment approaches.

[thezedwards]

Thanks for a bunch of people chiming in from Google so quickly.

1. As mentioned, yes this is a side channel. It may use "existing side channels" - but this is Google saying, "we aren't getting rid of 3rd party cookies, we are actually going to evolve them, but going to not mention the evolution or the overall 3rd party cookie deprecation when explaining this new proposal)."

1a) Please explain in these types of proposals HOW they relate to other proposals. This should be communicated as, "The CMA told us we needed to evolve 3rd party cookie deprecations, so we looked at what FireFox is doing for half-measures, and are modeling that. We still intend to keep the 3rd party deprecation timetable that we've discussed, and when the privacy sandbox is deployed, these techniques will no longer work - we are proposing an interim measure that would provide new/slightly safer tracking methods for 18-24 months, and assuming that FireFox stops their practice, Google may follow that. But for now, the company Google is paying billions to default Google search for, is acting like a policy blocker for one of our worst data sharing proposals in 2021 that conflicts with other privacy sandbox messaging."

2. A double key cookie does NOTHING if that cookie is accessible to an entity via Javascript, because they can read the cookie, and then fire off a request with that value back to the 1st party or other new 3rd party partners. If CNAME mapping protections aren't deployed with this, and other JS restrictions for the value stored in a double-keyed cookie, then it might as well be a single key -- this doesn't stop the partner who controls the key from sharing that value with new partners. In fact, the specs @ https://github.com/WICG/CHIPS#partitioning-model literally mention First Party Data sets, which is a CNAME-tracking-loophole, the middle ground to make it slightly safer, but not a solution at internet-scale at all.

2a) It's 2021 and Google and other browsers are still pretending like "Corporate Entity Lists associated to which browsers they own is a safe practice for building internet policies" -- first party lists and efforts to give special data sharing access to major corporations who own dozens/hundreds of domains, proves that Google is favoring itself and companies exactly like itself.

3. I hope regulators are watching how these proposals are shared in a a place like github, with tons of details missing, when the folks at the CMA and other regulatory bodies have asked for Google to be extremely clear about these proposals, the timelines, what each if shifting, and also requiring that these proposals be viewed through the lens of other public promises from Google about efforts to stop tracking.

3a) These types of proposals are market manipulation, and when this proposal "Gets press" - a bunch of "Open Internet" stocks will jump up at the news that Google is looking at half-measures all of a sudden, and not only has shifted from the timetable for full 3rd party cookie deprecation, but ya'll are now looking at policies that FireFox deployed, largely because it's a far weaker data protection policy than full 3rd party cookie blocking.

4. Looks like data privacy activists need to start focusing their attention on Firefox and the "half measures" that have been deployed there, which are now being used as policy blockers for Google to deploy similarly less safe half measures.

I'll let other folks ask questions and dig into this -- Google should stop putting huge policy shifts like this behind "proposals" and put them on the corporate google.com blog pages. It's clear this "3rd party cookie deprecation half measure" will be deployed, ya'll aren't asking for feedback or going through any standards reviews that could keep this from being deployed, and as mentioned, stocks are going to jump from this news, and many folks at Google and working at Google Ventures would know about these shifts and how they would impact competitor stock prices.

[torgo]

Hi @thezedwards. While we appreciate and welcome spirited debate and community contribution to our design reviews repo, can I please remind you that (a) this is a the technical architecture group and any discussion in these issues should focus on the technical design of the specifications and technologies being reviewed (and not stray into policy/legal/regulatory) and (b) we operate under the W3C Code of Conduct and Professional Ethics and as such can I please ask that you keep your remarks respectful and professional.

[torgo]

Hi @DCtheTall, @krgovind. We have been talking about this in today's TAG call. We're a bit concerned that this proposal is reinforcing or enabling a web feature that we might want to be deprecating in the first place? We discussed some negative outcomes of data leakage to a 3rd party without user interaction / consent which are enabled by the current regime and which would continue to be enabled in a CHIPS world. We're also concerned about the roll-out plan. If partitioned and unpartitioned cookies are intended to be supported simultaneously for some period of time then that could enable 3rd parties to work around the privacy protections. Also we discussed how this could/should fit together with the storage access API. Could we bring one of you in to a TAG call at some point to discuss further?

[krgovind]

Hi @torgo! Thanks for the review! I’d be happy to join a TAG call to discuss further.

I can also try and address some of the points raised in the discussion:

We're a bit concerned that this proposal is reinforcing or enabling a web feature that we might want to be deprecating in the first place?

I believe the web feature that is being referenced is unpartitioned cross-site cookies a.k.a “third-party cookies”. The primary reason for deprecating unpartitioned cross-site cookies is their prevalent use for cross-site tracking. Since partitioned cross-site cookies are double-keyed/partitioned, they do not enable the same kind of cross-site tracking. On the other hand, cross-site cookies are useful because they enable the “composable” nature of the web, where websites can delegate services to third-parties such as software-as-a-service providers, and content delivery networks, that don’t intend to track users across sites, but only need access to some notion of state that is scoped to the top-level website. These are the use-cases that we hope to serve with this proposal.

We discussed some negative outcomes of data leakage to a 3rd party without user interaction / consent which are enabled by the current regime and which would continue to be enabled in a CHIPS world.

First: Looking through the discussion notes, I saw that the Facebook Like button was discussed extensively as a scenario. Note that many embedded third-party use-cases like the Facebook Like button offer two embedding options:

1. JavaScript SDK (website embed a <script> tag on the top-level page)
2. <iframe> embed

JavaScript SDK based widgets have access to partitioned state even where third-party cookie blocking is enabled; because scripts embedded using the <script> tag in the top-level site already have access to the first-party cookie jar via document.cookie, and are able to store identifiers in it. Such identifiers are essentially partitioned by the top-level site; because the same third-party script on a different website would access that website’s first-party cookie jar, and therefore cannot see the identifier it may have stored on the first website.

Disallowing iframes from having similar access to partitioned state might incentivize third-parties to move from iframes to the embedded <script> (JS SDK) model, which we think is a worse direction for security and privacy, because it allows third-parties access to first-party cookies and storage.

Second: In the discussion notes, there was a comment that this proposal would be a regression for browsers like Safari where third-parties don’t have access to partitioned cookies. I disagree because Safari already provides default/seamless access to partitioned/double-keyed JavaScript storage when third-party cookie blocking is on. privacycg/storage-partitioning/issues/12 has discussion on the current state of partitioning in other browsers.

Could the TAG clarify whether the feedback is that:

1. A permission prompt should be required for partitioned cookies, but not for partitioned JavaScript storage?, or
2. Both partitioned JS storage and cookies should be gated behind a permission prompt?

(1) would mean stricter rules for cookies than for JS storage. Is there a reason we’d prefer this? Sites could simply migrate to JavaScript embedded either on the top-level website, or load JavaScript in iframes. So there is no improvement in terms of privacy benefits to the user.

(2) would entail changes to shipping behavior in Safari ITP, as well as Firefox’s Total Cookie Protection feature.

We're also concerned about the roll-out plan. If partitioned and unpartitioned cookies are intended to be supported simultaneously for some period of time then that could enable 3rd parties to work around the privacy protections.

Indeed. We are considering the fact that simultaneously supporting both mechanisms could allow third-parties to cache a cross-site join key (such as user-identifying information). The reason we’d like for partitioned cookies to be made available in Chrome before unpartitioned cookies are deprecated is to allow websites time to test, deploy, and prepare for the transition to a world without unpartitioned cookies.

One of the mechanisms we are considering to address the potential issue of 3ps caching cross-site join keys is to perform a one-time clearing of all partitioned cookies, which would be performed at the time when third-party cookie deprecation is shipped in Chrome. However, this plan has its tradeoffs; so we would like to invite the TAG’s feedback on it:

As mentioned above, third-parties with script access on the top-level website have access to the first-party cookie jar and could cache such cross-site join keys there. We are considering whether implementing a mechanism to clear only third-party partitioned state would incentivize third-parties to move towards having the top-level website embed their scripts; over adopting something like CHIPS in iframes. The alternative would be to clear all site data (including state belonging to top-level websites) at the time that Chrome ships third-party cookie deprecation, but that would be very disruptive to users.

I’d like to invite the TAG’s opinion on whether there are other options that we should consider.

Also we discussed how this could/should fit together with the storage access API.

My understanding is that the browsers that currently support storage access API are using it to allow third-parties access to unpartitioned storage. There is the discussion on privacycg/storage-access/issues/75 where the proposal is to “allow for prompt-free, undelayed cookie access” to partitioned cookies if the developer opts-in to partitioned cookies via an additional/optional parameter to the Storage Access API. However, since cookies are intended to be used as HTTP state, we would like to propose an API that doesn't require sites to deploy JavaScript (Storage Access API is a JS API), and works efficiently even for HttpOnly cookies.

[torgo]

I believe the web feature that is being referenced is unpartitioned cross-site cookies a.k.a “third-party cookies”.

Hi @krgovind just a quick note. I was actually refering to the high level user-facing feature - embedded content of any kind (such as a facebook like button, as we discussed in the session) that leaks information to a third party without the user's consent. In the facebook like button example, the harm from the cited example (UK NHS putting like buttons on their pages and thereby unintentionally leaking sensitive health information to Facebook) is a clear example of user harm that can result from this pattern – which is one of the things that has led to the (in progress) deprecation of "unpartitioned cross-site cookies."

My initial reaction to your question about permission prompts is that it should be required for 3rd party cookies in order to ensure that there is user consent going on when information is shared to those 3rd parties – and to inform them when they visit (e.g.) an NHS or NYTimes page that "(e.g.) Facebook would like to know what pages you visit here." If that same functionality is possible via partitioned JS storage then yes, I also think that should be gated behind a permission. However I don't think we need to fix both problems at once and I don't think we should be weakening one set of protections just because another set is already weak.

We're going to discuss again at our plenary call this week and try to come back to you with some useful feedback taking your poitns above into account and possibly schedule a live session after that.

[krgovind]

Thanks for the clarification @torgo!

In the facebook like button example, the harm from the cited example (UK NHS putting like buttons on their pages and thereby unintentionally leaking sensitive health information to Facebook) is a clear example of user harm that can result from this pattern – which is one of the things that has led to the (in progress) deprecation of "unpartitioned cross-site cookies."

Ah yes, indeed. The other mechanism (which many browsers now ship) to prevent this harm is to trim the default referrer. For example, Chrome changed the default referrer policy to strict-origin-when-cross-origin in M85, and we also initiated (and successfully merged) an update to the spec, which means that Facebook will now by default only receive https://www.nhs.uk as the referrer. Therefore, any potentially sensitive health information that can be gleaned from the Referer URL is no longer available. With this change NHS would have to opt-in to sending Facebook the full URL path by specify unsafe-url or no-referrer-when-downgrade as the referrer policy on the widget element. This article explains the change.

My initial reaction to your question about permission prompts is that it should be required for 3rd party cookies in order to ensure that there is user consent going on when information is shared to those 3rd parties – and to inform them when they visit (e.g.) an NHS or NYTimes page that "(e.g.) Facebook would like to know what pages you visit here."

Note that the proposal is not about (unpartitioned) 3p cookies as they exist today. What we're proposing is partitioning/double-keying those cookies. In the long-term default/un-gated access to unpartitioned 3p cookies will be deprecated, so Facebook would not be able to correlate the user activity on NHS/NYTimes with the user's logged in identity.

Is the concern about use of covert tracking signals (like fingerprinting or IP addresses) to join cross-partition identity?

Also, a quick note that Firefox's Total Cookie Protection feature, which is shipping, partitions both cookies and JS storage by default (i.e. no permission prompt needed).

[torgo]

@krgovind one thing we discussed in followup this morning is that the explainer kind of assumes you know what partitioned and unpartitioned is. I think it could benefit from a definition up front, as well as a definition of what opt-in means in this document. You say "developer opt-in" but I think it needs to be specific about which party is opting in in a scenario where you have a 1st party and a 3rd party involved...

[kenchris]

I agree with @torgo. Also, as I understand other browsers user partitioned cookies today, so why don't they need a proposal like this? Do they have an exception list or similar? This should be part of the introduction section in the explainer: What is partitioning? Who is using it today? pros/cons?

Now I read this on a webkit blog "As of ITP 2.1, partitioned cookies are no longer supported and third-parties classified with cross-site tracking capabilities now have to use the Storage Access API to get any cookie access."

So other browsers are moving away from partitioned cookies? All of this should really be discussed up front in the explainer

[torgo]

Focusing in on the "opt in": It's not clear to me why and how developer opt-in to partitioning aids user privacy? If cookies that are not opted in to partitioning will eventually be deprecated then why not simply double key all cookies to begin with rather than requiring an opt-in? Is the opt in only relevant to the phase-in period?

[DCtheTall]

@torgo @kenchris Thanks for taking the time to leave comments.

one thing we discussed in followup this morning is that the explainer kind of assumes you know what partitioned and unpartitioned is. I think it could benefit from a definition up front, as well as a definition of what opt-in means in this document.

Good point, I have refactored the explainer to make it more clear what "partitioning" cookies means.

You say "developer opt-in" but I think it needs to be specific about which party is opting in in a scenario where you have a 1st party and a 3rd party involved

I see the ambiguity there, I changed "developer opt-in" to "third-party opt-in" since it is the third party who should be including the Partitioned attribute in their cookies. Top-level site owners do not need the Partitioned attribute and can just use SameSite=Lax.

Also, as I understand other browsers user partitioned cookies today, so why don't they need a proposal like this? Do they have an exception list or similar?

Firefox blocks 3P cookies in ETP Default mode based on a blocklist, but AFAIK they do not partition cookies for sites on that block list in ETP Default. Cookie partitioning is only available in Private Browsing or ETP Strict mode.

Safari shipped then rolled back cookie partitioning in previous versions of ITP.

This is discussed in the explainer in Alternate Cookie Partitioning Designs.

All of this should really be discussed up front in the explainer

Ack'd. I can refactor the explainer to be more clear about these distinctions between what we are proposing and what different browsers have worked on up front.

It's not clear to me why and how developer opt-in to partitioning aids user privacy? If cookies that are not opted in to partitioning will eventually be deprecated then why not simply double key all cookies to begin with rather than requiring an opt-in? Is the opt in only relevant to the phase-in period?

The third-party opt-in is for web compatibility. We believe introducing a third-party opt-in will help ease the transition for third-party site owners to the new semantics of cross-site cookies.

Also adding a new attribute which requires the __Host- prefix will ideally broaden adoption of existing cookie features which improve the security model of cookies.

[krgovind]

It's not clear to me why and how developer opt-in to partitioning aids user privacy? If cookies that are not opted in to partitioning will eventually be deprecated then why not simply double key all cookies to begin with rather than requiring an opt-in? Is the opt in only relevant to the phase-in period?

The third-party opt-in is for web compatibility. We believe introducing a third-party opt-in will help ease the transition for third-party site owners to the new semantics of cross-site cookies.

Also adding a new attribute which requires the __Host- prefix will ideally broaden adoption of existing cookie features which improve the security model of cookies.

@torgo In addition to the points @DCtheTall mentioned; I envision that there is a need for a third-party developer opt-in even for the medium-to-long term (i.e. after the phase-in period). On most browsers, users/enterprise admins are able to enable support for unpartitioned third-party cookies. For example, users can disable tracking protection on Safari and Firefox. On Chrome (and presumably on other browsers), users and enterprise admins are able to create allowlists of domains that third-party cookie blocking does not apply to. Requiring developer opt-in ensures a consistent semantic regardless of browser treatment of third-party cookies.

[torgo]

Hi @krgovind - Ok that's great! Is the revised explainer stable at this point?

[hadleybeeman]

Hi @krgovind! Thanks for letting us know that you're removing CHIPS's dependency on first party sets.

I've had a look at your updated explainer... Can I just check my understanding? Does it mean that if a site is part of a first party set, then the double-keyed cookie is double-keyed to the first-party set rather than the specific domain — but if it's not part of a first-party set, then everything operates according to domain / origin? Is that correct?

Thanks!

[torgo]

Just noting with interest the good feedback that seems to have come from other browser vendors on CHIPS as recorded in Privacy CG minutes. 👍🏻

[krgovind]

Hi @krgovind - Ok that's great! Is the revised explainer stable at this point?

@torgo : Sorry, not yet, but once PR #44, it will be. (We'll give it a few days for community review before merging it in)

Hi @krgovind! Thanks for letting us know that you're removing CHIPS's dependency on first party sets.

I've had a look at your updated explainer... Can I just check my understanding? Does it mean that if a site is part of a first party set, then the double-keyed cookie is double-keyed to the first-party set rather than the specific domain — but if it's not part of a first-party set, then everything operates according to domain / origin? Is that correct?

@hadleybeeman That's correct. To be specific, the "site" in question is the top-level/embedder website.

[torgo]

Hi @krgovind, we're happy to see the update to the explainer which removes the dependency on First Party Sets. This was the key blocking issue in our view. It's good to see this proposal has good traction from implementers. We remain concerned about how/why developers will take this up - we understand this will depend on the deprecation of third party cookies, which we welcome. The TAG view is that this proposal will improve privacy on the Web.