Allow related domain names owned and operated by the same entity to declare themselves as belonging to the same first party.
First-Party Sets proposal is being updated with a new design based on use case specific definition and the Storage Access API. You can follow the discussion in the repo and we will update this content as the work progresses.
- First-Party Sets design change proposal, July 2022.
- The initial origin trial for First-Party Sets and SameParty was available in Chrome from versions 89 to 93 and is now closed.
- Chrome Platform Status.
- Chromium Projects.
Why do we need First-Party Sets?
Browsers are proposing privacy models that restrict access to user identity within a cross-site context. However, many organizations have related sites with different domain names, such as domains for different countries (
example.co.uk, for example). It should be possible to allow related domain names with an appropriate relationship, perhaps common ownership, to declare themselves as belonging to the same first party, so browsers treat those domains as first-party in situations where first party and third party are treated differently.
Any solution would also need to prevent abuse of the system. For example, it should not be possible to declare organizations that include unrelated sites with different owners, in order to gain first-party privileges.
How do First-Party Sets work?
A website can declare that it is a member (or owner) of a set of web domains by serving a manifest file that defines its relationship to the other domains: a JSON file at a
c.example wish to form a first-party set owned by
a.example. The sites would then serve the following resources:
"members": ["b.example", "c.example"],
The owner domain hosts a manifest file that lists its member domains. A browser can ask a member website to specify its owner, and then check the owner's manifest to verify the relationship.
Browser policies are expected to prevent abuse or misuse. For example, First-Party Sets must not enable the exchange of user information across unrelated sites, or the grouping of sites that are not owned by the same entity. One possible way for a site to register could be for the site to submit their proposed group of domains to a public tracker (such as a dedicated GitHub repository) along with information needed to satisfy browser policy. Verification of the owner’s control over member domains may also require a challenge to be served at a
.well-known URL on each of the domains in the set.
The complementary proposal to First-Party Sets is the
SameParty cookie attribute. Specifying the
SameParty attribute on a cookie instructs the browser to include the cookie when its context is part of the same First-Party Set as the top-level context.
For example, for the First-Party Set described above, a.example can set the following cookie:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
This means that when a visitor on b.example or c.example makes a request to a.example, the
session cookie is included on that request.
Engage and share feedback
- Origin trial: The initial origin trial for First-Party Sets and SameParty was available in Chrome from versions 89 to 93 and is now closed.
- GitHub: Read the proposal, raise questions and follow discussion.
- Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.