Wiki · Concept · Last reviewed June 25, 2026

Related Website Sets

Related Website Sets are a browser mechanism for declaring that several domains belong together, so user agents can make limited cross-site storage decisions for user-facing purposes.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, cookies, Storage Access API, domain relationships, surveillance

Definition

Related Website Sets, or RWS, are a web-platform proposal for declaring relationships among domains. The WICG draft says RWS lets developers declare related sites so user agents can allow limited access to cross-site data, such as cookies, for user-facing purposes. Google Privacy Sandbox describes the same mechanism as a way for a company to declare relationships among sites so browsers can make decisions about limited cross-site data access.

The older name was First-Party Sets. The rename matters because "first party" can sound like a legal or privacy conclusion, while RWS is only a technical declaration that a browser may use. A shopping brand, media company, identity provider, or service operator may have multiple domains. RWS asks the browser to recognize some of those domains as related when storage access would otherwise be blocked.

Status is not stable. The WICG draft is a Community Group Report, not a W3C Standard. Google announced on October 17, 2025 that Related Website Sets, including requestStorageAccessFor and Related Website Partition, would be retired as part of changes to Privacy Sandbox technologies. Any current deployment claim should therefore name the browser, version, list source, and fallback.

Mechanism

An RWS declaration has a primary site and member sites. The WICG data structure includes a primary site, equivalent country-code top-level domains, associated sites, and service sites. The submission guidelines define requirements for the public Related Website Sets list that Chrome consumes, and the WICG draft says user agents should regularly consume that canonical list and ship it to clients as an updateable component.

RWS is tied to the Storage Access API. MDN describes the Storage Access API as a way for cross-site content in an iframe to request access to third-party cookies and unpartitioned state. MDN also says Chrome can automatically grant access and skip prompts if the embedded content and embedding site are part of the same related website set.

The RWS-specific extension is Document.requestStorageAccessFor(), which lets a top-level site request third-party cookie access on behalf of embedded content from another site in the same set. MDN marks that method as a non-standard deprecated extension. A serious implementation record should also track storage-access headers, the storage-access Permissions Policy directive, sandbox tokens, and user interaction requirements.

Agent Context

For AI Browsers and Computer Use, RWS matters because an agent may navigate across domains that the browser treats as related even though the page addresses look separate to the user. A booking agent, shopping agent, media assistant, or account-recovery helper may encounter embedded widgets whose cookie access depends on a set declaration rather than a visible login flow.

Agent logs should distinguish page navigation from browser-mediated storage access. A successful embedded session does not necessarily mean the user explicitly authorized a fresh cross-site data flow. It may mean the browser recognized a relationship from the RWS list, applied a Storage Access API rule, or used a previously granted permission.

Governance Use

A review record should name the primary site, associated sites, service sites, ccTLD mappings, public list entry, well-known files, submission rationale, browser behavior, Storage Access API calls, and fallback path outside RWS. It should also record who controls each domain and whether the relationship would be clear to an ordinary user.

The topic belongs beside Storage Access API, Permissions Policy, Private State Tokens, Attribution Reporting API, Shared Storage API, Fenced Frame API, and Topics API. Each page describes a different way browsers mediate identity, storage, ads, measurement, and privacy promises.

Limits

RWS is not consent, corporate accountability, or proof that sites are meaningfully the same from a user's point of view. It can reduce breakage for legitimate multi-domain services, but it can also blur a browser privacy boundary that users may reasonably expect between different site names. The main governance question is who gets to define relatedness: the company, the browser, a public list process, or the user.

The retirement plan is also a warning. A browser privacy feature can acquire documentation, submission rules, demos, and enterprise planning, then become scheduled for removal after a platform strategy changes. Audits should treat RWS as policy-dependent infrastructure, not a durable standard.

Review Record

Source Discipline

Claims about the RWS data model, list consumption, same-party logic, and standards status should cite the WICG report. Claims about Chrome integration and developer workflow should cite Google Privacy Sandbox and the Chrome submission guidelines. Claims about Storage Access API behavior and deprecation of requestStorageAccessFor() should cite MDN. Claims about retirement should cite Google's October 17, 2025 Privacy Sandbox update.

Spiralist Reading

Spiralism reads Related Website Sets as a lesson in institutional naming. A browser boundary can be softened by a declaration that two domains are related. Sometimes that helps the user; sometimes it helps the institution preserve continuity across addresses. The record should ask whether the relationship is visible, necessary, revocable, and understandable to the person whose browser is asked to remember it.

Sources

Return to Wiki