Partitioned Cookies (CHIPS): Privacy and Safe Embedded Sessions

Embedded sessions often fail for a reason that looks like a login bug: the same third-party service sees a different cookie jar on each top-level site. The Partitioned cookie attribute, commonly called CHIPS, makes that separation explicit. The practical answer is to model the top-level site as part of the cookie key, then decide whether the embedded feature can work with isolated state. BotBrowser can repeat an authorized profile journey to observe cookie behavior under declared browser and proxy conditions; it cannot merge partitions, grant storage access, or prove that an application’s identity and consent model is correct. BotBrowser supports repeatable authorized CHIPS workflows; it cannot merge cookie jars or grant storage access.

TL;DR

• Partitioned stores a cookie in a jar keyed by the top-level site and the cookie’s origin.
• CHIPS is not the same as general cookie management, all browser storage partitioning, or the Storage Access API.
• A partitioned cookie can keep an embedded session separate, but it does not authenticate a user or replace consent and authorization.
• Test a real embed, a first-party route, rejection, expiry, and a top-level-site change with synthetic accounts.
• BotBrowser can repeat an authorized profile workflow and report observed cookie results, but it cannot merge jars, alter browser policy, or certify server-side identity.

Contents

• What Partitioned means
• A cookie fixture
• CHIPS versus neighboring APIs
• Privacy and identity boundaries
• Evidence and decision matrix
• Conclusion
• FAQ

What Partitioned means

RFC 6265bis defines cookie syntax and processing rules, while browser documentation describes the Partitioned attribute as a request to keep a cookie in partitioned storage. The partition key includes the top-level site and the cookie’s origin. An embedded service at https://embed.example can therefore receive one cookie jar when embedded by news.example and another when embedded by shop.example. The browser does not treat those jars as one shared third-party identity.

The attribute is used with Secure, and deployment still needs a compatible browser, correct Set-Cookie syntax, and a server that understands the resulting isolation. A cookie can be syntactically accepted while the application still fails because the iframe is not the expected origin, the server rejects the session, or the feature depends on an unpartitioned identifier. Separate browser acceptance from application success in every test record.

Partitioning is about storage scope, not secrecy. JavaScript running in the embedded origin can still read cookies available to that origin under normal cookie rules. The server can still receive the cookie on requests that include it. HTTPS protects transport in transit, but it does not decide who may use an account or how long a service retains events. Keep those decisions in authorization, consent, and data-governance contracts.

A cookie fixture

Use a synthetic endpoint and two top-level test pages. The embedded service sets a short-lived cookie and returns a non-sensitive session label. The fixture should vary one input at a time:

Set-Cookie: embed_session=synthetic-a; Secure; HttpOnly; SameSite=None; Partitioned; Max-Age=900

Expected behavior: the embed can send embed_session again within the same top-level site, a different top-level site receives a different jar, and a first-party route does not automatically reveal the embedded partition. The exact browser version and deployment mode belong in the record. Do not use a customer account, a real token, or a persistent identifier for this check.

Add a negative fixture that omits Partitioned, one that omits Secure, and one that uses an invalid attribute order or value. The goal is to see the browser and server’s observable result, not to infer a hidden implementation. Record whether the cookie was stored, sent, rejected, expired, or absent from the request. A missing cookie is not enough to conclude that storage partitioning caused the failure.

Test navigation and lifecycle separately. Reload the same top-level page, open the embed in a new tab, clear the synthetic profile, wait past the short expiry, and then change the top-level site. A session that survives reload but not a top-level-site change is consistent with partitioning. A session that disappears after profile cleanup is consistent with the cleanup operation. These observations should remain separate from claims about browser identity.

CHIPS versus neighboring APIs

Cookie management is the application work of setting, reading, expiring, scoping, and deleting cookies. It answers “which cookie should this request use?” CHIPS adds a storage boundary to that work. A cookie management library cannot make an unpartitioned cookie safe by renaming it, and it cannot decide whether a user should be logged in across unrelated top-level sites.

General storage partitioning covers more than cookies. A browser may isolate caches, DOM storage, or other state according to a site or network partition key. The exact covered surfaces and compatibility conditions are browser concerns. Do not infer that a partitioned cookie proves every storage surface is partitioned identically. Test the surface the product actually depends on and name the untested surfaces in the support record.

