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 Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: 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 or W3C Standards Track document. 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.

Snapshot

Current Context

As of June 25, 2026, RWS should be treated as discontinued Chrome Privacy Sandbox infrastructure and live web-platform history, not as a durable cross-browser privacy standard. Google's RWS overview and developer guide still explain the mechanism, but both now point to the Privacy Sandbox retirement update, and the developer guide says new RWS submissions are no longer accepted.

The retirement followed a broader October 17, 2025 Google update that listed RWS, requestStorageAccessFor, and Related Website Partition among the Privacy Sandbox technologies being retired after ecosystem feedback and low adoption. That does not erase old deployments, tests, documentation, enterprise policies, or browser flags, but it changes the source discipline: current claims should distinguish historical design, Chrome behavior at a specific version, and future fallback plans.

The strongest policy lesson is not that all multi-domain continuity is illegitimate. It is that browser privacy boundaries can be weakened through list governance, developer declarations, and UI assumptions that ordinary users may not understand. The RWS episode belongs beside CHIPS, Storage Access API, and FedCM as one proposed answer to the third-party-cookie transition, not as the answer.

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.

Chrome's developer guide makes two boundaries explicit. RWS did not provide implicit unpartitioned cookie access by default: an embedded frame still had to call requestStorageAccess(), or the top-level page had to call requestStorageAccessFor(). RWS also did not perform cross-site communication or move one site's cookies into another site's cookie jar; any data transfer still required some separate application mechanism.

The WICG draft also treats list governance as part of the mechanism. A site should appear in at most one set, and the draft recommends an implementation-defined limit of three associated sites to discourage abuse and keep the relationship understandable. Those constraints matter because the list is not just documentation; it can change how a browser applies privacy friction.

Boundary Tests

Not consent. A related-site declaration is not proof that a person understood or accepted a new cross-site data flow.

Not common ownership in every case. The RWS model included associated sites, where the claim was clear affiliation rather than strict common ownership.

Not CHIPS. CHIPS partitions a cookie by top-level site. RWS was about easing access to unpartitioned state among declared related sites.

Not FedCM. Federated Credential Management mediates federated login through the browser. RWS was a domain-relationship list used with storage-access decisions.

Not a cross-browser guarantee. The WICG report is incubation work, and Google's Chrome-specific docs cannot establish Safari, Firefox, Brave, or Edge behavior without separate implementation evidence.

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.

Because RWS reduced friction around storage access, it is especially important for agentic browsers not to treat a working embedded session as evidence of user intent. A browser agent should record the top-level site, embedded origin, storage-access method, permission result, and visible user gesture before relying on restored state for purchases, account changes, messages, or identity flows.

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.

After retirement, governance review should also ask what replaced the RWS path: partitioned cookies, ordinary Storage Access API prompts, FedCM, first-party login redirects, server-side account linking, or simple removal of cross-site continuity. A discontinued privacy mechanism can leave behind assumptions in product design long after the browser feature is gone.

Failure Modes

Relatedness overclaim. A company presents RWS membership as if it proved common ownership, consent, or a user's expectation that data would flow across the sites.

Invisible continuity. A user or agent sees separate domain names while an embedded frame regains session state because the browser treats the sites as related.

Associated-site confusion. A set includes an affiliated but not commonly owned associated site, making the relationship harder for users to infer from branding alone.

Stale dependency. A service still depends on RWS behavior after submissions have closed or the relevant Chrome path is removed.

Prompt laundering. Product copy says there is no permission prompt, but fails to explain that reduced friction is itself a policy decision made by the browser and list.

Agent audit gap. Logs record only a successful action, not the storage-access event or set membership that changed the embedded session state.

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.

Empirical work presented at ACM IMC 2024 tested whether users could determine site relatedness and found many privacy-harming errors, including cases where participants thought sites were unrelated even though RWS would treat them as related. That finding supports a cautious reading: user-facing labels, browser UI, and audit records matter because institutional relatedness is not reliably obvious.

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, member types, associated-site limits, 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 and the current Privacy Sandbox status materials.

Claims about user understanding should cite empirical work separately from browser documentation. A developer guide can explain what Chrome intended; it cannot prove that ordinary users understand the site relationship or expect the privacy boundary to soften.

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.

Open Questions

Sources

Return to Wiki