diff --git a/README.md b/README.md index b37c45a..52aa8e0 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ -# First-Party Sets +# Related Website Sets (formerly known as: First-Party Sets) This document proposes a new web platform mechanism to declare a collection of related domains as -being in a First-Party Set. +being in a Related Website Set. This proposal was previously named First-Party Sets. ## Editors: @@ -56,7 +56,7 @@ some notion of first-party. In defining this scope, we must balance two goals: t small enough to meet the user's privacy expectations, yet large enough to provide the user's desired functionality on the site they are interacting with. -First-Party Sets (FPS) is a web platform mechanism, proposed within the context of browser efforts to phase out support for third-party cookies, through which site authors of multi-domain sites may declare relationships between domains such that the browser may understand the relationships and handle cookie access accordingly. +Related Website Sets (RWS) is a web platform mechanism, proposed within the context of browser efforts to phase out support for third-party cookies, through which site authors of multi-domain sites may declare relationships between domains such that the browser may understand the relationships and handle cookie access accordingly. The core principle of allowing browsers to treat collections of *known related sites* differently from otherwise *unrelated sites* is grounded in ideas that had been previously discussed in the W3C (such as [Affiliated Domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12)), the now defunct IETF [DBOUND](https://datatracker.ietf.org/doc/html/draft-sullivan-dbound-problem-statement-02) working group, and previously deployed in some browsers (such as the [Disconnect.me entities list](https://github.com/disconnectme/disconnect-tracking-protection/blob/master/entities.json)). @@ -119,7 +119,7 @@ This proposal anchors on the use cases described above to develop a framework fo # Proposal -At a high level, a First-Party Set is a collection of domains, for which there is a single "set primary" and potentially multiple "set members." Only site authors will be able to submit their own set, and they will be required to declare the relationship between each "set member" to its "set primary." This declaration will be grounded in the [use cases](#heading=h.4t8m5gy1pn0r) described above and defined by "subsets." +At a high level, a Related Website Set is a collection of domains, for which there is a single "set primary" and potentially multiple "set members." Only site authors will be able to submit their own set, and they will be required to declare the relationship between each "set member" to its "set primary." This declaration will be grounded in the [use cases](#heading=h.4t8m5gy1pn0r) described above and defined by "subsets." ## Defining a "set" through use case-based "subsets" @@ -127,7 +127,7 @@ Throughout the evolution of this proposal, we considered how to define a single At time of submission, "set primaries" and "set members" will be declared. Set members could include a range of different domain types, matching up to the different types of use cases (or *subsets*) such as domains that users never directly interact with, like service or sandbox domains; and domains where users may benefit from a seamless session, like brand or app domains. -We propose enumerating the range of applicable subsets within a set (beginning with subsets that correlate to the [use cases described above](#use-cases)), requiring that a member domain must meet the definition of a single subset to be part of the set. For example, consider the following table as an example First-Party Sets schema: +We propose enumerating the range of applicable subsets within a set (beginning with subsets that correlate to the [use cases described above](#use-cases)), requiring that a member domain must meet the definition of a single subset to be part of the set. For example, consider the following table as an example Related Website Sets schema: **Set primary:** exampleA.com @@ -229,7 +229,7 @@ We consider using a public submission process (like a GitHub repository) to be a The following technical checks also help to mitigate abuse: -- Mutual exclusivity to ensure a domain isn't part of multiple First-Party Sets +- Mutual exclusivity to ensure a domain isn't part of multiple Related Website Sets - `.well-known` file check on all domains to ensure authorized submissions - Check against the [Public Suffix List](https://publicsuffix.org/) to ensure that sets are composed of valid registrable domains @@ -237,52 +237,52 @@ Additionally, there are other enforcement strategies we could consider to furthe For some subsets, like the "associated" subset, objective enforcement may be much more difficult and complex. In these situations, the browser's handling policy, such as a limit of three domains, should limit the scope of potential abuse. Additionally, we think that site authors will be beholden to the subset definition and avoid intentional miscategorization as their submissions would be entirely public and constitute an assertion of the relationship between domains. -## Chrome’s Submission Guidelines and FPS Canonical List +## Chrome’s Submission Guidelines and RWS Canonical List -Chrome’s implementation will depend on the list of First-Party Sets generated via the process described in [Submission Guidelines](https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md). The guidelines aim to provide developers with clear expectations on how to submit sets to the [canonical list](https://github.com/GoogleChrome/first-party-sets/blob/main/first_party_sets.JSON) that the browser will consume and apply to its behavior. +Chrome’s implementation will depend on the list of Related Website Sets generated via the process described in [Submission Guidelines](https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md). The guidelines aim to provide developers with clear expectations on how to submit sets to the [canonical list](https://github.com/GoogleChrome/first-party-sets/blob/main/first_party_sets.JSON) that the browser will consume and apply to its behavior. ## Leveraging the Storage Access API -To facilitate the browser's ability to handle each subset differently, we are proposing leveraging the [Storage Access API](https://privacycg.github.io/storage-access/) (SAA) to enable cookie access within a FPS. +To facilitate the browser's ability to handle each subset differently, we are proposing leveraging the [Storage Access API](https://privacycg.github.io/storage-access/) (SAA) to enable cookie access within a RWS. - With the SAA, sites may actively request cross-site cookie access, and user-agents may [make their own decisions](https://privacycg.github.io/storage-access/#ua-policy) on whether to automatically grant or deny the request or choose to prompt the user. We propose that browsers supporting FPS incorporate set membership information into this decision. In other words, browsers may choose to automatically grant cross-site access when the requesting site is in the same FPS, or in a particular subset of the same FPS, as the top-level site. + With the SAA, sites may actively request cross-site cookie access, and user-agents may [make their own decisions](https://privacycg.github.io/storage-access/#ua-policy) on whether to automatically grant or deny the request or choose to prompt the user. We propose that browsers supporting RWS incorporate set membership information into this decision. In other words, browsers may choose to automatically grant cross-site access when the requesting site is in the same RWS, or in a particular subset of the same RWS, as the top-level site. -We'd like to collaborate with the community in evolving the Storage Access API to improve developer and user experience and help the SAA better support the use cases that FPS is intended to solve. One way to do that is through extending the API surface in a way that makes it easier for developers to use the SAA without integrating iframes: +We'd like to collaborate with the community in evolving the Storage Access API to improve developer and user experience and help the SAA better support the use cases that RWS is intended to solve. One way to do that is through extending the API surface in a way that makes it easier for developers to use the SAA without integrating iframes: ### Providing capabilities beyond the Storage Access API -SAA currently requires that the API: (a) be invoked from an iframe embedding the origin requesting cross-site cookies access, and that (b) the iframe obtains user activation before making such a request. We anticipate that the majority of site compatibility issues (specifically, those that FPS intends to address) involve instances where user interaction within an iframe is difficult to retrofit, e.g. because of the usage of images or script tags requiring cookies. Additionally, since cross-site subresources may be loaded synchronously by the top-level site, it may be difficult for the subresources to anticipate when asynchronous cookie access via SAA is granted. To address this difficulty, we [propose a new API](https://github.com/mreichhoff/requestStorageAccessForSite) that we hope will make it easier for developers to adopt this change. +SAA currently requires that the API: (a) be invoked from an iframe embedding the origin requesting cross-site cookies access, and that (b) the iframe obtains user activation before making such a request. We anticipate that the majority of site compatibility issues (specifically, those that RWS intends to address) involve instances where user interaction within an iframe is difficult to retrofit, e.g. because of the usage of images or script tags requiring cookies. Additionally, since cross-site subresources may be loaded synchronously by the top-level site, it may be difficult for the subresources to anticipate when asynchronous cookie access via SAA is granted. To address this difficulty, we [propose a new API](https://github.com/mreichhoff/requestStorageAccessForSite) that we hope will make it easier for developers to adopt this change. Note: Both Firefox and Safari have run into these issues before and have solved them through the application of an internal-only "requestStorageAccessForOrigin" API ([4](https://bugzilla.mozilla.org/show_bug.cgi?id=1724376), [5](https://github.com/WebKit/WebKit/commit/e0690e2f6c7e51bd73b66e038b5d4d86a6f30909#diff-1d194b67d50610776c206cb5faa8f056cf1063dd9743c5a43cab834d43e5434cR253)), that is applied on a case-by-case basis by custom browser scripts (Safari: [6](https://github.com/WebKit/WebKit/blob/a39a03d621e441f3b7ca3a814d1bc0e2b8dd72be/Source/WebCore/page/Quirks.cpp#L1065), [7](https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp#L1217) Firefox: [8](https://phabricator.services.mozilla.com/D129185), [9](https://phabricator.services.mozilla.com/D124493), [10](https://phabricator.services.mozilla.com/D131643)). -As we continue to flesh out the First-Party Sets proposal, we invite feedback from browser vendors, web developers, and members of the web community. We will continue engagement through issues in this repo and through discussions in [WICG](https://www.w3.org/community/wicg/). +As we continue to flesh out the Related Website Sets proposal, we invite feedback from browser vendors, web developers, and members of the web community. We will continue engagement through issues in this repo and through discussions in [WICG](https://www.w3.org/community/wicg/). ## Administrative controls -For enterprise usage, browsers typically offer administrators options to control web platform behavior. Browsers may expose administrative options for locally-defined First-Party Sets (e.g., for private domains). +For enterprise usage, browsers typically offer administrators options to control web platform behavior. Browsers may expose administrative options for locally-defined Related Website Sets (e.g., for private domains). # UI Treatment -In order to provide transparency to users regarding the First-Party Set that a web page’s top-level -domain belongs to, browsers may choose to present UI with information about the First-Party Set primary +In order to provide transparency to users regarding the Related Website Set that a web page’s top-level +domain belongs to, browsers may choose to present UI with information about the Related Website Set primary and the members list. One potential location in Chrome is the [Origin/Page Info Bubble](https://www.chromium.org/Home/chromium-security/enamel/goals-for-the-origin-info-bubble) - this provides requisite information to discerning users, while avoiding the use of valuable screen real-estate or presenting confusing permission prompts. However, browsers are free to choose different presentation based on their UI patterns, or adjust as informed by user research. -Note that First-Party Sets also gives browsers the opportunity to group per-site controls (such as +Note that Related Website Sets also gives browsers the opportunity to group per-site controls (such as those at `chrome://settings/content/all`) by the “first-party” boundary instead of eTLD+1, which is not always the correct site boundary. # Domain Schemes -In accordance with the [Fetch](https://fetch.spec.whatwg.org/#websocket-opening-handshake) spec, user agents must "normalize" WebSocket schemes to HTTP(S) when determining whether a particular domain is a member of a First-Party Set. I.e. `ws://` must be mapped to `http://`, and `wss://` must be mapped to `https://`, before the lookup is performed. +In accordance with the [Fetch](https://fetch.spec.whatwg.org/#websocket-opening-handshake) spec, user agents must "normalize" WebSocket schemes to HTTP(S) when determining whether a particular domain is a member of a Related Website Set. I.e. `ws://` must be mapped to `http://`, and `wss://` must be mapped to `https://`, before the lookup is performed. User agents need not perform this normalization on the domains in their static lists; user agents may reject static lists that include non-HTTPS domains. # Clearing Site Data on Set Transitions -Sites may need to change which First-Party Set they are a member of. Since membership in a set could provide access to cross-site cookies via automatic grants of the Storage Access API, we need to pay attention to these transitions so that they don’t link user identities across all the FPSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one First-Party Set to another when it changes its set membership. While a set member may not always request and be granted access to cross-site cookies, for the sake of simplicity of handling set transitions, we propose to treat such access as always granted. +Sites may need to change which Related Website Set they are a member of. Since membership in a set could provide access to cross-site cookies via automatic grants of the Storage Access API, we need to pay attention to these transitions so that they don’t link user identities across all the RWSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one Related Website Set to another when it changes its set membership. While a set member may not always request and be granted access to cross-site cookies, for the sake of simplicity of handling set transitions, we propose to treat such access as always granted. In order to achieve this, the browser must clear site data after a site undergoes certain transitions, before starting any fetches that depend on that data/storage. @@ -293,18 +293,18 @@ The clearing should behave like [`Clear-Site-Data: "*"`](https://www.w3.org/TR/c * A user identifier could be stored in any of these storage types. * Clearing just a few of the types would break sites that expect different types of data to be consistent with each other. -Since member sites can only add/remove themselves to/from FPSs with the consent from the primary, we look at First-Party Set changes as a site changing its FPS primary. +Since member sites can only add/remove themselves to/from RWSs with the consent from the primary, we look at Related Website Set changes as a site changing its RWS primary. If a site’s primary changed: -1. If this site had no FPS primary, the site's data won't be cleared. - * Pro: Avoids adoption pain when a site joins a FPS. +1. If this site had no RWS primary, the site's data won't be cleared. + * Pro: Avoids adoption pain when a site joins a RWS. * Con: Unclear how this lines up with user expectations about access to browsing history prior to set formation. 2. Otherwise, clear site data of this site. Potential modification, which adds implementation complexity: -3. If this site's new primary is a site that previously had the same FPS primary as the first site, the site's data won't be cleared. +3. If this site's new primary is a site that previously had the same RWS primary as the first site, the site's data won't be cleared. * Pro: Provides graceful transitions for examples (f) and (g). * Con: Multi-stage transitions, such as (h) to (i) are unaccounted for. @@ -316,19 +316,19 @@ Potential modification, which adds implementation complexity: ![](./images/FPS_clear_site_data-not_clear.drawio.svg) -a. Site A and Site B create a FPS with Site A as the primary and Site B as the member. Site data will not be cleared. +a. Site A and Site B create a RWS with Site A as the primary and Site B as the member. Site data will not be cleared. -b. Site C joins the existing FPS as a member site where Site A is the primary. Site data will not be cleared. +b. Site C joins the existing RWS as a member site where Site A is the primary. Site data will not be cleared. --- ![](./images/FPS_clear_site_data-clear.drawio.svg) -c. Given an FPS with primary Site A and members Site B and Site C, if Site D joins this FPS and becomes the new primary; the previous set will be dissolved and the browser will clear data for Site A, Site B and Site C. +c. Given an RWS with primary Site A and members Site B and Site C, if Site D joins this RWS and becomes the new primary; the previous set will be dissolved and the browser will clear data for Site A, Site B and Site C. -d. Given an FPS with primary Site A and members Site B and Site C, if Site B leaves the FPS, the browser will clear site data for Site B. +d. Given an RWS with primary Site A and members Site B and Site C, if Site B leaves the RWS, the browser will clear site data for Site B. -e. Given two FPSs, FPS1 has primary Site A and members Site B and Site C and FPS2 has primary Site X and member Site Y, if they join together as one FPS with Site A being the primary, the browser will clear site data for Site X and Site Y. +e. Given two RWSs, RWS1 has primary Site A and members Site B and Site C and RWS2 has primary Site X and member Site Y, if they join together as one RWS with Site A being the primary, the browser will clear site data for Site X and Site Y. --- @@ -336,17 +336,17 @@ With the potential modification allowing sites to keep their data if the new set ![](./images/FPS_clear_site_data-potential_modification.drawio.svg) -f. Given an FPS with primary Site A and members Site B and Site C, if no site is added or removed, just Site C becomes the primary and Site A becomes the member, no site data will be cleared. +f. Given an RWS with primary Site A and members Site B and Site C, if no site is added or removed, just Site C becomes the primary and Site A becomes the member, no site data will be cleared. -g. Given an FPS with primary Site A and members Site B and Site C, if Site A leaves the FPS and Site B becomes the primary, the browser will clear site data for Site A. +g. Given an RWS with primary Site A and members Site B and Site C, if Site A leaves the RWS and Site B becomes the primary, the browser will clear site data for Site A. -h. & i. Given the FPS with primary Site A and member Site B and Site C, if Site D joins this set as a member and later becomes the primary, site data of Site A, Site B and Site C is only preserved if the user happens to visit during the intermediate stage. +h. & i. Given the RWS with primary Site A and member Site B and Site C, if Site D joins this set as a member and later becomes the primary, site data of Site A, Site B and Site C is only preserved if the user happens to visit during the intermediate stage. # Alternative designs ## Synchronous cross-site cookie access within same-party contexts -Where a Storage Access API invocation is automatically granted due to membership in the same First-Party Set, a similar effect may be achieved by user agents always allowing cross-site cookie access across sites within the same set. Such cookie access may be subject to rules such as [SameSite](https://web.dev/samesite-cookies-explained/), and depend on specification of a cookie attribute such as [SameParty](https://github.com/cfredric/sameparty). This would allow for synchronous cookie access on subresource requests, and, for most part, allows legacy same-party flows to continue functioning with minimal adoption costs involved for site authors. However, it prevents browsers' ability to mediate these flows and potentially intervene on behalf of users. Additionally, Storage Access API is already the preferred mechanism for gaining cross-site cookie access on major browsers such as Safari and Firefox. +Where a Storage Access API invocation is automatically granted due to membership in the same Related Website Set, a similar effect may be achieved by user agents always allowing cross-site cookie access across sites within the same set. Such cookie access may be subject to rules such as [SameSite](https://web.dev/samesite-cookies-explained/), and depend on specification of a cookie attribute such as [SameParty](https://github.com/cfredric/sameparty). This would allow for synchronous cookie access on subresource requests, and, for most part, allows legacy same-party flows to continue functioning with minimal adoption costs involved for site authors. However, it prevents browsers' ability to mediate these flows and potentially intervene on behalf of users. Additionally, Storage Access API is already the preferred mechanism for gaining cross-site cookie access on major browsers such as Safari and Firefox. ## Signed Assertions and set discovery instead of static lists @@ -365,17 +365,17 @@ verification of the legal entity associated with the website a certificate is issued for and encode information about this legal entity in the certificate itself. It might be possible to match this information for sites presenting EV certificates (or use the subjectAltName on a single EV certificate) to build -First-Party Sets. This could be used in place of [Signed Assertions](signed_assertions.md) +Related Website Sets. This could be used in place of [Signed Assertions](signed_assertions.md) as part of a dynamic set discovery mechanism. However, such an automatic mechanism would result in a very tight coupling of -identity and feature exposure through First-Party Sets to the existing certificate +identity and feature exposure through Related Website Sets to the existing certificate infrastructure. It's likely that this would negatively impact the deployment and use of encryption on the web, for example by forcing sites to obtain EV certificates as the only way to ensure continued functionality. A revocation of a certificate -that is used for FPS would have grave implications (such as deletion of all local +that is used for RWS would have grave implications (such as deletion of all local data through the Clear Site Data mechanism) and thus complicate the revocation process. See [Issue 12](https://github.com/privacycg/first-party-sets/issues/12) for an extended @@ -388,28 +388,28 @@ Instead of having a verification entity check that domains in a set match the st - Self-attestation of conformance to the subset definitions by submitter. - Technical consistency checks such as verifying control over domains, and ensuring that no domain appears in more than one set. - Transparency logs documenting all acceptances and deletions to enable accountability and auditability. -- Mechanism/process for the general public to report potential misuse of First-Party Sets. +- Mechanism/process for the general public to report potential misuse of Related Website Sets. -At this time, a verification entity to detect and enforce against abuses of the First-Party Sets technology has not been engaged. This may change in the future. +At this time, a verification entity to detect and enforce against abuses of the Related Website Sets technology has not been engaged. This may change in the future. ## Origins instead of registrable domains -A First-Party Set is a collection of origins, but it is specified by registrable domains, which +A Related Website Set is a collection of origins, but it is specified by registrable domains, which carries a dependency on the [public suffix list](https://publicsuffix.org). While this is consistent with the various proposed privacy models as well as cookie handling, the security boundary on the web is the origin, not registrable domain. An alternate design would be to instead specify sets by origins directly. In this model, any https -origin would be a possible First-Party Set primary, and each origin must individually join a set, +origin would be a possible Related Website Set primary, and each origin must individually join a set, rather than relying on the root as we do here. For continuity with the existing behavior, we would -then define the registrable domain as the default First-Party Set for each origin. That is, by +then define the registrable domain as the default Related Website Set for each origin. That is, by default, `https://foo.example.com`, `https://bar.example.com`, and `https://example.com:444` would all be in a set under `https://example.com`. Defining a set explicitly would override this default set. This would reduce the web's dependency on the public suffix list, which would mitigate [various problems](https://github.com/sleevi/psl-problems). For instance, a university may allow students to register arbitrary subdomains at `https://foo.university.example`, but did not place `university.example` on the public suffix list, -either due to compatibility concerns or oversight. With an origin-specified First-Party Set, +either due to compatibility concerns or oversight. With an origin-specified Related Website Set, individual origins could then detach themselves from the default set to avoid security problems with non-origin-based features such as cookies. (Note the [\_\_Host- cookie prefix](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.3.2) @@ -421,17 +421,17 @@ This origin-defined approach has additional complications to resolve: domains, not origins. Those features should not transitively join two different sets. For instance, we must account for one set containing `https://foo.bar.example.com` and `https://example.com`, but not `https://bar.example.com`. For cookies, we can say that cookies - remember the set which created them and we match both the Domain attribute and the first-party + remember the set which created them and we match both the Domain attribute and the related website set. Thus if `https://foo.bar.example.com` sets a Domain=example.com cookie, `https://example.com` can read it, but not `https://bar.example.com`. Other features would need similar updates. - The implicit state should be expressible explicitly, to simplify rollback and deployment, - which means First-Party Set manifests must describe patterns of origins, rather than a simple + which means Related Website Set manifests must describe patterns of origins, rather than a simple bounded list of domains. In particular, we should support subtree patterns. - `https://foo.example.com`'s implicit primary is `https://example.com`. If `https://example.com` then forms an explicit set which does not include `https://foo.example.com`, we need to change `https://foo.example.com`'s implicit state, perhaps to a singleton set. - This complex set of patterns and implicit behaviors must be reevaluated against existing - origins every time a First-Party Set is updated. + origins every time a Related Website Set is updated. - Certificate wildcards (which themselves depend on the public suffix list) don't match an entire subtree. This conflicts with wanting to express implicit states above. @@ -442,11 +442,11 @@ this is worthwhile. ## Avoid weakening new and existing security boundaries -Changes to the web platform that tighten boundaries for increased privacy often have positive effects on security as well. For example, cache partitioning restricts [cache probing](https://xsleaks.dev/docs/attacks/cache-probing/) attacks and third-party cookie blocking makes it much harder to perform [CSRF](https://owasp.org/www-community/attacks/csrf) by default. Where user agents intend to use First-Party Sets to replace or extend existing boundaries based on *site* or *origin* on the web, it is important to consider not only the effects on privacy, but also on security. +Changes to the web platform that tighten boundaries for increased privacy often have positive effects on security as well. For example, cache partitioning restricts [cache probing](https://xsleaks.dev/docs/attacks/cache-probing/) attacks and third-party cookie blocking makes it much harder to perform [CSRF](https://owasp.org/www-community/attacks/csrf) by default. Where user agents intend to use Related Website Sets to replace or extend existing boundaries based on *site* or *origin* on the web, it is important to consider not only the effects on privacy, but also on security. -Sites in a common FPS may have greatly varying security requirements, for example, a set could contain a site storing user credentials and another hosting untrusted user data. Even within the same set, sites still rely on cross-site and cross-origin restrictions to stay in control of data exposure. Within reason, it should not be possible for a compromised site in an FPS to affect the integrity of other sites in the set. +Sites in a common RWS may have greatly varying security requirements, for example, a set could contain a site storing user credentials and another hosting untrusted user data. Even within the same set, sites still rely on cross-site and cross-origin restrictions to stay in control of data exposure. Within reason, it should not be possible for a compromised site in an RWS to affect the integrity of other sites in the set. -This consideration will always involve a necessary trade-off between gains like performance or interoperability and risks for users and sites. User agents should facilitate additional mechanisms such as a per-origin opt-in or opt-out to manage this trade-off. Site owners should be aware of the potential security implications of creating an FPS and form only the smallest possible set of domains that encompasses user workflows/journeys across an application, especially when some origins in the set opt into features that may leave them open to potential attacks from other origins in the set. +This consideration will always involve a necessary trade-off between gains like performance or interoperability and risks for users and sites. User agents should facilitate additional mechanisms such as a per-origin opt-in or opt-out to manage this trade-off. Site owners should be aware of the potential security implications of creating an RWS and form only the smallest possible set of domains that encompasses user workflows/journeys across an application, especially when some origins in the set opt into features that may leave them open to potential attacks from other origins in the set. # Prior Art @@ -458,7 +458,7 @@ This consideration will always involve a necessary trade-off between gains like # Open question(s) -- We are still exploring how [CHIPS](https://github.com/privacycg/CHIPS) [integrates with](https://developer.chrome.com/docs/privacy-sandbox/chips/#first-party-sets-and-cookie-partitioning) First-Party Sets. We are working on technical changes to that design as well, and will share updates when we have a proposal. +- We are still exploring how [CHIPS](https://github.com/privacycg/CHIPS) [integrates with](https://developer.chrome.com/docs/privacy-sandbox/chips/#first-party-sets-and-cookie-partitioning) Related Website Sets. We are working on technical changes to that design as well, and will share updates when we have a proposal. - While we've proposed a limit of three domains for the "associated" subset, we seek feedback on whether this would be suitable for ecosystem use cases. - We may consider expanding the technical checks, where possible, involved in mitigating abuse (e.g., to validate ccTLD variants). diff --git a/FPS-tester-list.md b/RWS-tester-list.md similarity index 89% rename from FPS-tester-list.md rename to RWS-tester-list.md index 3c15fb4..10450dc 100644 --- a/FPS-tester-list.md +++ b/RWS-tester-list.md @@ -1,6 +1,6 @@ -# First-Party Sets Tester List +# Related Website Sets Tester List -## Ecosystem Testing of First-Party Sets +## Ecosystem Testing of Related Website Sets The purpose of this page is to consolidate testing information which is currently distributed across various GitHub issues, company blogs, social posts, etc. The usefulness of this page depends on testers sharing information and updates. @@ -11,7 +11,7 @@ The usefulness of this page depends on testers sharing information and updates. - Not evaluative. The purpose of this page is to consolidate links to information published by Privacy Sandbox testers. Editors will review submissions for relevance and to ensure general conformance to the guidelines above, but are not evaluating or endorsing the information provided. -- Editors will regularly review and approve submissions that meet the guidelines below. If you believe that an error has been submitted, please create an issue in the First-Party Sets repository with the words '[Tester List]' in the subject and the Editors will respond in short order. +- Editors will regularly review and approve submissions that meet the guidelines below. If you believe that an error has been submitted, please create an issue in the Related Website Sets repository with the words '[Tester List]' in the subject and the Editors will respond in short order. ## Guidelines @@ -27,7 +27,7 @@ The usefulness of this page depends on testers sharing information and updates. ## How to submit -1. On the First-Party Sets GitHub page, navigate to the document in the main table called ‘FPS-tester-list.md’ +1. On the Related Website Sets GitHub page, navigate to the document in the main table called ‘RWS-tester-list.md’ 1. Click the ‘pencil’ icon on the right side to edit the table and add your information 1. Use the | to make sure that the information that you provide correctly shows up in each cell diff --git a/signed_assertions.md b/signed_assertions.md index bcd3560..b26e2a4 100644 --- a/signed_assertions.md +++ b/signed_assertions.md @@ -2,11 +2,11 @@ ## Introduction -In this document, we propose an alternative solution to shipping a static list of all accepted First-Party Set assertions into the browser. The browser vendor, or some entities that it designates, can sign assertions for domains which meet UA policy, using some private key. A signed assertion has the same meaning as membership in a static list: these domains meet the signer’s policy. The browser would trust the signers’ public key and, as above, only accept domains covered by suitable assertions. +In this document, we propose an alternative solution to shipping a static list of all accepted Related Website Set assertions into the browser. The browser vendor, or some entities that it designates, can sign assertions for domains which meet UA policy, using some private key. A signed assertion has the same meaning as membership in a static list: these domains meet the signer’s policy. The browser would trust the signers’ public key and, as above, only accept domains covered by suitable assertions. Assertions are delivered in the `assertions` field, which contains a dictionary mapping from signer name to signed assertion. Browsers ignore unused assertions. This format allows sites to serve assertions from multiple signers, so they can handle policy variations more smoothly. In particular, we expect policies to evolve over time, so browser vendors may wish to run their own signers. Note these assertions solve a different problem from the Web PKI and are delivered differently. However, many of the lessons are analogous. -As with a static list, signers maintain a full list of currently checked domains. They should publish this list at a well-known location, such as `https://fps-signer.example/first-party-sets.json`. Although browsers will not consume the list directly, this allows others to audit the list. The signer may wish to incorporate a [Certificate-Transparency-like](https://tools.ietf.org/html/rfc6962) mechanism for stronger guarantees. +As with a static list, signers maintain a full list of currently checked domains. They should publish this list at a well-known location, such as `https://rws-signer.example/related-website-sets.json`. Although browsers will not consume the list directly, this allows others to audit the list. The signer may wish to incorporate a [Certificate-Transparency-like](https://tools.ietf.org/html/rfc6962) mechanism for stronger guarantees. The signer then regularly produces fresh signed assertions for the current list state. For extensibility, the exact format and contents of this assertion are signer-specific (browsers completely ignore unknown signers, so there is no need for a common format). However, there should be a recommended format to avoid common mistakes. Each signed assertion must contain: @@ -18,42 +18,42 @@ The signer then regularly produces fresh signed assertions for the current list Assertion lifetimes should be kept short, say two weeks. This reduces the lifetime of any mistakes. The browser vendor may also maintain a blocklist of revoked assertions to react more quickly, but the reduced lifetime reduces the size of such a list. -To avoid operational challenges for sites, the signer makes the latest assertions available at a well-known location, such as `https://fps-signer.example/assertions/`. We will provide automated tooling to refresh the manifest from these assertions, and sites with more specialized needs can build their own. To support such automation, the URL patterns must be standard across signers. +To avoid operational challenges for sites, the signer makes the latest assertions available at a well-known location, such as `https://rws-signer.example/assertions/`. We will provide automated tooling to refresh the manifest from these assertions, and sites with more specialized needs can build their own. To support such automation, the URL patterns must be standard across signers. Note any duplicate domains in the assertions and members attribute should compress well with gzip. -# Declaring a First Party Set +# Declaring a Related Website Set -A first-party set is identified by one _owner_ registered domain and a list of _secondary_ registered domains. (See [alternative designs](https://github.com/privacycg/first-party-sets#alternative-designs) for a discussion of origins vs registered domains.) +A related website set is identified by one _owner_ registered domain and a list of _secondary_ registered domains. (See [alternative designs](https://github.com/privacycg/first-party-sets#alternative-designs) for a discussion of origins vs registered domains.) -An origin is in a given first-party set if: +An origin is in a given related website set if: * Its scheme is https; and * Its registered domain is either the owner or is one of the secondary domains. -The browser will consider domains to be members of a set if the domains opt in and the set meets [UA policy](https://github.com/privacycg/first-party-sets#ua-policy), to incorporate both [user and site needs](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies). Domains opt in by hosting a JSON manifest at `https:///.well-known/first-party-set`. The secondary domains point to the owning domain while the owning domain lists the members of the set, a version number to trigger updates, and a set of signed assertions to inform UA policy ([details below](https://github.com/privacycg/first-party-sets#ua-policy)). +The browser will consider domains to be members of a set if the domains opt in and the set meets [UA policy](https://github.com/privacycg/first-party-sets#ua-policy), to incorporate both [user and site needs](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies). Domains opt in by hosting a JSON manifest at `https:///.well-known/related-website-set`. The secondary domains point to the owning domain while the owning domain lists the members of the set, a version number to trigger updates, and a set of signed assertions to inform UA policy ([details below](https://github.com/privacycg/first-party-sets#ua-policy)). -Suppose `a.example`, `b.example`, and `c.example` wish to form a first-party set, owned by `a.example`. The sites would then serve the following resources, with signed assertions served in the `assertions` field of the owner manifest: +Suppose `a.example`, `b.example`, and `c.example` wish to form a related website set, owned by `a.example`. The sites would then serve the following resources, with signed assertions served in the `assertions` field of the owner manifest: ``` -https://a.example/.well-known/first-party-set +https://a.example/.well-known/related-website-set { "owner": "a.example", "version": 1, "members": ["b.example", "c.example"], "assertions": { - "chrome-fps-v1" : "", - "firefox-fps-v1" : "", - "safari-fps-v1": "" + "chrome-rws-v1" : "", + "firefox-rws-v1" : "", + "safari-rws-v1": "" } } -https://b.example/.well-known/first-party-set +https://b.example/.well-known/related-website-set { "owner": "a.example" } -https://c.example/.well-known/first-party-set +https://c.example/.well-known/related-website-set { "owner": "a.example" } ``` @@ -65,56 +65,56 @@ The browser then imposes additional constraints on the owner's manifest: * Entries in `members` that are not registrable domains are ignored. * Only entries in `members` that meet [UA policy](https://github.com/privacycg/first-party-sets#ua-policy) will be accepted. The others will be ignored. If the owner is not covered by UA policy, the entire set is rejected. -## Discovering First Party Sets +## Discovering Related Website Sets -By default, every registrable domain is implicitly owned by itself. The browser discovers first-party sets as it makes network requests and stores the first-party set owner for each domain. On a top-level navigation, websites may send a `Sec-First-Party-Set` response header to inform the browser of its first-party set owner. For example `https://b.example/some/page` may send the following header: +By default, every registrable domain is implicitly owned by itself. The browser discovers related website sets as it makes network requests and stores the related website set owner for each domain. On a top-level navigation, websites may send a `Sec-Related-Website-Set` response header to inform the browser of its related website set owner. For example `https://b.example/some/page` may send the following header: ``` - Sec-First-Party-Set: owner="a.example", minVersion=1 + Sec-Related-Website-Set: owner="a.example", minVersion=1 ``` -If this header does not match the browser's current information for `b.example` (either the owner does not match, or its saved first-party set manifest is too old or does not exist), the browser pauses navigation to fetch the two manifest resources. Here, it would fetch `https://a.example/.well-known/first-party-set` and `https://b.example/.well-known/first-party-set`. +If this header does not match the browser's current information for `b.example` (either the owner does not match, or its saved related website set manifest is too old or does not exist), the browser pauses navigation to fetch the two manifest resources. Here, it would fetch `https://a.example/.well-known/related-website-set` and `https://b.example/.well-known/related-website-set`. These requests must be uncredentialed and with suitably partitioned network caches to not leak cross-site information. In particular, the fetch must not share caches with browsing activity under `a.example`. See also discussion on [cross-site tracking vectors](https://github.com/privacycg/first-party-sets#cross-site-tracking-vectors). -If the manifests show the domain is in the set, the browser records `a.example` as the owner of `b.example` (but not `c.example`) in its first-party-set storage. It evicts all domains currently recorded as owned by `a.example` that no longer match the new manifest. Then it clears all state for domains whose owners changed, including reloading all active documents. This should behave like [Clear-Site-Data: *](https://www.w3.org/TR/clear-site-data/). This is needed to unlink any site identities that should no longer be linked. Note this also means that execution contexts (documents, workers, etc.) are scoped to a particular first-party set throughout their lifetime. If the first-party owner changes, existing ones are destroyed. +If the manifests show the domain is in the set, the browser records `a.example` as the owner of `b.example` (but not `c.example`) in its related-website-set storage. It evicts all domains currently recorded as owned by `a.example` that no longer match the new manifest. Then it clears all state for domains whose owners changed, including reloading all active documents. This should behave like [Clear-Site-Data: *](https://www.w3.org/TR/clear-site-data/). This is needed to unlink any site identities that should no longer be linked. Note this also means that execution contexts (documents, workers, etc.) are scoped to a particular related website set throughout their lifetime. If the set owner changes, existing ones are destroyed. -The browser then retries the request (state has since been cleared) and completes navigation. As retrying POSTs is undesirable, we should ignore the `Sec-First-Party-Set` header directives on POST navigations. Sites that require a first-party set to be picked up on POST navigations should perform a redirect (as is already common), and have the `Sec-First-Party-Set` directive apply on the redirect. +The browser then retries the request (state has since been cleared) and completes navigation. As retrying POSTs is undesirable, we should ignore the `Sec-Related-Website-Set` header directives on POST navigations. Sites that require a related website set to be picked up on POST navigations should perform a redirect (as is already common), and have the `Sec-Related-Website-Set` directive apply on the redirect. -Subresource requests and subframe navigations are simpler as they cannot introduce a new first-party context. If the request’s Sec-First-Party-Set header owner matches the top-level document owner's manifest but is not currently recorded as being in that first-party set, the browser validates membership as above before making the request. Any Sec-First-Party-Set headers are ignored and, in particular, the browser should never read or write state for a first-party set other than the current one. This simpler process also avoids questions of retrying requests. The minVersion parameter in the header ensures that the browser's view of the owner's manifest is up-to-date enough for this logic. +Subresource requests and subframe navigations are simpler as they cannot introduce a new related website context. If the request’s Sec-Related-Website-Set header owner matches the top-level document owner's manifest but is not currently recorded as being in that related website set, the browser validates membership as above before making the request. Any Sec-Related-Website-Set headers are ignored and, in particular, the browser should never read or write state for a related website set other than the current one. This simpler process also avoids questions of retrying requests. The minVersion parameter in the header ensures that the browser's view of the owner's manifest is up-to-date enough for this logic. ## Cross-site tracking vectors -This design requires the browser to remember state about first-party sets, and use that state to influence site behavior. We must ensure this state does not introduce a cross-site tracking vector for two sites _not_ in the same first-party set. For instance, a site may be able to somehow encode a user identifier into the first-party set and have that identifier be readable in another site. Additionally, first-party sets are discovered and validated on-demand, so this could leak information about which sites have been visited. +This design requires the browser to remember state about related website sets, and use that state to influence site behavior. We must ensure this state does not introduce a cross-site tracking vector for two sites _not_ in the same related website set. For instance, a site may be able to somehow encode a user identifier into the related website set and have that identifier be readable in another site. Additionally, related website sets are discovered and validated on-demand, so this could leak information about which sites have been visited. -Our primary mitigation for these attacks is to treat first-party sets as first-party-only state. We heavily restrict how first-party set state interacts with subresources. Thus we never query or write to first-party set information for any set other than the current one. Even if first-party set membership were personalized, that membership should only influence the set itself. +Our primary mitigation for these attacks is to treat related website sets as first-party-only state. We heavily restrict how related website set state interacts with subresources. Thus we never query or write to related website set information for any set other than the current one. Even if related website set membership were personalized, that membership should only influence the set itself. -We can further mitigate personalized first-party sets, as well as information leaks during validation, by fetching manifests without credentials and from appropriate network partitions (double-keyed HTTP cache, etc.). +We can further mitigate personalized related website sets, as well as information leaks during validation, by fetching manifests without credentials and from appropriate network partitions (double-keyed HTTP cache, etc.). -Finally, first-party set state must be cleared whenever other state for some first-party is cleared, such as if the user cleared cookies from the browser UI. +Finally, related website set state must be cleared whenever other state for some related website is cleared, such as if the user cleared cookies from the browser UI. Some additional scenarios to keep in mind: -* The decision to validate a first-party set must not be based on not-yet-readable data, otherwise side channel attacks are feasible. For instance, we cannot optimize the subresource logic to only validate sets if a `SameParty` cookie exists. -* When validating a first-party set from a top-level navigation, it is important to fetch _both_ manifests unconditionally, rather than use the cached version of the owner manifest. Otherwise one site can learn if the user has visited the other by claiming to be in a first-party set and measuring how long the browser took to reject it. -* If two first-party sets jointly own a set of "throwaway" domains (so state clearing does not matter), they can communicate a user identifier in which throwaway domains one set grabs from the other. This can be prevented if UA policy includes each domain in at most one entity. However note that, immediately after a domain changes ownership, policies using signed assertions may briefly accept either of two entities while the old assertions expire. The browser can push a revocation list to clear old assertions faster. Mitigating personalized sets also partially addresses this attack (if not personalized, the sites must coordinate via a global signal like time). +* The decision to validate a related website set must not be based on not-yet-readable data, otherwise side channel attacks are feasible. For instance, we cannot optimize the subresource logic to only validate sets if a `SameParty` cookie exists. +* When validating a related website set from a top-level navigation, it is important to fetch _both_ manifests unconditionally, rather than use the cached version of the owner manifest. Otherwise one site can learn if the user has visited the other by claiming to be in a related website set and measuring how long the browser took to reject it. +* If two related website sets jointly own a set of "throwaway" domains (so state clearing does not matter), they can communicate a user identifier in which throwaway domains one set grabs from the other. This can be prevented if UA policy includes each domain in at most one entity. However note that, immediately after a domain changes ownership, policies using signed assertions may briefly accept either of two entities while the old assertions expire. The browser can push a revocation list to clear old assertions faster. Mitigating personalized sets also partially addresses this attack (if not personalized, the sites must coordinate via a global signal like time). ## Service workers -Service workers complicate first-party sets. We must consider network requests made from a service worker, subresource fetches made from a document with a service worker attached, as well as how a site which uses a service worker may adopt first-party sets. +Service workers complicate related website sets. We must consider network requests made from a service worker, subresource fetches made from a document with a service worker attached, as well as how a site which uses a service worker may adopt related website sets. -Changing a domain's first-party owner clears all state, including service worker registrations. This means service workers, like documents, are scoped to a given first-party set. Network requests from a service worker then behave like subresources. +Changing a domain's set owner clears all state, including service worker registrations. This means service workers, like documents, are scoped to a given related website set. Network requests from a service worker then behave like subresources. -If a document has a service worker attached, its subresource fetches go through the service worker. This does _not_ trigger first-party set logic as this fetch is, at this point, a funny IPC. If the service worker makes a request in response, the first-party set logic will fire as above. +If a document has a service worker attached, its subresource fetches go through the service worker. This does _not_ trigger related website set logic as this fetch is, at this point, a funny IPC. If the service worker makes a request in response, the related website set logic will fire as above. -Finally, if a site already has a service worker, it should still be able to deploy first-party sets. However that service worker effectively translates navigation fetches into subresource fetches, and only top-level navigations discover new sets. We resolve this by moving `Sec-Fetch-Party-Set` header processing to the navigation logic. If the header is present, whether it came from the network directly or the service worker, we attempt to validate the set. This is fine because the header is not directly trusted. +Finally, if a site already has a service worker, it should still be able to deploy related website sets. However that service worker effectively translates navigation fetches into subresource fetches, and only top-level navigations discover new sets. We resolve this by moving `Sec-Related-Website-Set` header processing to the navigation logic. If the header is present, whether it came from the network directly or the service worker, we attempt to validate the set. This is fine because the header is not directly trusted. ## Open questions @@ -125,4 +125,4 @@ Finally, if a site already has a service worker, it should still be able to depl * Should the recommended format include extensions? Too many extension points, particularly around cryptographic algorithms, can introduce complexity and security risks. * Should the assertions treat the owner as distinct from the member domains, or is a flat list sufficient? That is, is the signer’s policy likely to treat the owner distinct from other members? -Extensibility by signer names means formats can always be extended by updating browsers to expect new signers. But we must ensure that this does not increase operational burden on sites by designing the tooling correctly. For instance, the `chrome-fps-v1` and `chrome-fps-v2` signers could share an assertion URL, which provides a set of assertions. The tooling would then automatically include each in the manifest. +Extensibility by signer names means formats can always be extended by updating browsers to expect new signers. But we must ensure that this does not increase operational burden on sites by designing the tooling correctly. For instance, the `chrome-rws-v1` and `chrome-rws-v2` signers could share an assertion URL, which provides a set of assertions. The tooling would then automatically include each in the manifest. diff --git a/spec.bs b/spec.bs index a961856..e16c670 100644 --- a/spec.bs +++ b/spec.bs @@ -1,5 +1,5 @@ 
-Title: User Agent Interaction with First-Party Sets
+Title: User Agent Interaction with Related Website Sets
 Shortname: first-party-sets
 Level: None
 Status: w3c/CG-DRAFT