The Storage Access API is a different mechanism. It lets an embedded document request access to unpartitioned cookies under browser permission and user-interaction rules. It is not a way to turn every Partitioned cookie into a shared cookie. A product can use CHIPS for isolated embedded sessions and request storage access for a distinct first-party continuity use case, but the two paths need separate consent copy, tests, and fallback behavior.

Do not use a top-level redirect as an implicit substitute for either model. A redirect can change the browsing context and account journey, but it does not make an embedded third-party cookie first-party by definition. Document whether the user leaves the top-level site, which origin handles the credential, and how the user returns. The visible journey matters as much as the cookie attribute.

Privacy and identity boundaries

Partitioned cookies reduce cross-site reuse of one embedded cookie jar. They do not make a service anonymous, prevent all correlation, or remove the need for consent. The top-level site, embedded origin, server logs, request timing, and account actions can still create application-level records. Keep the purpose narrow: a partitioned cookie may preserve a shopping widget’s local session without making that session a cross-site identifier.

Identity belongs to an explicit account contract. A cookie value is a bearer credential only within the server’s authorization rules, and a partition key does not establish who is behind a browser. Require server-side authorization for every state-changing action, rotate session material, and expire it on the documented schedule. Never put secrets or account data in the partition key or in a URL used to set a cookie.

For privacy review, record the top-level-site class, embedded-origin class, cookie attributes, result state, and retention decision. Avoid full URLs, account names, raw cookie values, and message bodies. A coarse result such as partitioned-sent, partitioned-missing, rejected, or expired usually gives support enough information to choose the next test.

BotBrowser’s topic-specific capability is repeatable observation of an authorized embedded-session workflow across declared browser, platform, profile, and proxy inputs. Its limitation is that it cannot merge cookie jars, grant Storage Access permission, alter a server’s authorization decision, or prove that a cookie policy satisfies legal consent requirements. Treat a profile run as evidence about the tested journey, not as a universal privacy certification.

Evidence and decision matrix

Observation	Safe interpretation	Next action
Same embed sends the cookie after reload on one top-level site	The tested partition retained the synthetic session	Continue with expiry and cleanup checks
A second top-level site receives no matching cookie	Isolation is consistent with the partition key	Verify the server has a separate login or explicit handoff path
Cookie is rejected before a request	Syntax, Secure, context, policy, or browser support may be involved	Inspect the network fixture and compatibility record
Storage Access request is denied	The unpartitioned path is unavailable in this context	Keep the isolated CHIPS flow or show a user-directed fallback
Session disappears after expiry or profile cleanup	The tested lifecycle removed it	Re-authenticate deliberately; do not silently reuse another jar

This matrix is the reader artifact. It connects an observable cookie result to one safe product decision. Repeat it for first-party, embedded, private, headed, and headless contexts only when those are supported deployments, and keep each result labeled.

Operational rollout.

Ship a partitioned-cookie change behind a reversible server flag. The server should accept a new synthetic session label, expose a clear fallback for older browsers, and retain the old path only for the documented migration window. Do not silently copy an unpartitioned identifier into a partitioned cookie. That creates a new scope without explaining its consent and account meaning.

Monitor outcome classes rather than raw cookie values. Compare session start, session continuation, explicit sign-in, and sign-out rates by top-level-site class and browser support bucket. A lower continuation rate can mean correct isolation, a server bug, or a missing fallback. Pair the metric with a deterministic fixture before changing the cookie policy.

Document deletion. Removing a partitioned cookie from one top-level site does not imply that an account or server record is deleted. Define client cleanup, server revocation, and retention separately. A user-facing sign-out should clear the local jar and invalidate the server session when the product contract requires it. Keep those actions auditable without retaining raw cookie material.

Migration checklist.

Start with an inventory of embedded routes and classify each session as isolated, first-party, or explicitly shared. For every isolated route, record the top-level-site class, embedded origin, expected cookie attributes, and sign-out owner. This small contract prevents a deployment from silently changing a cookie from partitioned to unpartitioned merely because a framework default changed.

