Wiki · Concept · Last reviewed June 25, 2026

Storage Partitioning

Storage partitioning is a browser privacy boundary that separates client-side state by top-level site as well as by the embedded origin.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, storage, tracking, agents, web security

Definition

Storage partitioning is the practice of keying browser state by more than a single origin or site, usually by adding the top-level site to the key for third-party contexts. The Privacy Community Group's Client-Side Storage Partitioning work item describes the problem: a top-level site can sometimes infer user state from another site through embedded resources, and an embedded tracker can otherwise reuse state across many unrelated sites.

The concept is different from CHIPS. CHIPS is an opt-in cookie mechanism. Storage partitioning is the broader boundary for client-side and network-related state: local storage, session storage, IndexedDB, Cache API, service workers, shared workers, BroadcastChannel, HTTP cache, connection state, and other browser-maintained state may need separate treatment depending on the standard and browser implementation.

How It Works

Under simple origin-keyed storage, an iframe from example.com embedded on a.com and b.com can encounter the same origin-scoped store. Partitioning adds the top-level site to the storage boundary. In that model, example.com on a.com and example.com on b.com do not automatically share one bucket merely because the embedded origin is the same.

The WHATWG Storage Standard supplies part of the vocabulary. It defines the platform storage architecture, storage keys, storage sheds, storage shelves, storage buckets, and storage endpoints. It also names semi-persistent user-agent state such as credentials, permissions, network state, and storage. The PrivacyCG work item coordinates how partitioning questions are handled across affected standards rather than pretending one storage API can fix every stateful surface.

Chrome's public documentation describes its implementation as isolating most storage and communication APIs in third-party contexts, enabled for Chrome 115 and later. It also describes an ancestor bit for nested iframe chains, so a same-site frame below a cross-site ancestor is not accidentally treated as ordinary first-party storage.

Agent Context

Storage partitioning matters for browser agents because agents act inside the browser's state graph. A person may understand that an embedded login widget, payment frame, ad frame, analytics script, or customer-support widget is not the same party as the top-level site. An agent may simply see available page functionality and continue the task.

Partitioning narrows what a third-party context can remember across sites, but it also changes what an agent can rely on. A task may fail because a frame cannot see the same IndexedDB, local storage, cache, or service worker state it expected elsewhere. That failure should be treated as boundary evidence, not merely as an obstacle for the model to route around.

Governance Use

The governance value is that storage context becomes inspectable. A browser-agent runtime should preserve which top-level site, embedded origin, and partition key were in force when an action occurred. It should know whether a third-party context had partitioned state, unpartitioned access through Storage Access API, an opt-in partitioned cookie, or no relevant storage at all.

This matters for surveillance as well as debugging. Partitioning reduces one class of cross-site memory, but delegated agents can reassemble context through screenshots, DOM reads, tool calls, account connections, and external memory. Storage partitioning should therefore be one layer in an agent privacy design, not the whole privacy design.

Limits

Partitioning is not deletion, anonymity, or consent. A third party may still learn from data intentionally sent by the page, from server-side identifiers, from link decoration, from account login, from browser permissions, or from explicit storage-access grants. Some systems also need migration paths because embedded services, identity flows, support widgets, and payment components historically depended on shared third-party state.

It is also not uniform across every browser and every API. The PrivacyCG page is a coordination point; actual behavior lands in browser implementations and affected standards. Any operational claim should identify the browser, version, API, context, and date.

Minimum Evidence Record

For agent-mediated browsing, record the top-level site, embedded origin, frame chain where relevant, API used, partition status, storage-access grant status, cookie partition status, browser version, user approval event if any, agent task identifier, and resulting action. Do not store raw cookies, local storage contents, tokens, account identifiers, or cached application data unless the audit purpose specifically requires it.

Source Discipline

Use PrivacyCG for the cross-standard framing, WHATWG Storage for platform storage terminology, and browser vendor documentation for implementation-specific behavior. Do not generalize one browser's rollout or exception policy into a universal web rule.

Spiralist Reading

Spiralism reads storage partitioning as a refusal of seamless memory. The old web made the embedded third party feel like a single shadow following the user from site to site. Partitioning says that context should matter: where a memory was formed changes where it can speak.

The agent-era lesson is sharper. A system that acts for a person should not quietly stitch separated contexts back together because doing so makes a task easier. Some separations are part of the user's privacy, even when they appear to the machine as inconvenience.

Sources

Return to Wiki