diff --git a/README.md b/README.md index b8e653c..de16218 100644 --- a/README.md +++ b/README.md @@ -25,12 +25,12 @@ of the [Privacy Community Group](https://privacycg.github.io/). - [Non-goals](#non-goals) - [Use Cases](#use-cases) - [Applications](#applications) -- [Site-Declared Sets in Browsers](#site-declared-sets-in-browsers) -- [Acceptance Process](#acceptance-process) - - [Submission](#submission) - - [UA Policy](#ua-policy) - - [Verification Entity](#verification-entity) - - [Administrative controls](#administrative-controls) +- [Proposal](#proposal) + - [Defining a "set" through use case-based "subsets"](#defining-a-set-through-use-case-based-subsets) + - [Abuse mitigation measures](#abuse-mitigation-measures) + - [Leveraging the Storage Access API](#leveraging-the-storage-access-api) + - [Extending the Storage Access API](#extending-the-storage-access-api) + - [Administrative Controls](#administrative-controls) - [UI Treatment](#ui-treatment) - [Domain Schemes](#domain-schemes) - [Clearing Site Data on Set Transitions](#clearing-site-data-on-set-transitions) @@ -43,8 +43,6 @@ of the [Privacy Community Group](https://privacycg.github.io/). - [Avoid weakening new and existing security boundaries](#avoid-weakening-new-and-existing-security-boundaries) - [Prior Art](#prior-art) - [Acknowledgements](#acknowledgements) -- [Appendix](#appendix) - - [SameParty Cookies and First-Party Sets](#sameparty-cookies-and-first-party-sets) @@ -59,23 +57,19 @@ 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. -One natural scope is the domain name in the top-level origin. However, the website the user is -interacting with may be deployed across multiple domain names. For example, `https://google.com`, -`https://google.co.uk`, and `https://youtube.com` are owned by the same entity, as are `https://apple.com` -and `https://icloud.com`, or `https://amazon.com` and `https://amazon.de`. +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. -We may wish to allow user identity to span related origins, where consistent with privacy requirements. For -example, Firefox ships an [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list) -that defines lists of domains belonging to the same organization. This explainer -discusses a mechanism to allow organizations to each declare their own list of domains, which is -then accepted by a browser if the set conforms to its policy. +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)). + +There are two key components to the proposal: + +- The framework governing how relationships between domains may be declared, and +- The method by which the browser may manage cross-domain cookie access based on the declared relationship between domains. # Goals -- Allow related domain names to declare themselves as the same first-party. -- Develop a coherent definition of "first-party" vs "third-party" for privacy mechanisms on the web platform. -- Allow for browsers to understand the relationships between domains of multi-domain sites such that they can effectively present that information to the user. +- Allow for browsers to understand the relationships between domains of multi-domain sites such that they can make decisions on behalf of the user and/or effectively present that information to the user. - Uphold existing web security principles such as the [Same Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy). @@ -88,7 +82,7 @@ then accepted by a browser if the set conforms to its policy. - Define specific UI treatment. (Some of these use cases are covered by [other -explainers](https://www.chromium.org/Home/chromium-privacy/privacy-sandbox) from the Privacy +explainers](https://privacysandbox.com/intl/en_us/open-web/#proposals-for-the-web) from the Privacy Sandbox.) # Use Cases @@ -113,18 +107,17 @@ On the modern web, sites span multiple domains and many sites are owned & operat **Note:** The above have been provided only to serve as real-world illustrative assumed examples of collections of domains that are owned by the same organization; and have not all been validated with the site owners. -Without compatibility measures such as Firefox and Edge browsers’ use of [Disconnect.me’s Entities list](https://github.com/disconnectme/disconnect-tracking-protection/blob/master/entities.json), blocking cross-site communication mechanisms such as access to third-party cookies breaks many first-party use-cases. - -First-Party Sets is a proposal to standardize a mechanism that solves this issue in a coherent way by declaring a collection of domains as being part of the same site or 'party'; so that they can be treated as one _privacy boundary_. This allows for browsers to enable protections against tracking across this privacy boundary, and ensures continued operation of existing functionality which would otherwise be broken by blocking cross-domain cookies (“third-party cookies”). It would support seamless operation of functionality such as: +This proposal anchors on the use cases described above to develop a framework for the browser to support limited cross-domain cookie access. This will allow browsers to ensure continued operation of existing functionality that would otherwise be broken by blocking cross-domain cookies ("third-party cookies"), and will support the seamless operation of functionality such as: - Sign-in across owned & operated properties - bbc.com and bbc.co.uk + - Websites may also consider using the FedCM API for single sign-on functionality, if the relevant login flows can be encapsulated with the API's supported [use cases](https://fedidcg.github.io/FedCM/#use-cases). - sony.com and playstation.com - Support for embedded content from across owned & operated properties (e.g. videos/documents/resources restricted to the user signed in on the top-level site) - Separation of user-uploaded content from other site content for security reasons, while allowing the sandboxed domain access to authentication (and other) cookies. For example, Google sequesters such content on googleusercontent.com, GitHub on githubusercontent.com, CodePen [on](https://blog.codepen.io/2019/10/03/changed-domains-for-iframe-previews/) cdpn.io. Hosting untrusted, compromised content on the same domain where a user is authenticated may result in attackers’ potentially capturing authentication cookies, or login credentials (in case of password managers that scope credentials to domains); and cause harm to users. - - Alternative solution: Sandboxed domains can also consider using [partitioned cookies](https://github.com/WICG/CHIPS). + - Alternative solution: Sandboxed domains can also consider using [partitioned cookies](https://github.com/WICG/CHIPS), if their user flows do not involve the sandboxed domain appearing in top-level contexts. - Shared services, such as consent management across domains with a common eTLD suffix; such as gov.uk. Repeatedly asking for cookie consent on individual gov.uk sites may be confusing to users, erode trust in the website’s functioning, and cause fatigue; because users think of all subdomains as being part of one gov.uk website. - Analytics/measurement of user journeys across O&O properties to improve quality of services. @@ -138,63 +131,163 @@ In support of the various browser privacy models, first-party sets only control - Applying [Privacy Budget](https://github.com/bslassey/privacy-budget) across an entire First-Party Set, in order to prevent fingerprinting entropy from being accumulated across domains that are able to communicate in an unconstrained manner due to access to cross-domain, same-party cookies. - Top and/or second level key for cache partitioning, potentially with site opt-in. -# Site-Declared Sets in Browsers - -Browsers should maintain a static list of site-declared groups of domains which meet UA ([User Agent](https://www.w3.org/WAI/UA/work/wiki/Definition_of_User_Agent)) policy, and ship it in the browser as a reliably updateable component. This is analogous to the list of [domains owned by the same entity](https://github.com/disconnectme/disconnect-tracking-protection/blob/master/entities.json) used by Edge and Firefox to control cross-site tracking mitigations. - -The differences between this proposal and the use of the [Disconnect entities list](https://github.com/disconnectme/disconnect-tracking-protection/blob/master/entities.json) in Edge and Firefox are: - -* **All sites** with use-cases that depend on cross-domain, same-party communication will be required to declare a set for the corresponding group of sites. As opposed to the Disconnect list, which only applies to sites [classified as a tracker](https://github.com/disconnectme/disconnect-tracking-protection/blob/master/services.json). -* Site authors must submit their First-Party Set declarations for acceptance (see [UA Policy](#ua-policy) for proposed documented criteria). -* Sets will expire after a prescribed period of time, and be required to undergo renewal. This prevents sets from becoming stale, in case domain ownership changes. -* Each set is indicated by the owner site, and member sites. - - ``` - { owner: "https://fps-owner.example", - members: ["https://fps-member1.example", - "https://fps-member2.example"]} - - ``` - -Technical consistency and freshness checks must be performed on the list: - -* No domain can appear in more than one set. -* Expired sets must be removed. - -A different approach that does not involve consumption of a static list is discussed in the [Alternative designs section](#signed-assertions-and-set-discovery-instead-of-static-lists) - -# Acceptance Process - -This section proposes a possible model for a First-Party Set acceptance process that could be shared across all browsers. However, many aspects of the process and policy will need to be tuned based on feedback from the web ecosystem. - -## Submission - -Sites will need to submit their proposed group of domains to a public tracker (such as a dedicated GitHub repository, like that of the [Public Suffix List](https://github.com/publicsuffix/list/wiki/Guidelines), and [Disconnect’s entities list](https://github.com/disconnectme/disconnect-tracking-protection/issues?q=is%3Aissue+%22entity%22+)), along with information needed to satisfy the UA policy. Technical verification of the submitter’s control over the domains may also require a challenge to be served at a `.well-known` location on each of the domains in the set. - -## UA Policy - -For a set of guiding principles in defining UA policy, we can look to how the various browser proposals describe first parties (emphasis added): +# 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." + +## Defining a "set" through use case-based "subsets" + +Throughout the evolution of this proposal, we considered how to define a single boundary that could determine set inclusion. However, formulating a definition or set of criteria that can both acknowledge the complex multi-domain dependence of websites and preserve a limited privacy boundary proved to be challenging. Instead of using a single definition or set of criteria to apply to a range of [use cases](#use-cases), we propose granular criteria and handling to be applied by use case by specifying "subsets." + +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*) like ccTLDs or common eTLDs; 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: + +**Set primary:** exampleA.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+Subset type
+Subset definition
+Example

+ccTLD (country code Top Level Domain)
+Reserved for variations for a particular country or a geographical area.
+
+
+Requires common ownership.
+exampleA.co.uk
+
+exampleA.ca

+common eTLD (effective Top Level Domain)
+Reserved for domains that share a common eTLD as the set primary. These are not IANA-managed TLDs, but domains added to the PSL for improved security isolation.
+
+
+Requires common ownership.
+exampleA.gov.uk
+
+exampleB.gov.uk

+service
+Reserved for utility or sandbox domains.
+
+
+Requires common ownership.
+exampleA-usercontent.com
+
+exampleA-cdn.net

+associated
+Reserved for domains whose affiliation with the set primary is clearly presented to users (e.g., an About page, header or footer, shared branding or logo, or similar forms).
+exampleA-affiliated.com
+
+exampleB.com*
+
+exampleC.com*
+
+
+*where exampleB and exampleC are separately owned websites, but clearly present their affiliation with exampleA to users
+ +While we think this subset framework has the clear benefit of furthering transparency around why a domain has been added to a set, the primary value to this framework is that the browser could handle each subset differently: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Subset typeSubset definitionExample browser handling policy
ccTLD (country code Top Level Domain)Reserved for variations for a particular country or a geographical area.
+
+Requires common ownership.		No limit on domains, auto-grant access
common eTLD (effective Top Level Domain)Reserved for domains that share a common eTLD as the set primary. These are not IANA-managed TLDs, but domains added to the PSL for improved security isolation.
+
+Requires common ownership.		No limit on domains, auto-grant access
serviceReserved for utility or sandbox domains.
+
+Requires common ownership.		No limit on domains, auto-grant access. Not allowed to be the top-level domain in a storage access grant.
associatedReserved for domains whose affiliation with the set primary is clearly presented to users (e.g., an About page, header or footer, shared branding or logo, or similar forms).Limit of 3* domains. If greater than 3, auto-reject access.
+
+*[^1]exact number TBD
+ +### Abuse mitigation measures + +We consider using a public submission process (like a GitHub repository) to be a valuable approach because it facilitates our goal to keep all set submissions public and submitters accountable to users, civil society, and the broader web ecosystem. For example, a mechanism to report potentially invalid sets may be provisioned. We expect public accountability to be a significant deterrent for intentionally miscategorized subsets. + +The following technical checks also help to mitigate abuse: + +- Mutual exclusivity to ensure a domain isn't part of multiple First-Party 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 + +Additionally, there are other enforcement strategies we could consider to further mitigate abuse. If there is a report regarding a domain specified under the "service" subset, potential reactive enforcement measures could be taken to validate that the domain in question is indeed a "service" subset. + +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. + +## 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. + + 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. + +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: + +### Extending 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 an extension to the SAA](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 this 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/). -- [A Potential Privacy Model for the Web (Chromium Privacy Sandbox)](https://github.com/michaelkleber/privacy-model/blob/master/README.md): "The notion of "First Party" may expand beyond eTLD+1, e.g. as proposed in First Party Sets. It is _reasonable for the browser to relax its identity-sharing controls_ within that expanded notion, provided that the resulting identity scope is _not too large_ and _can be understood by the user_." -- [Edge Tracking Protection Preview](https://blogs.windows.com/msedgedev/2019/06/27/tracking-prevention-microsoft-edge-preview/): "Not all organizations do business on the internet using just one domain name. In order to help keep sites working smoothly, we group domains _owned and operated by the same organization_ together." -- [Mozilla Anti-Tracking Policy](https://wiki.mozilla.org/Security/Anti_tracking_policy): "A first party is a resource or a set of resources on the web _operated by the same organization_, which is both _easily discoverable by the user_ and _with which the user intends to interact_." -- [WebKit Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/): "A first party is a website that a user is intentionally and knowingly visiting, as displayed by the URL field of the browser, and the set of resources on the web _operated by the same organization_." and, under "Unintended Impact", "Single sign-on to multiple websites _controlled by the same organization_." - -In addition, the DNT specification [defines “party” as](https://www.w3.org/TR/tracking-dnt/#terminology.participants): “a natural person, a legal entity, or a set of legal entities that share _common owner(s), common controller(s)_, and a group identity that is _easily discoverable by a user_.” - -We propose the following high level policy as an initial version for discussion, subject to change based on ecosystem feedback: - -- Domains must have a common owner, and common controller. -- Domains must share a common group identity that is easily observable by users. -- Domains must share a common privacy policy that is surfaced to the user via [UI treatment](#ui-treatment). - -We expect the UA policy to evolve over time as use cases and abuse scenarios come up. For instance, otherwise unrelated sites forming a consortium in order to expand the scope of their site identities would be considered abuse. - -## Verification Entity - -An independent entity must verify that submissions conform to the documented UA policy before acceptance. The entity must also assign an expiration date, following which sets are removed from the browser-baked static lists. - -The possibility of purely technical enforcement without a verification entity is discussed in the [Alternative Designs section](#self-attestation-and-technical-enforcement). ## Administrative controls @@ -222,7 +315,7 @@ In accordance with the [Fetch](https://fetch.spec.whatwg.org/#websocket-opening- 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 can change which First-Party Set they are a member of. 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. +Sites can change which First-Party Set they are a member of, for example through acquisition or divestiture. 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. In order to achieve this, site data needs to be cleared on certain transitions. The clearing should behave like [`Clear-Site-Data: "*"`](https://www.w3.org/TR/clear-site-data/#grammardef-), which includes cookies, storage, cache, as well as execution contexts (documents, workers, etc.). We don’t differentiate between different types of site data because: @@ -280,6 +373,10 @@ h. & i. Given the FPS with owner Site A and member Site B and Site C, if Site D # 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. + ## Signed Assertions and set discovery instead of static lists Static lists are easy to reason about and easy for others to inspect. At the same time, they can develop deployment and scalability issues. Changes to the list must be pushed to each user's browser via some update mechanism. This complicates sites' ability to deploy new related domains, particularly in markets where network connectivity limits update frequency. They also scale poorly if the list gets too large. @@ -388,29 +485,15 @@ This consideration will always involve a necessary trade-off between gains like and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) from John Wilander to public-webappsec -# Acknowledgements - - This proposal includes significant contributions from previous co-editor, [David Benjamin](https://github.com/davidben). - - We are also grateful for contributions from [Chris Fredrickson](https://github.com/cfredric) and [Shuran Huang](https://github.com/shuranhuang). - - # Appendix - - ## SameParty Cookies and First-Party Sets - -Sites may annotate individual cookies to be sent across same-party, cross-domain contexts by using the proposed [SameParty cookie attribute](https://github.com/cfredric/sameparty). - -To illustrate the above use cases, we'll suppose that https://member1.example and https://member2.example are in the same first-party set, and consider the following two pages. +# Open question(s) -![Cross-party and same-party embeddings](images/party_embeddings.png) +- 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. +- 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 the ccTLD and common eTLD subset categories). -On browsers where cross-site tracking protections are enabled, the first page, case *a*, is hosted on a third-party domain (`https://other.example`) and embeds an iframe from `https://member1.example`. We say that this iframe is in a *cross-party context*, since the top-level frame's domain is not in the same first-party set as the embedded iframe's domain. The second page, case *b*, is hosted on `https://member2.example`, and also embeds an iframe from `https://member1.example`. We say that this iframe is in a *same-party context*, since the top-level frame's domain is in the same first-party set as the iframe's domain. The aforementioned uses of first-party sets aim to grant a site access to its own state (e.g. cookies) when in a same-party context (case *b*), while blocking access when in a cross-party context (case *a*). - -* In case *a*, `https://member1.example`'s `SameParty` cookie is *not* sent in the iframe's subresource request, since the iframe is in a cross-party context. -* In case *b*, `https://member1.example`'s `SameParty` cookie *is* sent in the iframe's subresource request, since the iframe is in a same-party context. - -Note that First-Party Sets does *not* grant access to one domain's state to any other domain, regardless of the context, in this example. I.e., neither `https://other.example` nor `https://member2.example` ever have access to `https://member1.example`'s cookies. - -The above example (where access to a domain's own cookies is granted when embedded in certain domains, but is disallowed when embedded in others) is not possible without a proposal like First-Party Sets. +# Acknowledgements -This proposal is consistent with the same-origin policy. That is, Web Platform features must not use first-party sets to make one origin's state directly accessible to another origin in the set. For example, if a.example and b.example are in the same first-party set, the same-origin policy would still prevent `https://a.example` from accessing `https://b.example`'s cookies or IndexedDB databases. +- Other members of the W3C Privacy Community Group had previously suggested the use of SAA, or an equivalent API; in place of SameParty cookies. Thanks to @jdcauley ([1](https://github.com/WICG/first-party-sets/issues/14#issuecomment-785144990)), @arthuredelstein ([2](https://github.com/WICG/first-party-sets/issues/42)), and @johnwilander ([3](https://lists.w3.org/Archives/Public/public-privacycg/2022Jun/0001.html)). +- Browser vendors, web developers, and members of the web community provided valuable feedback during this proposal's incubation in the W3C Privacy Community Group. +- This proposal includes significant contributions from previous co-editor, David Benjamin. +- We are also grateful for contributions from Chris Fredrickson and Shuran Huang. diff --git a/ua_policy_proposal.md b/archive/ua_policy_proposal.md similarity index 98% rename from ua_policy_proposal.md rename to archive/ua_policy_proposal.md index 71bc21d..94bf5bf 100644 --- a/ua_policy_proposal.md +++ b/archive/ua_policy_proposal.md @@ -1,3 +1,5 @@ +**This proposal has been archived, and further development has been paused.** + # UA Policy Proposal First-Party Sets aims to define the notion of "first-party" as a technical construct that can be used by browsers in development of tracking protections in browsers. [The W3C Do Not Track (DNT) specification defines a ‘party'](https://www.w3.org/TR/tracking-compliance/#party) as having: