A partitioned cookie solves one narrow problem: it lets an embedded origin keep a separate cookie jar for each top-level site. That can help an iframe chat widget remember a handle, but it does not reconstruct a conversation by itself.
Imagine chat.example embedded on shop-a.com and shop-b.com. With CHIPS, the browser keys a Partitioned cookie by both the embedded site and the top-level site. The cookie available on shop-a is not the cookie available on shop-b. That reduces cross-site tracking, but it also means CHIPS is not a shared identity system. The distinction matters when debugging a session that seems to disappear.
What still has to exist
A reliable restore flow needs three pieces outside the browser policy:
- An opaque conversation handle. Do not put the transcript, email address, or customer record in the cookie.
- A server-side mapping from that handle to the conversation the user is allowed to resume.
- A fallback when storage is unavailable, such as an explicit sign-in or a first-party continuation flow.
A typical candidate looks like this:
Set-Cookie: __Host-chat=opaque-id; Path=/; Secure; HttpOnly; SameSite=None; Partitioned
Partitioned requires Secure. A cross-site iframe normally also needs SameSite=None. The __Host- prefix keeps the cookie host-bound by forbidding Domain and requiring Path=/. HttpOnly is appropriate when only the server needs the handle.
None of those attributes prove that the browser accepted the cookie, retained it, or will send it in the context you care about.
Test behavior, not API presence
Checking that localStorage, IndexedDB, or document.cookie exists is not enough. Privacy modes, partitioning, permissions, sandbox flags, and browser policy can still make reads or writes fail.
Run a short-lived write/read/delete probe inside the real iframe. Record which operation failed and clean up every temporary value. For cookies, test a disposable candidate and treat the result as evidence for that browser and embedding context, not a universal guarantee.
I maintain MonoTools. Its Storage Probe checks localStorage, sessionStorage, IndexedDB, and a short-lived Partitioned cookie candidate locally. It does not request Storage Access permission or claim that a passing probe guarantees durable identity.
CHIPS is a browser storage boundary. Session restoration is still an application protocol.
Top comments (0)