Sharing Cookie Consent Across Your Own Domains After Chrome Drops Related Website Sets

We covered the same-site version of this problem last week: one registrable domain, several subdomains, one consent cookie. This is the cross-site version — brand.com, brand.de and brandshop.com — where a cookie cannot be shared at all and sites have reached for an iframe instead.

What Chrome has actually said

Be precise about the stage, because the two official sources do not use the same tense.

• The Chrome 153 release notes give a stable date of 8 September 2026 and, under Deprecations and removals, say Related Website Sets “is planned for deprecation and removal”, and that requestStorageAccessFor “is planned for deprecation and removal along with Related Website Sets”.
• The ChromeStatus entries for Related Website Sets and requestStorageAccessFor, both updated on 21 August 2026, carry a deprecation stage at milestone 144 and a stage labelled “Removal of API” at milestone 153. Their overall status field still reads “Proposed”.
• The Related Website Sets submission repository is archived and has taken no changes since November 2025. Its final list holds 70 sets covering 320 sites.

So 153 is the milestone Chrome has attached to removal, but neither page states that the code is already gone from every stable install. We did not test it: the machine we would have used runs Chrome 152. What follows is written so that you can check your own traffic rather than take our word or anyone else’s.

Why a set mattered for consent

The pattern is familiar. Each brand site embeds a small iframe from one consent domain. The iframe reads or writes the decision in its own storage, and posts it back to the page. Where third-party cookies are allowed, that iframe simply sees its cookies. Where they are blocked, it sees partitioned storage — a fresh, empty jar per top-level site — and the visitor who accepted on brand.com is a stranger on brand.de.

The Storage Access API is the sanctioned way back through that wall, and Google’s own documentation sets out what membership in a set changed. Without a set, the request “requires a user gesture”, and the user must previously have visited the storage origin as a top-level site. With a set, the “first time user prompt can be skipped”. requestStorageAccessFor went further: it let the top-level page request access on the embed’s behalf, and it “can only be used for sites within a Related Website Set”.

Take the set away and the Storage Access API still exists — it is not being removed. It just falls back to the unprivileged path: a click inside the iframe, possibly a prompt, and no way to ask on page load.

What breaks, specifically

Unguarded calls to requestStorageAccessFor. If the method is removed, calling it throws a TypeError, and if that call sits at the top of your consent bootstrap, nothing after it runs. That is a worse failure than a missing grant: the banner may never render at all.

A consent read that assumed a silent grant. A script that calls requestStorageAccess() inside the iframe on load, with no user gesture, gets a rejection where it used to get access. If the fallback on rejection is “show the banner”, visitors on blocked-cookie browsers see it again on every sister domain.

Nothing, on default Chrome. Chrome kept third-party cookies on by default, and ChromeStatus says Related Website Sets was designed “for use in a browser without third-party cookies”. A normal Chrome window will not show any change. That is why this will not surface in a quick check from the office.

Checking your own setup

Open a sister domain in a Chrome Incognito window, which blocks third-party cookies by default, and run these in the console of the top-level page and then of the consent iframe (select its context in the DevTools console dropdown):

// top-level page: is the method still there?
typeof document.requestStorageAccessFor          // "function" or "undefined"

// inside the consent iframe: can it read its own storage right now?
await document.hasStorageAccess()                // true / false

// and would a request be granted without asking?
(await navigator.permissions.query({ name: "storage-access" })).state
                                                 // "granted" | "prompt" | "denied"

Then search your consent code for the call itself:

grep -rn "requestStorageAccessFor\|requestStorageAccess(" --include=*.js .

Any hit that is not wrapped in a feature check and a try/catch is worth fixing today, whether or not 153 has removed the method on your users’ machines yet:

async function canReadSharedConsent() {
  if (!document.hasStorageAccess) return false;
  try {
    if (await document.hasStorageAccess()) return true;
    const { state } = await navigator.permissions.query({ name: "storage-access" });
    return state === "granted";      // never trigger a prompt on page load
  } catch {
    return false;
  }
}

Note what that function does not do: it never calls requestStorageAccess() without a click. A consent banner that throws a browser permission prompt at a visitor before they have done anything is not a fix.

A design that does not need the grant

Keep the decision first-party on every domain. Each site writes its own consent record in its own cookie, and that record is what the site’s tags obey. Cross-domain sharing becomes an optimisation for pre-filling the banner, not the source of truth. When the shared read fails, the site simply asks once, and nothing throws.

For signed-in visitors, the durable version of sharing is server-side: store the decision against the account and restore it on each domain after login. The CNIL has written specific rules for that case, including symmetric withdrawal, which we covered in consent that follows a logged-in account. For anonymous visitors, accept that each domain asks. Three banners over three brand sites is a smaller problem than a shared-iframe setup that silently throws on some fraction of your traffic.

The wider Privacy Sandbox wind-down, of which this is one piece, is in what survived the Privacy Sandbox shutdown. That post predates the 153 release notes and describes Related Website Sets as slated for deprecation; this one is the update.

A banner that reappears on sister domains is easy to miss from a normal browser window. Scan each of your domains to see what loads before a decision is made with CookieInspector.