Privacy Sandbox After the Removals: Which Technologies Chrome Keeps and What That Means for Measurement

Privacy Sandbox is not a single switch for privacy or advertising. Google continues some technologies, retires others and stops pursuing further proposals. The status page checked on 24 October 2026 is dated 14 August 2026. The earlier shorthand “eight removed, three remaining” does not accurately describe that overview.

The summary lists eight entries under “Deprecate and remove”: Aggregation Service, Attribution Reporting, Fenced Frames, Private Aggregation, Protected Audience, Related Website Sets including requestStorageAccessFor(), Shared Storage including Select URL, and Topics. IP Protection instead appears alongside Partitioned Popins and Related Website Partition under “Discontinue”. Further proposals are classified as “Do not launch”. Such a status does not confirm that every installed Chrome version has already removed the same interface.

CHIPS, Storage Access and FedCM remain important components

CHIPS, Storage Access and FedCM are among the technologies receiving continued support, not an exhaustive list of survivors. The overview also names Private State Tokens, Storage and Network State Partitioning, User-Agent Client Hints and frame-ancestors, among others. The following three APIs serve different purposes; version numbers indicate original Chrome availability rather than the scope of every later extension.

A technical dividing line alone does not explain the decisions

Google’s announcement of 17 October 2025 cites ecosystem feedback, expected value and low adoption as reasons for retiring several offerings. The Chromium announcement for Related Website Sets also refers to the retained cookie strategy and limited or declining usage. A general rule that “partitioning requires no trust, while lists require too much” is therefore not established as the reason for these decisions.

Related Website Sets was intended to facilitate limited access to unpartitioned cookies between related sites. This required a recognized set and API calls; an arbitrary self-published list did not automatically grant unrestricted access across domains. Removing Related Website Sets also affects document.requestStorageAccessFor(), but does not replace the general Storage Access API that remains supported.

Chrome has not universally abolished third-party cookies either. On 22 April 2025, Google confirmed the existing choice in settings and abandoned plans for a new standalone prompt. Third-party cookies are blocked by default in Incognito. Other browsers, settings and policies can impose different restrictions.

CHIPS separates cookies by top-level site

The Partitioned attribute adds the top-level site to the cookie’s storage association. A site means the combination of scheme and registrable domain, not every individual URL or necessarily every subdomain. Two HTTPS pages under the same registrable domain can therefore belong to the same site.

Set-Cookie: __Host-widget=example-value; Path=/; Secure; HttpOnly; SameSite=None; Partitioned; Max-Age=2592000

Simplified partition association (name/path omitted):
(widget.example, https://shop.example)
(widget.example, https://blog.example)
Separate cookie storage for the two top-level sites.

The example shows one HTTP response header followed by a simplified association. A complete cookie key includes further attributes, such as name and path. The example value is not a production session token. CHIPS requires Secure; the __Host- prefix additionally requires Path=/ and no Domain attribute. HttpOnly prevents access through document.cookie.

Max-Age=2592000 means 30 days and is only an example lifetime. CHIPS is not limited to a single visit. Lifetime and stored content must fit the function. A chat or payment frame can retain state within one site, while an existing cross-site workflow may need changes.

Partitioning prevents automatic sharing of this cookie between different top-level sites. It guarantees neither anonymity nor the absence of other permitted account links. The browser does not automatically generate different cookie values either: the separation applies to storage compartments.

Storage Access: permission and activation are different

An embed can use document.requestStorageAccess() to request access to otherwise blocked unpartitioned cookies or supported storage types. The browser can grant or deny the request. Initial access requiring approval often needs interaction with the embedded content.

A fresh gesture and prompt are not mandatory for every call. Chrome can reuse an existing permission; the documentation describes 30 days, extended through further interaction. Under specified conditions, an active FedCM sign-in can also act as a trust signal. Permission and activation of access in a particular document remain different steps. Browser implementations differ.

After the RWS shortcut disappears, an integration needs an appropriate alternative, such as a direct request from the embedded document. Missing permission and rejected requests must be handled as ordinary cases. “Another click every time from now on” is not an accurate description of the API.

FedCM mediates sign-in, not blanket privacy consent

FedCM mediates between a website and an identity provider through the browser and can enable sign-in without third-party cookies. Conventional federated sign-in does not universally depend on third-party cookies: a redirect flow can use cookies in a first-party context. FedCM requires suitable identity-provider endpoints and integration on the website.

An account chooser can appear during initial linking or sign-in. For previously linked accounts, FedCM supports automatic reauthentication under certain conditions. A signed-out state may require an identity-provider login flow; the blanket claim that “no existing login means no result” is too narrow. Other sign-in paths remain necessary for unsupported browsers and failures.

A browser permission or account choice is not automatically legal consent for additional processing. Google explicitly states that any required consent for purposes beyond authentication must be obtained separately.

Consequences for existing measurement and embeds

New dependencies on deprecated APIs increase maintenance risk. Existing integrations need an inventory: which interface is actually called, which measurements will disappear and which tested fallback is available? Removal and migration should follow the specific Chrome version, vendor guidance and application tests.

Not every stateful embed necessarily requires Partitioned. Depending on the function, options include partitioned cookies or other partitioned storage, Storage Access, FedCM or first-party integration. Server-side joining of identifiers is not a universal replacement either, and moving processing to a server does not by itself make that processing lawful.

Google explicitly mentions continued work on an interoperable Attribution standard. This establishes neither an immediately available replacement nor the end of all browser-assisted measurement. Continued support for an API is also no guarantee of unchanged long-term availability.