Below is a summary of the Cookies Having Independent Partitioned State (a.k.a. CHIPS) explainer: GitHub - DCtheTall/CHIPS: A proposal for a cookie attribute to partition cross-site cookies by top-level site. If you are interested in learning more about this proposal, I recommend reading the entire proposal there.

A Problem

Major browsers have already begun to restrict cookies sent in cross-site contexts (i.e. third-party cookies) since these cookies have the potential to identify users and track their behavior across different top-level sites.

However, not all cross-site cookies are used for cross-site tracking. There are several other use cases for cookies on the web which are related to a user’s activity within a single top-level site. Some examples include: third-party SaaS embeds like store locator services or customer support chat widgets and CDNs that use cookies for load balancing.

In these cases, the cross-site requests are for sites who are owned by a different organization than the owner of the browser’s top-level site, so First-Party Sets are not sufficient to meet these use cases.

A Proposal

We propose a new opt-in cookie attribute, Partitioned, which servers can use to indicate they’d wish to set a cross-site cookie which is partitioned by top-level site.

This means that if a user is visiting example.com and embed.saas.com sets a cookie with the Partitioned attribute:

Set-Cookie: __Host-sid=a3e9f; Secure; HttpOnly; Path=/; Partitioned;

Then the resulting cookie would only be sent to embed.saas.com when the browser’s top-level site is example.com. In other words, if the user navigates to a different top-level site that makes cross-site requests to embed.saas.com, those requests would not include the cookie set on example.com.

When major browsers no longer support unpartitioned third-party cookies, these Partitioned cookies would not be subject to the same cross-site cookie restrictions as unpartitioned third-party cookies. This would allow third parties to continue to use cookies without giving them the capability of storing cross-site identifiers on users’ machines.

Important takeaways from the explainer

• Opt-in cookie attribute, Partitioned, instead of partitioning by default.
• Browsers must enforce that Partitioned cookies also adopt other semantics which help improve the security of cookies by requiring that in order to use Partitioned, a cookie must also use the __Host- prefix.
• Browsers must enforce limitations on the size of a third party’s cookie jar per-partition, but not across different partitions, in order to avoid leaking cross-site information to third parties.

WDYT?

I think this proposal makes a lot of sense.

As your problem statement calls out, there are a variety of useful scenarios where cookies are used today. Cookies also have a useful property that don’t exist in other storage APIs: the ability to mark them HttpOnly (+Secure). I don’t personally believe it’s desirable to block them by default as Safari does today.

If we work under the assumption that allowing cookies in a partitioned context without user interaction is reasonable (which, per the discussion in Let embedees optionally request access to partitioned cookies and storage · Issue #75 · privacycg/storage-access · GitHub appears to be cross-browser consensus), in what situations should they be allowed to be set?

1. Always, with them writing to partitioned cookie storage by default.
2. If/when an explicit JavaScript call is made to unlock access (as described in the Storage Access API issue link).
3. When they are explicitly marked as being desired in a partitioned context (as described in this proposal).

The WebKit team has described trying the first approach years ago and running into unacceptable compatibility issues. It’s difficult to reason about if the things would be any different now, either for them or other browsers. Site authors sometimes gate logic on a UA detection, so the compat impact could be different between browsers as well.

The second approach makes less sense to me if we don’t have a user interaction requirement-- it prevents the storage of cookies on the first request and forces a more async pattern that is likely more difficult for developers.

The third approach, this proposal, strikes a reasonable balance of avoiding sites seeing cookies and assuming they are cross-site as they always were in the past and instead makes them explicitly mark them. In the process of doing that, they will likely go through at least one pass of testing to confirm it will work for them.

Salesforce expressed support for this proposal here: Very happy to see this proposal · Issue #8 · DCtheTall/CHIPS · GitHub

Given the interest, this has been adopted as an incubation into GitHub - WICG/CHIPS: A proposal for a cookie attribute to partition cross-site cookies by top-level site.