Many Privacy Sandbox APIs are ramping up to General Availability (GA) in Chrome Stable in preparation for third-party cookie deprecation beginning in 2024. Some of these APIs will help preserve crucial cross-site cookie use cases, like CHIPS, and the API currently known as First-Party Sets (FPS). In this post, we introduce Related Website Sets (RWS)—our new name for FPS that better reflects its purpose—and provide a refresher on key use cases along with an update on the associated subset domain limit.
Preserving critical user journeys
RWS is designed to minimize disruptions to specific user-facing features once Chrome starts limiting access to third-party cookies by default. Our goal is to allow users to browse the web with minimal disruption while still upholding the privacy goals of the Privacy Sandbox. To strike this balance, RWS targets specific use cases related to website functionality:
- The ccTLD use case addresses breakages like the login example filed in our public tracker. Such cases are often addressed in the ecosystem through heuristic-based exceptions (See ref 1).
- The service domain use case addresses a common developer practice to isolate sensitive functions (like supporting an authentication flow) from user-facing domains. Such cases may be addressed in the ecosystem through targeted exceptions (See ref 2).
- The associated domain use case provides more flexibility for the types of domains that may require third-party cookie access for critical user journeys (See ref 3). While the ccTLD and service domain use cases employ strict technical checks based on domain characteristics to minimize abuse, the associated domain uses a numeric limit. Read more about this in the next section.
Associated domain limit increased to five domains
Chrome previously proposed a numeric limit of three domains for the Associated Subset (plus one primary domain), in alignment with our objective to prevent widespread tracking abuse. We have heard feedback from web standards participants that the limit was too low for different types of use cases.
We have decided to increase the associated domain limit to five domains (plus one primary domain) which best matches the most comparable implementation offered by another major browser (See ref 4). This will take effect beginning in Chrome 117.
Since RWS is not intended as an ads solution, we are not taking into consideration feedback on how to improve RWS to better serve ads use cases. For ads use cases, developers should explore using the Topics, Protected Audience, and Attribution Reporting APIs and provide feedback on them accordingly.
Users have a choice for extended use cases, beyond five associated domains
For user-impacting experiences that are not supported by this limit, Chrome is working on a user prompting flow that also leverages the Storage Access API (SAA), a standard adopted by other browsers. For use cases that need more than five associated domains, we encourage developers to evaluate how SAA may be supported in non-RWS contexts. We are following the Blink launch process separately for this feature, which will be rolling out in Chrome Desktop beginning in Chrome 117.
Next steps
We're grateful for the ecosystem feedback that has helped shape the API so far. We have invested in RWS as a method of providing developers predictability, control, and agency in preserving the end user experience of the websites they build. We are excited to see how developers adopt and use RWS as we ramp up. The submission process is currently live, and the RWS JSON generator tool is a great starting point to help with submissions.
Follow the Intent to Ship thread to track progress, and check out these materials for implementation guidance.
References
- There is general agreement across browsers that these cross-site cookie use-cases are necessary, but they have taken different approaches in enabling them. Firefox (code) and Safari (code) have both implemented the pop-up heuristic that addresses the breakage observed, for example in the Nintendo login flow.
- There are also multiple examples where browsers hard code exceptions to minimize disruption for users. Firefox grants storage access on redirect flows between Microsoft Teams and login.microsoftonline.us.
- Firefox provides a "shim" that will call requestStorageAccessForOrigin on behalf of facebook.com when the user logs in on instagram.com. An example of site grouping can also be seen in Safari's hard coded exceptions to group storage access prompts for multiple domains.
- Firefox autogrants the first 5 requestStorageAccess calls made by a third-party site (code) that the user has visited before. In Chrome, the first five domains listed in the associated subset in addition to the same set's primary domain will have autogranted third-party cookie access through RWS.