Related Website Sets – the new name for First-Party Sets in Chrome 117

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.