[Proposal] First-Party Sets

Tags: #<Tag:0x00007fc569fdd960>


(The following is a quick summary of the explainer at https://github.com/mikewest/first-party-sets. If you’re interested in more details, I’d suggest skimming that document.)

A Problem

One pattern that most browsers have agreed upon is a categorization of requests and documents into “first-party” and “third-party” buckets, giving users the option to regulate cross-context access to persistent state.

A number of browser features depend upon this distinction to some extent. Cookie controls are the most prominent example, followed by narrower features like credential sharing schemes (Shared Web Credentials and Smart Lock for Passwords, for example), process selection, etc. Note that the latter two examples rely on proprietary heuristics in some cases.

The first-/third-party distinction breaks down to an extent in practice, as a single entity will often host its assets and services across domains that aren’t known a priori to be related. Consider https://apple.com/ and https://icloud.com/ , https://google.com/ and https://youtube.com/ , or https://amazon.com/ and https://amazon.de/ . These origins all represent distinct registrable domains, and are generally considered “third-party” to each other, though they’re controlled by the same entity, and explicitly share state information with each other in order to support features like single sign-on.

A Proposal

One way of approaching this problem would be to run with an approach similar to what some native platforms have already shipped: JSON files hosted at well-known locations on various origins that wish to assert their shared first-partyness. We could allow https://a.example/ , https://b.example/ , and https://c.example/ to declare themselves as a first-party set by hosting a JSON file at /.well-known/first-party-set containing a first-party-set member which holds the set of origins being asserted:

  "first-party-set": {
    "origins": [ "https://a.example/", "https://b.example/", "https://c.example/" ]

https://a.example/ informs the browser about this file by delivering an X-Bikeshed-This-Origin-Asserts-A-First-Party-Set: ?T header. Upon receipt, the browser pulls down this file, as well as the files for any other origin asserted to be in the set. If all the origins assert the same set, huzzah! If not, it’s not a set.

What does being first-party set enable?

I have three things in mind:

  • The “block third-party cookies and site data” behavior in browsers could respect this notion of first-partyness to avoid breaking same-entity interactions. Likewise, browsers can enhance their cookie control mechanisms with this additional metadata. For example, “Forget this site” can shift towards “Forget this entity”, wiping data for an entire set of first-parties at once.
  • Browsers’ credential sharing behavior for sites which are affiliated could substitute this proposal for the vendor-specific solutions which exist today.
  • Browsers may use first-party sets as one additional input into heuristics around their process models while they ramp up to strict origin isolation.