A widget served from widget.example is loaded in an iframe on two different top-level sites. Modern browsers no longer let it read the same client-side storage in both. What changed, and what is the unit that quota and eviction now apply to?

## The identity storage hangs off changed For most of the web's history, client-side storage was keyed on origin alone. An iframe from `widget.example` opened the same IndexedDB database no matter which page embedded it, which is exactly what made cross-site tracking through storage possible: write an identifier once, read it back everywhere the widget appears. Modern browsers changed the key. Storage is now addressed by a **storage key**, which combines the frame's origin with the **top-level site** it is embedded under. The same origin in two different embedding contexts gets two unrelated stores. So for a widget from `widget.example`: - embedded on `siteA.example` → one store - embedded on `siteB.example` → a second, entirely separate store - loaded directly as a top-level page → a third The frame code is identical in all three; the storage it reaches is not. ## What is partitioned Partitioning is not limited to one API. It covers the script-visible storage surface an embedded frame can use, including `localStorage` and `sessionStorage`, IndexedDB, `CacheStorage`, service worker registrations, and coordination primitives such as `BroadcastChannel` and the Web Locks API. Cookies are partitioned too, but under their own separate rules and attributes. Note what that means for messaging: two frames of the same origin on two different top-level sites cannot see each other's storage and cannot reach each other through a `BroadcastChannel` either. The isolation is deliberate and fairly complete. ## Quota and eviction follow the key This is the second half of the question and the part candidates usually miss. Because everything is keyed by the storage key, quota and eviction are accounted per key as well: - Each partition has its own usage and its own share of the ceiling. `navigator.storage.estimate()` called inside the frame reports the partition's numbers, not a global total for `widget.example`. - Filling the widget's storage on one embedding site does not consume the budget it has on another. - Eviction of one partition leaves the others alone: the widget can be wiped on `siteA.example` while its data on `siteB.example` survives untouched. One embedded copy of your widget being evicted therefore says nothing about the others, and there is no single number that describes "how much disk this widget uses across the web". ## Browser status Chromium shipped third-party storage partitioning in Chrome 115. Firefox arrived at the same place through Total Cookie Protection and state partitioning, and Safari partitions or blocks third-party state by default under its tracking-prevention rules. The details differ, but the design conclusion is the same everywhere: an embedded third party cannot assume shared state across embedders. ## The escape hatch, and its limits The Storage Access API exists for the legitimate cases — an embedded document that is the same organisation as the top-level site, a federated widget where the user genuinely expects continuity: ```js if (await document.hasStorageAccess() === false) { await document.requestStorageAccess(); // requires a user gesture } ``` `document.requestStorageAccess()` must be called from a user gesture inside the embedded frame, and the browser decides whether to grant it — a grant is not guaranteed and is not permanent. Historically it restores unpartitioned **cookie** access; extensions that cover other storage types are newer and support differs across browsers, so do not architect on the assumption that IndexedDB or `localStorage` will be un-partitioned on request. ## Designing under partitioning The honest design response is to stop treating the client as the place where cross-site identity lives. **Move continuity to the server.** If the same user should be recognised on two embedding sites, that recognition belongs to an authenticated server-side session, not a value cached in an iframe. **Expect a cold start per embedder.** Any bootstrap the widget caches will be rebuilt once per top-level site. Keep it small, and lean on the HTTP cache — which is a separate mechanism from quota-managed storage — for the static assets themselves. **Budget per partition.** A widget that assumed one shared quota across the web now has one budget per embedder. That is usually more total room, but each individual partition is subject to its own eviction. **Test in an embedded context.** The most common way this defect ships is developing the widget as a top-level page, where nothing is partitioned, and discovering the behaviour only once a real customer embeds it.