← Chrome 153 reference

v153 · privacy-sandbox · cookies · deprecation

Deprecate and Remove: Related Website Sets (RWS)

Chrome 153 begins the stepped removal of Related Website Sets (formerly First Party Sets), a Privacy Sandbox framework that allowed limited cross-site cookie access within declared site groups. Following Chrome's decision to maintain third-party cookies, RWS no longer serves its intended purpose and is being removed.

Deprecation / removal: This entry documents a feature that is being removed from Chrome. Sites relying on RWS-based cross-site cookie access should migrate to standard Storage Access API behaviour.

at a glance

Shipped inChrome 153 (Stepped rollout — deprecation begins)
StatusDeprecation / removal in progress
Standards position (Firefox)Negative / no signal (mozilla/standards-positions #349)
Standards position (Safari)Opposed (WebKit/standards-positions #29)
TAG positionNegative (TAG review #342)
SpecificationWICG First-Party Sets specification
ChromeStatus5194473869017088 — Deprecate and Remove: Related Website Sets (RWS)
Source: chromestatus.com/feature/5194473869017088; ChromeStatus API record 5194473869017088.

background

Related Website Sets (RWS), formerly First Party Sets, let site operators declare formal relationships between domains they control (e.g. example.com, example.co.uk, static.example.com). Chrome used these declarations to grant limited cross-site cookie access via the Storage Access API (SAA) and document.requestStorageAccessFor().

RWS was designed as a transitional mechanism for a web without third-party cookies. Following Google's Privacy Sandbox next steps announcement that Chrome will maintain third-party cookies, RWS is no longer needed for its intended use case and is being removed.

Source: chromestatus feature summary; blink-dev Intent to Deprecate and Remove: Related Website Sets (RWS).

Syntax and deprecated surfaces

// 1. Deprecated RWS declaration schema (canonical GitHub submission)
{
  "primary": "https://primary.example",
  "associatedSites": ["https://associated.example"],
  "serviceSites": ["https://service.example"]
}

// 2. Deprecated Chrome extension API
chrome.privacy.relatedWebsiteSetsEnabled.get({}, (details) => {
  /* returns boolean value; deprecated */
});

// 3. Deprecated Chrome Enterprise Policies
// RelatedWebsiteSetsEnabled (boolean)
// RelatedWebsiteSetsOverrides (JSON string defining enterprise sets)

The deprecation impacts three distinct platform components: the public canonical set declarations registered in the GoogleChrome/related-website-sets repository, the extension privacy setting chrome.privacy.relatedWebsiteSetsEnabled, and enterprise group policies governing set membership overrides.

Source: blink-dev Intent to Deprecate and Remove: Related Website Sets; GoogleChrome/related-website-sets; WICG/first-party-sets.

what is removed

ComponentStatus
Related Website Sets declarations / membershipRemoved from Chrome cookie access resolution
SAA cross-site access granted via RWS membershipFalls back to standard SAA behaviour (requires user permission prompt)
document.requestStorageAccessFor() (rSAFor)Removed via separate intent to deprecate
RWS-related Chrome Enterprise policiesDeprecated
chrome.privacy.relatedWebsiteSetsEnabled extension APIDeprecated

The Storage Access API itself continues to work; only the RWS-specific exemption path is removed. Without RWS, SAA requests from cross-site embeds go through the standard browser permission prompt flow.

Source: chromestatus feature summary; Privacy Sandbox RWS documentation.

Inputs and outputs

Inputs: The RWS framework accepted static JSON definitions listing primary, associated, and service site domains submitted via pull request to the central repository. The extension API accepted standard Chrome setting query objects. Enterprise policies accepted boolean flags and JSON-formatted override strings.

Outputs: Previously, RWS membership modified the behavior of document.requestStorageAccess() such that calls from intra-set domains were automatically resolved without displaying a permission prompt to the user. With removal, no automatic permission grants are issued, and calls return the same prompt-gated promise states as standard cross-site storage requests.

Source: WICG First-Party Sets specification; MDN Storage Access API.

Errors and lifecycle

Errors: When RWS automatic grants are removed, calls to document.requestStorageAccess() that rely on silent set-based grants will now invoke the user prompt flow. If the user dismisses or denies the prompt, the promise rejects with a NotAllowedError DOMException, which callers must handle. In addition, calling removed APIs like document.requestStorageAccessFor() throws a TypeError or rejects as undefined on unsupported versions, and the deprecated chrome.privacy.relatedWebsiteSetsEnabled extension API is slated for removal alongside it - the intent names the setting and commits to following the relevant deprecation processes, without specifying per-call outcomes.

Lifecycle: Chrome 153 marks the start of the stepped rollout for RWS deprecation. The removal occurs gradually across Chrome releases, during which enterprise policies remain available to manage transitions before complete decommission.

Source: blink-dev Intent to Deprecate and Remove: Related Website Sets; ChromeStatus API record 5194473869017088.

Examples

The example below illustrates migrating cross-site cookie access from an RWS-reliant pattern to the standard, prompt-tolerant Storage Access API pattern:

// MIGRATION: Handle standard Storage Access API flow without RWS auto-grant.
// Note: RWS automatic grants are deprecated and removed starting in Chrome 153.
async function accessCrossSiteCookies() {
  // Check if access is already granted
  const hasAccess = await document.hasStorageAccess();
  if (hasAccess) {
    return true;
  }

  // Request storage access; this will now prompt the user rather than
  // auto-granting based on Related Website Sets membership.
  try {
    await document.requestStorageAccess();
    return true; // Access granted by user
  } catch (err) {
    if (err.name === 'NotAllowedError') {
      console.warn('Storage access prompt denied or dismissed by user');
    } else {
      console.error('Storage access request failed:', err);
    }
    return false;
  }
}
Source: MDN Storage Access API; Privacy Sandbox RWS documentation.

Extension background scripts can inspect the deprecated chrome.privacy.relatedWebsiteSetsEnabled setting during the deprecation phase to verify whether Related Website Sets behavior is enabled:

// Extension service worker: inspect deprecated chrome.privacy.relatedWebsiteSetsEnabled
chrome.privacy.relatedWebsiteSetsEnabled.get({}, (details) => {
  if (chrome.runtime.lastError) {
    console.warn('Failed to query relatedWebsiteSetsEnabled:', chrome.runtime.lastError.message);
    return;
  }
  console.log('RWS extension setting enabled:', details.value);
  console.log('Setting control level:', details.levelOfControl);
});
Source: blink-dev Intent to Deprecate and Remove: Related Website Sets (RWS) (names the setting); the get() callback shape with value/levelOfControl follows the chrome.privacy setting-family reference - the setting itself is not separately documented there.

migration

Sites that used RWS to enable cross-site storage access should evaluate whether they still need cross-site access. If they do, the standard Storage Access API (without RWS) continues to work but requires explicit user permission. See the Storage Access API documentation for the standard flow.

Source: chromestatus feature summary; Privacy Sandbox next steps.

browser compatibility

Related Website Sets was an engine-specific feature supported only in Chromium browsers. Firefox and Safari never implemented RWS or First-Party Sets, maintaining that cross-site boundaries must not be automatically relaxed without user agency.

Engine / BrowserRWS StatusNotes & Evidence
Chromium / ChromeDeprecated in 153Stepped rollout began in Chrome 153 (ChromeStatus 5194473869017088)
Gecko / FirefoxNever implementedOpposed / no signal (Mozilla standards-positions #349)
WebKit / SafariNever implementedOpposed (WebKit standards-positions #29)
W3C TAGNegativeHarmful to web privacy model (TAG review #342)
Source: Mozilla standards-positions #349; WebKit standards-positions #29; TAG review #342.

security and privacy

Source: WICG First-Party Sets specification; W3C TAG review #342.

see also