@@ -8,7 +8,7 @@ URL: https://wicg.github.io/first-party-sets/
 Editor: Chris Fredrickson, Google https://google.com, cfredric@google.com
 Editor: Kaustubha Govind, Google https://google.com, kaustubhag@google.com
 Editor: Johann Hofmann, Google https://google.com, johannhof@google.com
-Abstract: How user agents should integrate with First-Party Sets, a mechanism to declare a collection of related domains as being in a First-Party Set.
+Abstract: How user agents should integrate with Related Website Sets, a mechanism to declare a collection of related domains as being in a Related Website Set.
 Markup Shorthands: markdown yes
 Default Biblio Display: inline
@@ -38,12 +38,12 @@ urlPrefix: https://w3c.github.io/permissions/; spec: permissions { "SUBMISSION-GUIDELINES": { "href": "https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md", - "title": "First-Party Sets Submission Guidelines", + "title": "Related Website Sets Submission Guidelines", "publisher": "Google Chrome" }, - "FPS-LIST": { + "RWS-LIST": { "href": "https://github.com/GoogleChrome/first-party-sets/blob/main/first_party_sets.JSON", - "title": "First-Party Sets list", + "title": "Related Website Sets list", "publisher": "Google Chrome" }, "STORAGE-ACCESS": { @@ -69,9 +69,9 @@ urlPrefix: https://w3c.github.io/permissions/; spec: permissions This section is non-normative. -First-Party Sets (“FPS”) provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the [[STORAGE-ACCESS]]. +Related Website Sets (“RWS”) provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This is facilitated through the use of the [[STORAGE-ACCESS]]. -This document defines how user agents should integrate with the [[FPS-LIST]]. For a canonical reference of the structure of the FPS list and technical validations that are run at time of submission, please see the [[SUBMISSION-GUIDELINES]]. +This document defines how user agents should integrate with the [[RWS-LIST]]. For a canonical reference of the structure of the RWS list and technical validations that are run at time of submission, please see the [[SUBMISSION-GUIDELINES]].