Add a compatibility row for older browsers or managed environments that do not implement the attribute. The fallback should preserve the task, explain the reduced continuity, and avoid copying a cross-site identifier into a new jar. A user who signs in again is safer than a product that silently links sessions across sites. Keep the fallback visible in support documentation and localization.

Incident diagnosis.

When a user reports a missing embedded session, reproduce the same top-level site first. Inspect the Set-Cookie response, the request cookie row, expiry, and profile cleanup state. Then repeat on a second top-level site. Do not begin by clearing every browser store, because that removes the evidence needed to distinguish partitioning from expiration, a server rejection, or an origin mismatch.

If the cookie appears on the first site but not the second, the result is consistent with CHIPS and should lead to an explicit handoff or sign-in path. If it disappears on the first site after reload, inspect Secure, SameSite, expiry, response headers, and the endpoint’s authorization response. A clean diagnosis names the observed row and the next owner; it does not infer a person from the cookie value.

Review after changes.

Re-run the two-site fixture when the browser baseline, embedded origin, proxy, consent prompt, account service, or sign-out flow changes. Keep the synthetic value and expected result stable so a diff is attributable to one change. Review both headed and headless modes only when both are supported products, and retain their records separately. A passing headed test cannot establish a headless deployment guarantee.

The review record should include the fixture revision, browser release, profile family, top-level-site class, embedded origin class, attribute set, visible fallback, and deletion decision. It should exclude raw values and account identifiers. This is enough for a maintainer to decide whether to keep CHIPS, request Storage Access, or route the user through a first-party page.

Conclusion

Use Partitioned when an embedded feature needs a per-top-level-site session and can tolerate that isolation. Distinguish it from general cookie management, broader storage partitioning, and Storage Access permission. The next safe action is to run the synthetic two-top-level-site fixture, inspect the cookie request rows, and verify sign-out, expiry, rejection, and fallback behavior.

FAQ

Does CHIPS share a login across every site?

No. It intentionally separates the embedded cookie jar by top-level site. A shared login needs a separate, explicit account journey and authorization contract.

Is a Partitioned cookie a replacement for consent?

No. Storage scope does not decide whether processing is lawful or expected. Keep consent and privacy notices aligned with the feature’s purpose.

Is CHIPS the same as the Storage Access API?

No. CHIPS provides partitioned storage. Storage Access is a permissioned request for unpartitioned cookie access under browser rules.

Can BotBrowser merge two partitions?

No. It can repeat an authorized test workflow and report observed results, but it cannot change browser storage policy or server authorization.

Support handoff.

When an embedded session fails, support should capture only the top-level-site class, embedded-origin class, browser release, profile mode, and visible fallback. This bounded packet lets owners compare one controlled fixture without requesting a customer cookie value.

A release rehearsal.

Before enabling the attribute for real users, rehearse the complete journey with a clean synthetic profile. Open the first top-level site, complete the embedded sign-in, reload, sign out, and verify that the local session disappears. Open the second top-level site and confirm that it starts with its own state. Repeat with the documented fallback. The expected result is an understandable message and a deliberate sign-in action.

Keep rehearsal inputs stable. Use the same short-lived cookie name, response headers, account class, and endpoint revision for every browser candidate. Change one variable at a time and write that variable in the result row. This makes a regression actionable: a missing cookie after a browser update differs from a missing cookie after a server framework update or a changed consent prompt.

The product owner should approve the visible boundary before launch. Explain that an embedded session is local to the current top-level site and another site may ask the user to sign in again. Explain what sign-out clears locally and what the server revokes. This copy is part of the privacy contract, not a troubleshooting detail.

Record the decision in the release note, link the synthetic fixture, and assign an owner for expiry and deletion checks. Revisit it whenever an embedded origin or consent flow changes.

Sources and next reading

• MDN: Cookies
• MDN: Set-Cookie and Partitioned
• RFC 6265bis
• W3C Privacy Principles
• Storage Access API
• Browser storage partitioning and privacy

Sources

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
• https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/
• https://www.w3.org/TR/privacy-principles/
• https://botbrowser.io/docs/reference/advanced-features/