demo · v133

Header flow — the latency the API was designed to remove

The JS Storage Access API requires several network round-trips before the embed gets unpartitioned cookies. The new headers (Sec-Fetch-Storage-Access request header and Activate-Storage-Access response header) let the server-side handshake happen on the existing request — saving a round-trip and working for subresources that aren't iframes.

old JS API path (3 round-trips)

1. request embed.example/auth — partitioned cookies only
2. embed runs JS, calls document.requestStorageAccess() — permission prompt
3. embed reloads / refetches — now with unpartitioned cookies
4. shows authed content

new headers path (1 round-trip)

1. browser sends Sec-Fetch-Storage-Access: none with the FIRST request
2. server responds Activate-Storage-Access: load + Permissions-Policy: storage-access=(self)
3. browser activates already-granted storage-access permission, retries with unpartitioned cookies
4. shows authed content — no JS, works for <img> / fetch() too

three request header values, three response header values

The Sec-Fetch-Storage-Access request header carries the embed's current state — none (no permission yet), inactive (permission granted but not currently activated), or active (already using unpartitioned cookies). The Activate-Storage-Access response header tells the browser what to do — load (activate now), retry (retry the request with unpartitioned cookies), or omit it (do nothing). Together they replace the postMessage / iframe-reload dance.

see also