The Storage Access API

Think of the cloakroom again. Each shop now has its own ticket book, so your main cloakroom ticket from AdCo's own building is useless inside ShopA. The Storage Access API is the cloakroom attendant at ShopA asking you, "Would you like to use your main ticket here?" If you say yes, that one attendant, in that one shop, may use it.

How an embed asks

Imagine comments.example is embedded on blog.example. Inside its frame, its script does this (JavaScript, shown only to read):

// Inside the comments.example frame
if (!(await document.hasStorageAccess())) {
  signInButton.onclick = async () => {        // must run inside a click
    try {
      await document.requestStorageAccess();     // the browser may ask you
      location.reload();                         // now it sees its own cookies
    } catch {
      showMessage("Open comments.example to sign in");
    }
  };
}

hasStorageAccess() answers "do I already have my cookies here?" requestStorageAccess() asks for them, and either succeeds or fails. A well-written embed handles the failure gracefully.

The rules engines apply

• Only embedded frames ask. A top-level page already has its own cookies.
• A user gesture is required. A script cannot request access silently on page load; it must be inside your click.
• You may have to know the embed. Engines can require that you have visited the embedded site directly before, so a tracker you have never heard of cannot ask. Safari, for example, requires this.
• The browser may show a prompt, naming both sites, and you can refuse.
• Grants are narrow. They cover one embedded site on one top-level site, and they expire after a while.
• Sandboxed frames need the page to allow it explicitly, with the allow-storage-access-by-user-activation sandbox token.

The exact prompts and time limits differ between engines and change over time; the shape above is common to all of them.

Where it ships

The Storage Access API ships in Safari, Firefox and Chrome (Chrome since version 119). In Chrome it matters only for users who block third-party cookies, since everyone else still has unpartitioned third-party cookies. Related Website Sets, which once granted access automatically between sites owned by one company, were retired (checked October 2026).

Storage Access versus CHIPS

The two are easy to mix up. With CHIPS (the Partitioned attribute from Leg 1), an embed accepts a separate jar on each site and needs no permission. With Storage Access, the embed asks for its one shared jar, which can recognise you across sites, so it needs your gesture and possibly your yes. Prefer CHIPS when the embed does not need to know who you are elsewhere.

A common misconception

"Granting storage access lets the embed read the page's cookies." It does not. comments.example gets its own cookies back, nothing of blog.example's. What you are agreeing to is that comments.example may recognise you on this blog.