Introduce a cookie attribute called SameParty, which allows web developers to annotate cookies that are allowed to be set or sent in contexts where all ancestor frames belong to the same party, as demarcated by First-Party Sets.
In order to increase privacy on the web, browser vendors are either planning or already shipping restrictions on cross-site tracking, such as phasing out third-party cookies. Third-party cookies are currently defined as those associated with a site that is different from the site of the top-level page. However, modern websites are typically served over multiple domains/sites, many of which are owned by the same organization. First-Party Sets provides a mechanism to group domains/sites belonging to the same organization as being same-party with each other, and thus defines a privacy boundary for websites.
The SameParty cookie attribute provides web developers a means to annotate cookies that are allowed to be set or sent in same-party, cross-site contexts; and hence should not be subject to obsoletion. In addition, SameParty cookies are blocked in cross-party, cross-site contexts.
We are introducing SameParty now, early in the process of phasing out third-party cookies, as a means for sites to test out the First-Party Set behavior. While third-party cookies are still around today, we want to provide ample opportunities for web developers to test that their sites work with SameParty and to migrate their cookies to the new model far in advance of third-party cookies' removal.
Interoperability and Compatibility
Little to no interoperability risk. The SameParty cookie attribute does not reuse or alter a previously defined token, and should be ignored by browsers that don't support it, as specified by RFC 6265bis. Cookies set with SameParty will likely also specify SameSite=None, such that SameParty can be used preferentially when supported, while browsers that don't support SameParty will continue to apply SameSite=None (which is more permissive than SameParty), such that no site breakage is expected. Alternatively, cookies may be set with both SameParty and SameSite=Lax, so that browsers that don't support SameParty continue to apply SameSite=Lax rules (more restrictive than SameParty) to protect against cross-site attacks.
No compatibility concerns, because without the SameParty attribute, cookie semantics are unchanged.
Edge: Positive (supportive of continued discussion)
Web / Framework developers: Positive signals as demonstrated in W3C PrivacyCG discussions
This attribute is to be used in conjunction with First-Party Sets. For the initial prototype in Chromium, a cookie that specifies SameParty while the site is not in a specified First-Party Set will be subject to SameSite enforcement rules, rather than SameParty rules. This is because the First-Party Sets are to be delivered via Component Updater, and there may be a gap between when the First-Party Sets are updated and when the SameParty cookies are deployed, during which the cookies should not be subject to SameParty enforcement to avoid site breakage.
Developers can also perform end-to-end testing of their sites with this feature enabled, without deploying a real First-Party Set, by using the --use-first-party-set= command-line switch in Chromium.
We plan to update the DevTools Cookies panel to display the SameParty attribute value, and show tooltips in the Network tab when cookies are excluded due to SameParty enforcement. In addition, the Issues tab will display warnings when the attribute is used incorrectly.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. This feature will be supported on Windows, Mac, Linux, Chrome OS, and Android, but will initially not be supported on Android WebView. This feature depends on First-Party Sets, which will initially not be supported on Android WebView due to the Component Updater dependency during the initial prototype phase.
Link to entry on the feature dashboard
Requesting approval to ship?