Intent to Experiment: First-Party Sets and 'SameParty' cookie attribute
Chris Fredrickson
{cfredric, chlily, kaustubhag, shuuran}@chromium.org
Explainer
https://github.com/privacycg/first-party-sets
https://github.com/cfredric/sameparty
Specification
None
Design docs
Working on finalizing; will update the thread when this is complete.
Summary
Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. (A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set.) Allow sites to indicate which cookies are intended to be set or sent in contexts where all ancestor frames belong to the same First-Party Set.
Blink component
Internals>Network>First-Party-Sets
TAG review
https://github.com/w3ctag/design-reviews/issues/342
https://github.com/w3ctag/design-reviews/issues/595
TAG review status
Pending
Risks
Interoperability and Compatibility
No risks for First-Party Sets. Sites will opt in to using First-Party Sets; there is no change to existing behavior for sites not opting in to First-Party Sets.
Little to no interoperability risk for the SameParty attribute. 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.
Gecko: Harmful (https://github.com/mozilla/standards-positions/pull/360/files)
Edge: Positive (https://github.com/privacycg/meetings/blob/master/2020/telcons/12-10-minutes.md)
WebKit: Positive (https://github.com/cfredric/sameparty/issues/2)
Web developers: Positive (https://github.com/privacycg/meetings/blob/master/2020/telcons/12-10-minutes.md)
Ergonomics
The SameParty 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.
Activation
To use this feature, sites will have to join a First-Party Set (process detailed on https://sites.google.com/a/chromium.org/dev/updates/first-party-sets). Developers will also have to change their Set-Cookie headers and JavaScript document.cookie writes to apply a valid SameParty attribute.
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.
Goals for experimentation
To get feedback on the First-Party Sets and `SameParty` proposals; test First-Party Set functionality within a limited prototype; evaluate the current First-Party Set policy; and increase awareness of the First-Party Set and SameParty features.
We will collect metrics on cookie usage, i.e. how often the `SameParty` attribute is the sole reason for excluding a cookie; how often the `SameParty` attribute includes a cookie that would have been excluded by the value of the cookie's `SameSite` attribute; and the extent to which `SameParty` was necessary for including a `SameParty` cookie (i.e. how many different domains had to be treated as same-party in order to include the cookie).
Debuggability
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. The SameParty 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.
Is this feature fully tested by web-platform-tests?
No. It is testable however, and we do plan to add tests.
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1175191
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5280634094223360
Links to previous Intent discussions
Intent to prototype for First-Party Sets: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/0EMGi-xbI-8/m/FgSjq6TtBwAJ
Intent to prototype for SameParty: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-unZxHbw8Pc
