demo · v133
Partitioning probe — what's keyed by top-level site now?
Click each test to write a value, then visit this page embedded on another site to see whether you get the same value back. The partitioning landed in Chrome 115; 133's chromestatus entry is the catch-up acknowledgement.
| storage | writes | reads | partitioned? |
|---|---|---|---|
| localStorage | — | ||
| IndexedDB | — | ||
| Cookies (document.cookie) | — | ||
| BroadcastChannel | — | ||
| Service Worker scope | — | ||
Open this page as an iframe on a different top-level origin and run "read" — values won't transfer if the storage is partitioned by top-level site.
what each storage now sees
Pre-115, third-party iframes had full access to first-party storage keyed by origin only. That let cross-site trackers maintain identity across sites. The privacycg partitioning work re-keyed every client-visible storage by {top-level site, embedded origin}. The Storage Access API exists for the cases where shared state is legitimately needed (auth flows). Chrome 133's chromestatus entry is the documentation catch-up — the runtime behaviour itself rolled out in 115.