Chrome wipes everything but Google

Chrome ships a carve-out for its own vendor. Enable “Delete data sites have saved to your device when you close all windows” and the browser clears cookies, Local Storage, and IndexedDB for every origin on shutdown. Except Google’s. Data for google.com and youtube.com survives the wipe. The setting states every site. The behavior is every site minus Google.

This is not the first disclosure. Jeff Johnson at Lapcat Software documented the identical exemption in 2020. Chrome retained google.com and youtube.com cookies after a user configured clear-on-exit. Google acknowledged it, labeled it a bug, and said a fix was inbound. The behavior has resurfaced. “Again” is the operative word, and the recurrence is what matters. A one-time defect gets fixed once. A structural property returns.

The condition is a trust boundary drawn around first-party Google, enforced inside the browser Google writes. Classify it as CWE-359, exposure of private personal information to an unauthorized actor - here the unauthorized actor is the vendor operating outside a control the user explicitly set. The user action is a wipe. The stated scope is all site data. The delivered scope excludes the origin set with the highest identity value in the profile. The gap between the two is the exposure.

There is a second Google-only channel in the same binary. The X-Client-Data header, also called the variations header. It is a base64-encoded serialized protobuf listing the field-trial and experiment IDs the browser instance is enrolled in. Chrome attaches it to requests bound for Google-owned domains - google.com, youtube.com, doubleclick.net, googlesyndication.com and the rest of the property list - and to no other origin. Documented publicly since 2019. Each ID is low-entropy and the set is semi-stable across restarts. In aggregate it narrows the instance. It is a fingerprinting surface handed to one party by construction, not by user consent. The header is suppressed in Incognito, which is the tell - a value understood internally as non-identifying would not need suppression.

The justification for the cookie exemption is sign-in and sync. Chrome ties browser identity to a Google account. Auth state for accounts.google.com must persist for the stay-signed-in model to hold across restarts. Retaining that state on exit keeps the account session alive. Defensible in isolation. The problem is scope leakage. The exemption does not stop at the authentication cookie. It covers general site data for the Google domains, so the retained set includes tracking and preference cookies that have no role in keeping a user signed in. The narrow requirement justifies a broad carve-out.

What the persistence enables is straightforward. A user who sets clear-on-exit expects a clean profile at next launch. Google origins keep NID, plus the auth and identity cookies - SID, HSID, SAPISID, and the __Secure-1PSID family. Those are stable identifiers and live session tokens. The user’s stated intent is defeated for the exact origins where defeating it matters most. Cross-session correlation continues against a user who took the documented step to end it.

The security reachability follows from where those cookies live. The Chrome cookie store is a file - the Cookies SQLite database under User Data\Default\Network\Cookies in the profile directory. Values are encrypted. Historically with DPAPI keyed to the user. Since Chrome 127, with App-Bound Encryption, which binds the decryption key to a system service to raise the cost of theft by a process running as the user. Any code executing in the user context that can read and decrypt the store reads the cookies. Infostealers do precisely this. RedLine Stealer, Lumma, Raccoon, StealC. The technique maps to MITRE T1539, steal web session cookie. When a user wipes site data and the Google cookies remain, the tokens that survive the wipe are the ones that ride SAPISID-based authentication into a Google account - the highest-value credentials in the jar.

App-Bound Encryption changed the cost curve, not the outcome. Chrome 127 moved the cookie key behind a system service, so a plain read of the SQLite file no longer yields plaintext. Stealer families adapted inside months. The working approaches invoke the decryption path from inside the browser’s own trust context - through the remote debugging port bound on 127.0.0.1, through injection into a live chrome.exe, or by calling the elevation service as the user it already trusts. ABE raised the bar to code execution in the user session and inside the browser context. That is a higher bar than a file copy. It is not a wall. The retained Google cookies sit behind that same encryption, so the exemption inherits ABE’s residual exactly - enough to stop a naive copy, not enough to stop a resident stealer.

The real-world pipeline is the infostealer market. Stolen Chrome cookie sets are packaged and sold. A live 1PSID and SAPISID pair grants access to the Google session with no password and no MFA prompt - the session is already authenticated. That is T1550.004 in effect, use of an alternate authentication material, followed by T1185, browser session hijacking, once the token is replayed. Clear-on-exit is a control the user believes reduces this window. The exemption removes the reduction for the single origin set an attacker most wants. The control still works against every other site. It does not work where it counts.

Session replay is the quiet half of the chain and the harder half to see. A stolen 1PSID replayed from attacker infrastructure produces an authenticated Google request that is structurally identical to a legitimate one - same cookie, same header shape, same endpoint. The distinguishing signals are contextual, not content-based. A new source ASN. A device and user-agent pairing the account has not presented before. An impossible-travel delta against the prior session. Those signals live in Google-side account telemetry, not in the victim’s SIEM. The defender whose user was robbed sees the theft at the host if the file read fired an alert, and sees nothing of the reuse. The two halves of the chain are visible to two different parties, and neither party sees both.

The pattern is consistent across Chrome features, not confined to one toggle. X-Client-Data sends a fingerprint to Google alone. The cookie exemption retains Google state through a user wipe. The Privacy Sandbox rollout - Topics, Protected Audience - reworks tracking into browser-mediated APIs while Google sits on both the buy and sell side of the ad auction the browser now brokers. Each is defensible on its own terms. Together they define a first-party Google sphere that the settings surface does not fully govern.

What defenders see splits between network and host. On the network, a TLS-terminating proxy or an mitmproxy log shows X-Client-Data present on Google-bound requests and absent everywhere else, and shows a Cookie header still riding to google.com in a session that the user configured to clear. Passive Wireshark on the wire shows neither - the traffic is TLS - so the visibility depends on inspection at a break point, not a tap. On the host, the signal is file access. Sysmon Event ID 11 for writes to the Cookies database and the Local Storage leveldb, Event ID 1 for the process that touched them, and for theft, a handle open and read against the Cookies file by a process that is not chrome.exe. That last one is the infostealer signature worth alerting on. EDR products flag non-browser process access to the Chrome user data directory as a credential-theft category. That detection is where the exposure gets caught, if it gets caught.

What does not fire is the exemption itself. Chrome retaining its vendor’s cookies is documented behavior, not an anomaly, so no rule triggers on it. There is no event that says a wipe was requested and partially honored. User intent and browser behavior diverge silently, and telemetry has nothing to correlate because nothing logs the divergence. The detection gap is not a missing rule. It is the absence of any observable event to write a rule against.

Treat the current instance as a bug and assume it gets fixed a second time. The structural fact does not move. The browser and the dominant web property share an owner, and sign-in, sync, variations, and ads each supply a rationale for a Google-only path. The residual after any patch is the same as before it - the consumer toggle is advisory for Google origins, and its scope is set by the vendor, not the user. The deterministic control is enterprise policy. ClearBrowsingDataOnExitList and managed profile controls behave by administrative definition rather than by UI intent, and their scope is auditable. That distinction is the technical reality: policy-enforced clearing is a control, the settings toggle is a preference the vendor may honor selectively.

Under the Privacy Act 1988 and the Australian Privacy Principles, a user-facing control that does not perform the action it names is a transparency and consent problem before it is an engineering one. For SOCI-regulated entities, Google session tokens persisting in the browser profile through a documented clear is a data-handling fact to model in the threat picture, not a footnote - the tokens are reachable by any user-context code and they authenticate to external accounts. The exemption does not create the infostealer. It raises the value of what the infostealer already reaches, and it does so against the user who took the step meant to lower it.