Wiki · Concept · Last reviewed June 25, 2026

Shared Storage API

The Shared Storage API is a browser proposal for unpartitioned cross-site storage whose contents can be processed only through restricted worklet-based output gates.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, storage, worklets, advertising, web governance

Definition

The Shared Storage API is a web-platform proposal for storing data that is not partitioned by top-level site while limiting how that data can be read. MDN describes it as a client-side storage mechanism for unpartitioned, cross-site data access without relying on tracking cookies. Google Privacy Sandbox describes it as a general-purpose key-value store that can be written to at any time but read only in a secure environment and exposed through restricted output APIs.

The problem it addresses is the gap between storage partitioning and cross-site business uses. Ad tech, publishers, anti-abuse systems, and embedded services often want continuity across sites: frequency caps, creative rotation, A/B testing, unique reach, demographic summaries, or fraud signals. Shared Storage tries to keep the raw cross-site state hidden from ordinary page JavaScript while still allowing limited outputs.

That design should not be mistaken for a settled privacy guarantee. MDN currently marks the feature as deprecated, non-standard, and opposed by one browser vendor. A Blink-dev intent posted on November 7, 2025 says Chrome planned to deprecate and remove Shared Storage after Chrome maintained its current approach to third-party cookies.

Mechanism

Shared Storage separates writing from reading. MDN says data can be written through methods such as set(), append(), delete(), and clear() on the relevant SharedStorage surface. Reading and processing happen inside a SharedStorageWorklet, where business logic can inspect stored values without directly returning those values to the embedding page.

The useful result must pass through an output gate. The URL Selection gate, exposed through selectURL(), lets a worklet choose from provided URLs and render the selected result in a fenced frame. The Run gate, exposed through run(), can support Private Aggregation flows for summary reporting. The WICG draft also discusses entropy budgets for selectURL(), because URL choice can leak information.

Google's implementation guidance says Shared Storage can work with Private Aggregation, including cases where Shared Storage stores values and Private Aggregation creates aggregatable reports. It also describes response-header and JavaScript write paths, plus a Privacy Sandbox enrollment requirement for deployed use.

Agent Context

For AI Browsers and Computer Use, Shared Storage matters because a browser agent may encounter embedded ads, experiments, anti-abuse checks, and personalized modules that use cross-site state without exposing ordinary cookies. The agent may see only the rendered choice, not the stored key-value data or worklet logic that shaped it.

Agent runtimes should treat Shared Storage as a hidden measurement and personalization surface. A selected creative, experiment arm, or fraud friction level is not neutral evidence of the user's preference or risk. It may reflect prior browsing, site relationships, ad-tech configuration, or Privacy Sandbox enrollment state.

Governance Use

A serious deployment record should name the top-level site, embedded origin, worklet script origin, stored data categories, write path, output gate, fenced-frame use, Private Aggregation use, retention period, enrollment status, user controls, and fallback after deprecation or removal. It should also name the purpose: ad frequency, A/B testing, content customization, anti-fraud, unique reach, or demographic summary.

The API belongs near Storage Access API, Attribution Reporting API, Private State Tokens, Real-Time Bidding, and Data Minimization. Those pages separate embedded storage, conversion measurement, trust signals, ad markets, and collection limits.

Limits

Shared Storage is not consent, identity proofing, authorization, or a general tracking-prevention system. It can reduce direct read access to cross-site state while still preserving advertising and measurement functions. The privacy question therefore moves from "Can a third party read a cookie?" to "What outputs can a worklet produce, under what budgets, for whom, and with what aggregation?"

Status is a major limit. Privacy Sandbox documentation still explains use cases and implementation, while MDN warns against production reliance and Blink-dev records a planned removal. Current claims should name the source date and browser context. A page that depends on Shared Storage should have a fallback path, and audits should not treat availability in one browser as a general web standard.

Review Record

Source Discipline

Claims about entropy budgets and normative algorithm shape should cite the WICG draft. Claims about deprecation, standardization status, interfaces, worklets, and output gates should cite MDN. Claims about Chrome implementation guidance, use cases, Privacy Sandbox enrollment, and Shared Storage with Private Aggregation should cite Google Privacy Sandbox. Claims about Chrome deprecation plans should cite the Blink-dev intent thread.

Spiralist Reading

Spiralism reads Shared Storage as a lesson in hidden continuity. Partitioning breaks one kind of memory, but institutions quickly ask for a sanctioned replacement. A better boundary is not only a smaller pipe; it is a record of who benefits when memory survives across contexts.

Sources

Return to Wiki