Chrome exempts Google's domains from user site-data controls

Chrome 152.0.7977.83 keeps google.com cookies, Local Storage, and Session Storage on disk after you close every window, even with the browser set to delete all site data on close. A report on Lapcat Software reproduced this on two Macs. The content setting at chrome://settings/content/siteData was on its “Delete data sites have saved to your device when you close all windows” default. Chrome was not signed in, sign-in was disallowed, and the default search engine had been switched from Google to DuckDuckGo to rule that out.

From a clean state, chrome://settings/content/all showed nothing saved. One Google search, then close the only open window, and google.com data was back. It survived quitting and relaunching. Delete it, repeat the search, and it returned every time. In ~/Library/Application Support/Google/Chrome/Default the persisted data was Cookies, Local Storage, and Session Storage, and www.google.com was the only site getting the exemption.

The same author reported a near-identical bug six years ago, when Chrome exempted Google-owned sites from the automatic site-data deletion setting. That one got picked up by The Register, The Verge, and Gizmodo, and Google fixed it after the report. The symptom is the same as it was then.

This time the author was told the cause is Compression Dictionary Transport, a Chromium-specific feature, and that google.com’s exemption is a coincidence: google.com is an early adopter of it. Compression Dictionary Transport lets a server nominate an already-fetched resource as a dictionary for Brotli or Zstandard compression of later responses, which shrinks transfers for sites whose assets barely change between versions. The dictionary has to persist across page loads to pay off, so the browser stores state keyed to the origin. If that storage path doesn’t honor “delete on close,” any origin using the feature keeps data past the point where the user asked for it gone. google.com happens to be an early adopter, which is why it is the one showing the leak.

For anyone treating “delete site data on close” as a privacy boundary, it isn’t one in this build. Whatever paths the toggle clears, the data this feature leaves behind isn’t among them. On a shared or sensitive machine where site data genuinely has to be gone between sessions, the dependable options are a throwaway profile or guest session per use, or clearing the profile directory out of band, rather than trusting the in-browser setting. You can check your own build the way the report did: browse, close all windows, and look at chrome://settings/content/all for anything left over.

A public Chromium bug report based on the original post already exists, filed by someone other than the author.