Skip to content

Add Storage Access API page (privacy, optional)#76

Draft
jdevalk wants to merge 1 commit into
mainfrom
standards-scan/storage-access-api-2026-07-05
Draft

Add Storage Access API page (privacy, optional)#76
jdevalk wants to merge 1 commit into
mainfrom
standards-scan/storage-access-api-2026-07-05

Conversation

@jdevalk

@jdevalk jdevalk commented Jul 5, 2026

Copy link
Copy Markdown
Owner

What changed

Adds a new spec page: Storage Access API under privacy.

  • Documents the browser API by which cross-site content embedded in an <iframe> requests access to its own unpartitioned third-party cookies/state — behind a user gesture (transient activation), gated by user prompts and prior first-party interaction.
  • Covers the practical requirements: SameSite=None; Secure cookies, secure context, the allow-storage-access-by-user-activation sandbox token, the storage-access Permissions-Policy gate, and the Sec-Fetch-Storage-Access / Activate-Storage-Access header workflow.
  • Wires relatedSlugs both ways with third-party-scripts, security/cookie-attributes, and security/permissions-policy.
  • Adds an added changelog entry and regenerates the count-driven OG images plus the new per-page image.

Why now

Third-party cookies are being partitioned/blocked by default (Firefox Total Cookie Protection, Safari ITP, Chrome following). The Storage Access API is the standards-track replacement for the old "please disable your tracking protection" workaround — it restores access for legitimate cross-site cases (SSO, federated identity, personalisation widgets) without reopening the site to tracking. Cross-engine support is mature: Safari 11.1 (2018), Firefox 65 (2019), Edge 85 (2020), Chrome 119 (2023).

Primary source(s)

Status: optional — justification

It genuinely depends on context (CONTRIBUTING's definition of optional): the API only matters to sites that embed cross-site content needing first-party cookies/state. A standalone first-party site that sets its own cookies never needs it. So optional, not recommended — honest about who it applies to, rather than inflating the bar.

Notes

  • No new site asset / discoverable resource, so no api-catalog Linkset or Link header change.
  • SKILL.md left unchanged: page count phrasing ("140+ pages") stays accurate at 157 and no category changed, so no digest recompute needed.
  • npm run build passes (157 pages indexed); lint + prettier clean via pre-commit hook.

Opened as a draft by the daily standards scan for maintainer review — not for auto-merge.

🤖 Generated with Claude Code

New spec page documenting the W3C Privacy CG Storage Access API — the
standard way for embedded cross-site content to request its own
unpartitioned cookies behind a user gesture as browsers partition and
block third-party cookies. Marked `optional`: it only applies to sites
embedding cross-site content that needs first-party state (SSO,
federated identity, signed-in widgets), and has shipped in all engines
for years.

Wires relatedSlugs on third-party-scripts, cookie-attributes, and
permissions-policy; adds an `added` changelog entry; regenerates the
count-driven OG images plus the new per-page image.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying specification-website with  Cloudflare Pages  Cloudflare Pages

Latest commit: 4f1e5c2
Status: ✅  Deploy successful!
Preview URL: https://e4ee180e.specification-website.pages.dev
Branch Preview URL: https://standards-scan-storage-acces.specification-website.pages.dev

View logs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant