Chrome 153 for developers: what breaks with RWS and requestStorageAccessFor

Chrome 153 reached the Stable channel on September 8, 2026 and starts Chrome's two-week major release cycle. For teams maintaining cross-domain sign-in, authenticated embeds, or cross-site requests with cookies, the most concrete compatibility issue in this release is different: Chrome 153 removes Related Website Sets (RWS) and document.requestStorageAccessFor(). Chrome lists both under milestone 153 removals, so they should be audited before updating a test environment or shipping code that depends on them.

The key is to separate two cases. A direct call to requestStorageAccessFor() loses the API itself and must be removed or redesigned. An integration that still uses the standard document.requestStorageAccess() API inside an iframe does not lose that API, but it no longer receives RWS-specific treatment and falls back to normal Storage Access API behavior outside a related set.

What Chrome 153 actually removes

• document.requestStorageAccessFor(): this was a Chrome-specific extension that allowed a top-level document to request access to unpartitioned cookies on behalf of an embedded origin. Chrome states that the API was only usable between sites in Related Website Sets, so it is removed together with RWS.
• Related Website Sets: the mechanism for declaring relationships between sites and enabling special cross-site access behavior is no longer part of Chrome 153. Set configuration no longer provides the RWS-related grant benefit.
• RWS-based SAA auto-granting: calls to requestStorageAccess() between sites that were previously members of the same set now follow regular Storage Access API rules without the RWS shortcut.

The Chrome 153 beta documentation explicitly lists both removals. The Chrome Platform Status notes for milestone 153 add that Storage Access API usage within a former set falls back to the API's behavior outside RWS.

What should not be confused with this removal

The standard Storage Access API was not removed. Methods such as document.requestStorageAccess() remain the standard route for embedded content to request access to unpartitioned storage when the use case genuinely requires it. What disappears is RWS-specific treatment. Outside RWS, the flow can require user interaction, context checks, and a permission decision, so a path that previously felt automatic may start showing a prompt, be denied, or require an additional UX step.

Chrome 153 is also not a general removal of third-party cookies. Chrome itself connects the removal of RWS and requestStorageAccessFor() to its decision to maintain the current approach to third-party cookies. User settings, policies, browsing mode, and other controls can still restrict cross-site cookies, so compatibility testing should include restricted-cookie scenarios.

Enterprise policies and the RWS-related extension API should not automatically be treated as removed in the same step. Chromium's intent says that RWS-related enterprise policies and chrome.privacy.relatedWebsiteSetsEnabled are also intended for deprecation, but through their own processes. If you maintain an extension or managed environment, audit those separately and confirm the specific milestone before removing them.

Search checklist: where to find dependencies in the repository

Start with literal searches across application code, tests, manifests, and infrastructure. A simple ripgrep command can speed up triage:

rg -n "requestStorageAccessFor|top-level-storage-access|relatedWebsiteSetsEnabled|related-website-set|First-Party Sets|Related Website Sets|requestStorageAccess\(" .

Do not limit the audit to front-end code. RWS can also appear in .well-known files, infrastructure configuration, operational documentation, end-to-end tests, CI flags, enterprise policies, and extension code. An occurrence with no SAA call may be dead configuration; a production occurrence of requestStorageAccessFor() is a direct incompatibility.

Classify each occurrence before changing code

1. Direct requestStorageAccessFor() call

This is the simplest case: the API is removed. Feature detection can prevent an immediate runtime error, but keeping the old path as the main implementation does not preserve the feature because the behavior it provided no longer exists in Chrome 153. The flow needs a different architecture.

2. requestStorageAccess() inside an iframe that relied on RWS

The standard API remains, but the old set relationship no longer provides the privileged path. Retest with a clean profile and verify that the request runs in a context compatible with SAA, that a user action is available when required, and that the application handles rejection or prompting. The Storage Access API documentation describes the difference between using SAA with and without RWS and lists alternatives by use case.

3. Related Website Sets configuration only

.well-known files, references to the set list, or registration documentation are no longer a Chrome 153 compatibility mechanism. Before deleting them, confirm whether another internal process consumes them; for browser behavior, however, do not plan the experience around an RWS benefit.

4. Enterprise policy or extension

Treat this as a separate track. Chromium's public plan includes deprecation of policies and chrome.privacy.relatedWebsiteSetsEnabled, but it is not safe to turn that intent into “removed in 153” without confirmation of the relevant milestone.