Infrastructure

@@ -79,52 +79,52 @@ This specification depends on the Infra standard. [[!INFRA index]]

List consumption

-User agents should consume the canonical [[FPS-LIST]] on a regular basis (e.g., every 2 weeks) and ship it to individual clients (e.g. a browser application) as an updateable component. +User agents should consume the canonical [[RWS-LIST]] on a regular basis (e.g., every 2 weeks) and ship it to individual clients (e.g. a browser application) as an updateable component. ISSUE(wicg/first-party-sets#122): Can we make a recommendation for an update interval here? -Individual clients must [=build the list of first-party sets=] on restart, or on start-up, if newly downloaded. Clients must not re-build the list at any other point in time. +Individual clients must [=build the list of related website sets=] on restart, or on start-up, if newly downloaded. Clients must not re-build the list at any other point in time. -The FPS list is a [=UTF-8=] encoded file containing contents parseable as a JSON object, conforming to the [[JSON-SCHEMA index]] described in the [[SUBMISSION-GUIDELINES]]. +The RWS list is a [=UTF-8=] encoded file containing contents parseable as a JSON object, conforming to the [[JSON-SCHEMA index]] described in the [[SUBMISSION-GUIDELINES]]. -Note: Conformance to the schema is validated at submission time. Hence, it is not required for the user agent to validate conformance again on the client. The algorithms in this specification describe how user agents should parse the FPS list, and when a particular set should be considered valid from the client’s perspective. +Note: Conformance to the schema is validated at submission time. Hence, it is not required for the user agent to validate conformance again on the client. The algorithms in this specification describe how user agents should parse the RWS list, and when a particular set should be considered valid from the client’s perspective. ISSUE(wicg/first-party-sets#125): Client-side validation may be needed in cases where the [[PSL]] version differs between the server and client. -To build the list of first-party sets from a JSON [=byte sequence=] |bytes|, the user agent should run the following steps: +To build the list of related website sets from a JSON [=byte sequence=] |bytes|, the user agent should run the following steps: 1. Let |json| be the result of [=parse JSON bytes to an infra value|parsing JSON bytes to an infra value=] with |bytes|. 2. If |json| is a parsing exception, or if |json| is not an [=ordered map=], or if |json|[“sets”] does not exist, return and optionally retry fetching the list, or perform other error recovery tasks. 3. For each |entry| of |json|: - 1. Let |set| be a [=first-party set=]. + 1. Let |set| be a [=related website set=]. 2. If |entry|[“primary”] does not exist, continue. ISSUE(wicg/first-party-sets#126): The specification currently suggests skipping invalid sets (missing primary entries) instead of rejecting the entire list. However, there may be benefit in a full rejection given that the server is expected to hold valid information at all times. - 3. Set |set|’s [=first-party set/primary=] to |entry|[“primary”]. + 3. Set |set|’s [=related website set/primary=] to |entry|[“primary”]. 4. Let |ccTLDs| be the result of [=parse an equivalence map|parsing an equivalence map=] from |entry|[“ccTLDs”]. If |ccTLDs| is failure, continue. 5. Set |set|’s ccTLDs to |ccTLDs|. 6. Let |serviceSites| be the result of [=parse a subset|parsing a subset=] from |entry|[“serviceSites”]. If the result is failure, continue. - 7. Set |set|’s [=first-party set/serviceSites=] to |serviceSites|. + 7. Set |set|’s [=related website set/serviceSites=] to |serviceSites|. 8. Let |associatedSites| be the result of [=parse a subset|parsing a subset=] from |entry|[“associatedSites”]. If the result is failure, continue. - 9. Set |set|’s [=first-party set/associatedSites=] to |associatedSites|. - 10. Add |set| to the user agent’s [=list of first-party sets=]. + 9. Set |set|’s [=related website set/associatedSites=] to |associatedSites|. + 10. Add |set| to the user agent’s [=list of related website sets=]. -User agents may opt to pre-process the list into a different format before delivery to the client, e.g. for optimization reasons, as long as they ensure that the client will eventually hold a valid [=list of first-party sets=] as defined in this specification. +User agents may opt to pre-process the list into a different format before delivery to the client, e.g. for optimization reasons, as long as they ensure that the client will eventually hold a valid [=list of related website sets=] as defined in this specification.

Data Structures

-The user agent maintains a global list of first-party sets, which is a [=/list=] of [=first-party sets=]. +The user agent maintains a global list of related website sets, which is a [=/list=] of [=related website sets=]. -A first-party set is a [=/struct=] with the following items: +A related website set is a [=/struct=] with the following items: -primary: A [=site=] that represents the set’s primary domain. +primary: A [=site=] that represents the set’s primary domain. -ccTLDs: An [=equivalence map=], representing the set’s equivalent country-code top level domains that were specified by the submitter. +ccTLDs: An [=equivalence map=], representing the set’s equivalent country-code top level domains that were specified by the submitter. -associatedSites: A [=/list=] of [=sites=] in the associated subset. +associatedSites: A [=/list=] of [=sites=] in the associated subset. -serviceSites: A [=/list=] of [=sites=] in the service subset. +serviceSites: A [=/list=] of [=sites=] in the service subset. Note: For additional context on the meaning of these fields please refer to the [[SUBMISSION-GUIDELINES]]. @@ -158,37 +158,37 @@ To parse an equivalence map from an ordered map |input|, run the foll 7. Set |map|[|keySite|] to |equivalents|. 6. Return |map|. -

Validating first-party set inclusion

+

Validating related website set inclusion

-Under FPS, a [=site=] |site1| is considered equivalent to another [=site=] |site2| given an [=equivalence map=] |equivalents|, if |equivalents|[|site1|] contains |site2| or |equivalents|[|site2|] contains |site1|. +Under RWS, a [=site=] |site1| is considered equivalent to another [=site=] |site2| given an [=equivalence map=] |equivalents|, if |equivalents|[|site1|] contains |site2| or |equivalents|[|site2|] contains |site1|. ISSUE(wicg/first-party-sets#123): Should this be renamed to avoid being confused with a mathematical equivalence relation? -To determine the member type of a given [=site=] |site| in a given [=first-party set=] |set|, run the following steps: +To determine the member type of a given [=site=] |site| in a given [=related website set=] |set|, run the following steps: -1. If |site| is [=equivalent to=] |set|’s [=first-party set/primary=] given |set|’s [=first-party set/ccTLDs=], return “primary”. -2. For each |associatedSite| of |set|'s [=first-party set/associatedSites=]: - 1. If |site| is [=equivalent to=] |associatedSite| given |set|’s [=first-party set/ccTLDs=], return “associated”. -3. For each |serviceSite| of |set|'s [=first-party set/serviceSites=]: - 2. If |site| is [=equivalent to=] |serviceSite| given |set|’s [=first-party set/ccTLDs=], return “service”. +1. If |site| is [=equivalent to=] |set|’s [=related website set/primary=] given |set|’s [=related website set/ccTLDs=], return “primary”. +2. For each |associatedSite| of |set|'s [=related website set/associatedSites=]: + 1. If |site| is [=equivalent to=] |associatedSite| given |set|’s [=related website set/ccTLDs=], return “associated”. +3. For each |serviceSite| of |set|'s [=related website set/serviceSites=]: + 2. If |site| is [=equivalent to=] |serviceSite| given |set|’s [=related website set/ccTLDs=], return “service”. 4. Return “none”. -To find a first-party set for a given [=site=] |site|, run the following steps: +To find a related website set for a given [=site=] |site|, run the following steps: -1. For each |set| of the user agent’s [=list of first-party sets=]: +1. For each |set| of the user agent’s [=list of related website sets=]: 1. Let |type| be the [=determine the member type|member type=] of |site| in |set|. 2. If |type| is not “none”, return |set|. 2. Return null. -Note: The [[SUBMISSION-GUIDELINES]] require that each site can only appear in at most one First-Party set, which is validated at submission time. For this reason, user agents do not need to be concerned with the order of the list of first-party sets when performing these steps. +Note: The [[SUBMISSION-GUIDELINES]] require that each site can only appear in at most one Related Website set, which is validated at submission time. For this reason, user agents do not need to be concerned with the order of the list of related website sets when performing these steps. -Define the limit for associated sites within a single [=first-party set=] to be an [=implementation-defined=] value, which is recommended to be 3. +Define the limit for associated sites within a single [=related website set=] to be an [=implementation-defined=] value, which is recommended to be 3. -Note: This limit is used when [=determine eligibility for an associated site|determining eligibility for an associated site=] to only consider the sites listed at the top of the associated subset. It is meant to discourage abuse and help users and user agents understand why a particular first-party set needs to exist. User agents may choose a different number based on this goal. +Note: This limit is used when [=determine eligibility for an associated site|determining eligibility for an associated site=] to only consider the sites listed at the top of the associated subset. It is meant to discourage abuse and help users and user agents understand why a particular related website set needs to exist. User agents may choose a different number based on this goal. A [=site=] |embeddedSite| is eligible for same-party membership when embedded within a [=site=] |topLevelSite|, if the following steps return true: -1. Let |set| be the result of [=find a first-party set|finding a first-party set=] for |topLevelSite|. +1. Let |set| be the result of [=find a related website set|finding a related website set=] for |topLevelSite|. 2. If |set| is null, return false. 3. Let |topLevelType| be the [=determine the member type|member type=] of |topLevelSite| in |set|. 4. If |topLevelType| is “associated” and the result of [=determine eligibility for an associated site|determining eligibility for an associated site=] given |topLevelSite| and |set| is false, return false. @@ -198,10 +198,10 @@ A [=site=] |embeddedSite| is eligible for same-party membership when 8. If |type| is “associated”, return the result of [=determine eligibility for an associated site|determining eligibility for an associated site=] given |embeddedSite| and |set|. 9. Return true. -To determine eligibility for an associated site given a [=site=] |site| and a [=first-party set=] |set|, run the following steps: +To determine eligibility for an associated site given a [=site=] |site| and a [=related website set=] |set|, run the following steps: -1. If |set|’s [=first-party set/associatedSites=] does not contain |site|, return false. -2. Let |index| be the index of |site| in |set|’s [=first-party set/associatedSites=]. +1. If |set|’s [=related website set/associatedSites=] does not contain |site|, return false. +2. Let |index| be the index of |site| in |set|’s [=related website set/associatedSites=]. 3. If |index| is greater than or equal to the [=limit for associated sites=], return false. 4. Return true. @@ -227,9 +227,9 @@ Modify {{Document/requestStorageAccessFor(requestedOrigin)}} to insert the follo 1. Let |settings| be doc's [=relevant settings object=]. 1. If |settings| and requestedOrigin [=are same-party in an embedding context=], the user agent may [=queue a global task=] on the [=permissions task source=] given global to [=resolve=] p and abort the remaining steps. -

Handling first-party set changes

+

Handling related website set changes

-When a [=site=] |site| leaves a [=first-party set=] as the result of building a new [=list of first-party sets=], user agents must ensure that it does not retain any access to data or shared identifiers held by other sites in the first-party set by running the following steps: +When a [=site=] |site| leaves a [=related website set=] as the result of building a new [=list of related website sets=], user agents must ensure that it does not retain any access to data or shared identifiers held by other sites in the related website set by running the following steps: 1. Assert that |site| is not an [=opaque origin=]. 2. Let |domain| be site’s [=origin/host=]. @@ -241,23 +241,23 @@ When a [=site=] |site| leaves a [=first-party set=] as the result of building a 5. [=Remove a permission store entry|Remove all permission store entries=] for |descriptor|, where key[0] is |site| or key[1] is |origin|. 6. Run additional [=implementation-defined=] steps to ensure that any web-accessible storage is removed from |origin|. -ISSUE(wicg/first-party-sets#124): This section should provide more details on how user agents can figure out when a site leaves an FPS. +ISSUE(wicg/first-party-sets#124): This section should provide more details on how user agents can figure out when a site leaves an RWS.

Privacy Considerations

Provide user transparency and control

-A user agent that uses FPS to infer the relationship between two sites should ensure that its users are informed about this user agent choice and give users the opportunity to view and control choices made by the user agent. +A user agent that uses RWS to infer the relationship between two sites should ensure that its users are informed about this user agent choice and give users the opportunity to view and control choices made by the user agent. -

Ensure compatibility with non-FPS environments

+

Ensure compatibility with non-RWS environments

-Some user agents may choose not to support FPS in specific environments (such as Private Browsing Modes), or at all. All user agents and specifications should be mindful of this in their own API integrations and aim to gracefully fall back to a working solution for users and developers. +Some user agents may choose not to support RWS in specific environments (such as Private Browsing Modes), or at all. All user agents and specifications should be mindful of this in their own API integrations and aim to gracefully fall back to a working solution for users and developers. -For providing access to cross-site cookies, this specification aims to ensure compatibility with non-FPS environments through usage of the [[STORAGE-ACCESS]], which provides developers an interface to handle rejections to the request and gives user agents flexibility to employ mechanisms such as prompts or heuristics as an alternative to FPS. +For providing access to cross-site cookies, this specification aims to ensure compatibility with non-RWS environments through usage of the [[STORAGE-ACCESS]], which provides developers an interface to handle rejections to the request and gives user agents flexibility to employ mechanisms such as prompts or heuristics as an alternative to RWS.

Prevent privacy leaks from list changes

-Developers may submit changes to their sets to add or remove sites. Since membership in a set could provide access to cross-site cookies via automatic grants of the [[STORAGE-ACCESS]], we need to pay attention to these transitions so that they don’t link user identities across all the FPSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one First-Party Set to another when it changes its set membership. While a set member may not always request and be granted access to cross-site cookies, for the sake of simplicity of handling set transitions, we propose to treat such access as always granted. +Developers may submit changes to their sets to add or remove sites. Since membership in a set could provide access to cross-site cookies via automatic grants of the [[STORAGE-ACCESS]], we need to pay attention to these transitions so that they don’t link user identities across all the RWSs they’ve historically been in. In particular, we must ensure that a domain cannot transfer a user identifier from one Related Website Set to another when it changes its set membership. While a set member may not always request and be granted access to cross-site cookies, for the sake of simplicity of handling set transitions, we propose to treat such access as always granted. For this reason, this specification requires user agents to clear any site data and storage-access permissions of a given site when a site is removed from a set, before starting any fetches that rely on those permissions or site data. @@ -267,9 +267,9 @@ Note: Most fetches do not depend on data that needs to be cleared, so user agent

Avoid weakening new and existing security boundaries

-Changes to the web platform that tighten boundaries for increased privacy often have positive effects on security as well. For example, cache partitioning restricts [[CACHE-PROBING]] attacks and third-party cookie blocking makes it much harder to perform [[CSRF]] by default. Where user agents intend to use First-Party Sets to replace or extend existing boundaries based on site or origin on the web, it is important to consider not only the effects on privacy, but also on security. +Changes to the web platform that tighten boundaries for increased privacy often have positive effects on security as well. For example, cache partitioning restricts [[CACHE-PROBING]] attacks and third-party cookie blocking makes it much harder to perform [[CSRF]] by default. Where user agents intend to use Related Website Sets to replace or extend existing boundaries based on site or origin on the web, it is important to consider not only the effects on privacy, but also on security. -Sites in a common FPS may have greatly varying security requirements, for example, a set could contain a site storing user credentials and another hosting untrusted user data. Even within the same set, sites still rely on cross-site and cross-origin restrictions to stay in control of data exposure. Within reason, it should not be possible for a compromised site in an FPS to affect the integrity of other sites in the set. +Sites in a common RWS may have greatly varying security requirements, for example, a set could contain a site storing user credentials and another hosting untrusted user data. Even within the same set, sites still rely on cross-site and cross-origin restrictions to stay in control of data exposure. Within reason, it should not be possible for a compromised site in an RWS to affect the integrity of other sites in the set. This consideration will always involve a necessary trade-off between gains like performance or interoperability and risks for users and sites. User agents should facilitate additional mechanisms such as a per-origin opt-in or opt-out to manage this trade-off.