Re: [w3ctag/design-reviews] Cookies Having Independent Partitioned State (CHIPS) (#654)

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: (a) JavaScript SDK (website embed a `<script>` tag on the top-level page) or (b) 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.
Not allowing iframes to have 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, it seemed like there was a note 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 a permission prompt should be required for partitioned cookies, but not for partitioned JavaScript storage? Or is the feedback that both partitioned JS storage and cookies should be gated behind a permission prompt? 
The former 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.
The latter 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”. 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.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/654#issuecomment-887056462