How to redesign the flow without looking for a 1:1 replacement

There is no universal replacement that recreates requestStorageAccessFor() from the top level. Migration depends on why the site needed cookies or unpartitioned state across origins.

• Use the standard Storage Access API when the embed truly needs the same unpartitioned state: move the request into the embedded content, handle the user-interaction requirement, and implement success, denial, and recovery paths. Test business behavior, not just method presence.
• Consider CHIPS when state can be partitioned by top-level site: Partitioned cookies fit widgets and components that need state within each embedding site but do not need to share the same session across all embeds.
• Consider FedCM for federated identity: when the core problem is sign-in between an identity provider and a relying party, FedCM may fit better than attempting to preserve broad cross-site cookie access.
• Reduce cross-site state when possible: origin consolidation, authenticated redirects, short-lived tokens, or backend APIs can be more predictable than depending on a cookie exception. The right choice depends on the product's architecture and security model.

The Privacy Sandbox Storage Access API page compares SAA, CHIPS, and FedCM and is a better reference for choosing by use case than searching for an API with the same shape as requestStorageAccessFor().

Test plan: compare Chrome 152 and 153 with the same scenario

To avoid “works on my machine,” pin browser versions. Chrome for Testing lets teams download specific versions and pair Chrome with ChromeDriver, making it easier to reproduce the same test on the previous milestone and on 153.

1. Build a minimal case in Chrome 152 and Chrome 153: same top-level origin, same iframe, same cookies, and the same click sequence.
2. Use a clean profile: old permissions can mask first-visit behavior. Also repeat the case with an existing grant if that is relevant to the product.
3. Test with third-party cookies restricted: DevTools' Privacy and security panel can temporarily limit third-party cookies during testing. This exposes flows that depend on storage-access grants.
4. Observe the code path: in M153, a check such as typeof document.requestStorageAccessFor === "function" should make it clear that the Chrome-specific path is unavailable. The application still needs to be validated by its final behavior.
5. Observe the network: in DevTools, check whether the Cookie header is sent on cross-site requests and review warnings in Cookies/Issues. The DevTools cookie documentation shows where to inspect sent and blocked cookies.
6. Test denial and missing gestures: an SAA flow must also behave correctly when access is not granted. Avoid loops, silent failures, or assumptions of auto-granting.
7. Move the case into CI: pin Chrome 153 in the login/embed end-to-end test and keep an assertion on the user-visible result, such as a recognized session, a loaded resource, or an explicit fallback.

Removal, origin trial, and new feature are different categories

The Chrome 153 post separates these changes into different sections. RWS and requestStorageAccessFor() are listed under Deprecations and removals: they are compatibility changes that need auditing now. JavaScript Self-Profiling Markers, by contrast, appears as a new origin trial: it is an opt-in experiment and does not explain a regression in code that depended on RWS.

Likewise, the new two-week cadence is a release-schedule change, not a compatibility API. Chrome announced milestone 153 as the first Stable release in that cadence, shipping on September 8, 2026. When triaging regressions, record separately: “removal that changes existing behavior,” “trial that requires opt-in,” and “new feature.” That prevents an experimental addition from being blamed for a documented removal.

Release gate for affected projects

• No production call to document.requestStorageAccessFor() remains unmigrated.
• Any requestStorageAccess() flow that relied on RWS has been retested without RWS auto-granting.
• The flow handles permission, denial, and fallback without assuming automatic access.
• RWS files and documentation have been identified and are no longer treated as a Chrome 153 compatibility requirement.
• Cookies and credentialed requests have been inspected in DevTools with a clean profile.
• Chrome 153 has been added to automated testing with a pinned Chrome for Testing version.
• RWS-related enterprise policies and extension APIs are tracked separately rather than assumed to share the same removal milestone.
• Origin trials and new Chrome 153 features are kept separate from the incompatibility list.

Once these checks are covered, the upgrade stops being a bet based on a changelog and becomes a behavior verification: where the API disappeared, the code was redesigned; where the standard API remains, the flow was tested without the RWS benefit.

Main sources: Chrome 153 beta, Chrome's two-week release cycle, Chrome 153 Release Notes, Storage Access API, Related Website Sets developer guide, and Chrome for Testing.