v152 · Web APIs · Privacy

Partition Visualizer

document.requestStorageAccessFor(origin) was removed in Chrome 152 — it allowed a top-level frame to grant unpartitioned storage access to embedded content without user interaction. This visualizer shows how storage is partitioned under the new model versus what requestStorageAccessFor allowed.

current browser status

Checking Storage Access API support without calling the removed method.

removed API checking...
replacement request checking...
access probe checking...
If requestStorageAccessFor is missing, this page keeps the visual model interactive and shows migration paths instead of throwing.
Storage partitioning model
First-party (unpartitioned)
Partitioned (per-top-site)
Blocked (cross-site)
site-a.example (1st party)
cookie: session localStorage: prefs IndexedDB: user
✅ Full unpartitioned access
embed.example in site-a (partitioned)
cookie: ↦site-a/embed localStorage: ↦site-a/embed
🔵 Partitioned by top-site key
embed.example in site-b (different partition)
cookie: ↦site-b/embed
🔵 Different partition — isolated from site-a partition
In Chrome 152+, embedded content always gets a partitioned storage key: (top-site, embedded-origin). The same embedded origin in two different top-level sites gets completely separate storage — cross-site tracking via shared cookies is impossible.
// Removed in Chrome 152 — requestStorageAccessFor // Allowed top-level site to grant unpartitioned access without user gesture await document.requestStorageAccessFor('https://embed.example'); // ❌ removed // Replacement: Storage Access API (requires user gesture inside embed) // In the embedded frame: await document.requestStorageAccess(); // ✅ still works, requires user gesture // Or: use CHIPS (partitioned cookies, works without permissions) // Set-Cookie: embed_session=abc; Partitioned; SameSite=None; Secure

see also