Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 8 min read

Chrome cookies: why google.com survives 'delete on close', again

If you set Chrome to delete site data when you close all windows, Chrome 152 still keeps google.com's cookies, local storage and session storage. Jeff Johnson, the Mac developer behind Lapcat Software, reproduced it on t

Chrome cookies: why google.com survives 'delete on close', again

If you set Chrome to delete site data when you close all windows, Chrome 152 still keeps google.com's cookies, local storage and session storage. Jeff Johnson, the Mac developer behind Lapcat Software, reproduced it on two Macs on September 5, 2026, and a Hacker News user reproduced it in open-source Chromium the same day. The same developer found the same kind of exemption for Google's sites in 2020, and Google fixed it then. If you rely on Chrome cookies being cleared, for privacy or for testing, this is the setting not doing what it says.

TL;DR

  • With "Delete data sites have saved to your device when you close all windows" on, and Chrome sign-in off, one Google search leaves google.com site data that survives a quit and relaunch.
  • What survives: cookies, local storage and session storage. As far as Johnson can tell, www.google.com is the only site exempted.
  • It reproduces in Chromium 152.0.7977.75 on Debian, so it sits in the shared code, not only in Google's branded build.
  • In October 2020 Chrome 86 kept data for YouTube and Google Search under the equivalent setting. Google called it a bug and fixed it. Six years later it is back.
  • I stamped it REVERT: a delete-everything setting that spares its owner is not a bug you get to ship twice.

What Chrome's "delete site data on close" setting should do

Chrome's site data page, chrome://settings/content/siteData, has a default behaviour for all sites. The strictest choice is "Delete data sites have saved to your device when you close all windows". Site data here means more than cookies: local storage, session storage, IndexedDB and service workers, everything a site can leave on your disk to recognise you next time.

The promise is simple: close the last window and every site starts from zero. It is a middle ground between normal browsing and incognito: extensions, bookmarks and history stay, tracking state does not. Developers use it to get a clean browser for testing sign-in flows and consent banners without clearing things by hand.

Why does Chrome keep google.com cookies?

Johnson's write-up sets up the cleanest case he can. On two Macs with Chrome 152.0.7977.83:

  1. Default search engine switched to DuckDuckGo.
  2. Site data set to delete when all windows close.
  3. Not signed into Chrome, and Chrome sign-in disallowed.
  4. chrome://settings/content/all empty, so no site starts with stored data.

Then one Google search, close the only window, reopen. The google.com site data is back, and it survives quitting and relaunching Chrome. It repeats every time. On disk, in ~/Library/Application Support/Google/Chrome/Default, the saved data is in Cookies, Local Storage and Session Storage. "As far as I can tell, www.google.com is the only site exempted by Chrome."

Jeff Johnson's post of September 5, 2026: Chrome exempts google.com from the user's site data setting

On Hacker News, saint_yossarian reproduced it in open-source Chromium 152.0.7977.75 on Debian sid. That matters because Chromium is the base for most other browsers, including several that sell themselves on privacy. Whether each of them inherits the behaviour depends on what they change, so check yours rather than assume.

Nobody outside Google knows why it happens or which release regressed it. Johnson says so himself: "I'm personally inclined to cite Hanlon's razor here rather than engage in conspiracy theories. Nonetheless, Google has no excuse for incompetence either … Perhaps some kind of unit tests for this feature? Move slower and don't break things." The HN thread was less charitable. Both readings end in the same place: the one domain that ignores your setting belongs to the company that wrote the setting.

The 2020 Chrome bug that came back

On October 7, 2020, the same author published "Chrome exempts Google sites from user site data settings" about Chrome 86.0.4240.75. With "Clear cookies and site data when you quit Chrome" on, Apple.com's data was wiped, but YouTube kept its database storage, local storage and service workers, and Google Search kept its local storage.

It was covered by The Register, Gizmodo and The Verge:

The Verge, October 2020:

The Verge reported that Google called it a bug and fixed it. A fixed bug returning in the same feature, for the same owner, is what a regression test is for. A test that Google's own domains obey the user's deletion setting would have caught it.

How to check if Chrome kept your Google cookies

You don't need to trust the blog post; you can look. Quit Chrome completely first, because it locks its databases while it runs. On macOS the default profile is the folder above; on Linux it is usually ~/.config/google-chrome/Default. Chrome's cookie store is an SQLite database with a cookies table, so you can list which hosts still have cookies after a "delete on close" session:

# quit Chrome first; macOS, default profile
# (recent Chrome keeps the file in Default/Network/Cookies, older versions in Default/Cookies)
sqlite3 ~/Library/Application\ Support/Google/Chrome/Default/Network/Cookies \
  "SELECT host_key, name FROM cookies WHERE host_key LIKE '%google.com';"

If the setting worked, that query returns nothing after you close all windows. Local and session storage live in LevelDB folders next to it (Local Storage/leveldb, Session Storage), which are harder to read but easy to list.

What you can do while this stands:

  • Test in a fresh profile or a guest window when you need a truly clean state, instead of relying on the close-to-delete setting.
  • Clear google.com by hand from the site data page if it matters to you, and check again after the next Chrome update.
  • If you build on Chromium, add your own check to your release tests: set the policy, visit the vendor's own domains, close, and assert the store is empty.
  • If you rely on privacy extensions in Chrome, note the next section.

Chrome 152's other escapes: V8 and uBlock Origin

The google.com exemption landed in a busy week for Chrome. On September 3, Chrome 152 shipped 12 security fixes, including CVE-2026-85046, a type confusion in V8. "Google is aware that an exploit for CVE-2026-85046 exists in the wild." The reporter's bounty was $1,000.

On August 31, Google removed all remaining Manifest V2 extensions from the Chrome Web Store, uBlock Origin included. Installed MV2 extensions on Chrome 138 or earlier stay but get no updates; Brave self-hosts AdGuard, uBlock Origin, uMatrix and NoScript. Tuta's reply ended with "Long live uBlock Origin!"

So in one week Chrome had a sandbox escape that paid $1,000 and a settings escape that paid Google. On Wednesday I stamped Google's Gemini 3.8 Flash SHIP IT. That stands; this is a different product.

Also this weekend: the qBittorrent "sandbox escape"

The weekend's top Hacker News story, 1,278 points (HN), was a Mastodon post from August: "my copy of QBittorrent escaped its sandbox last night and downloaded a whole bunch of content owned by major corporations, and then my copy of Jellyfin broke containment and added those unfortunately-downloaded media files to its various libraries." The author is "conducting an internal investigation". It is a parody of the summer's AI-lab sandbox-escape reports, and the only one where everyone agrees who did it.

Also in this episode: Isar Aerospace, Spotify's token trick, AI on-call

Isar Aerospace reached orbit. At 10:12 pm CEST on Saturday, Spectrum lifted off from AndΓΈya, Norway, and reached orbit a little over seven minutes later, then deployed five cubesats (Space.com). It is the first orbital launch from Western European soil. The first flight, in March 2025, crashed in under a minute. CEO Daniel Metzler says "Europe now has sovereign access to space" (press release); the top HN comment notes French Guiana is EU territory.

Spotify cut Claude Code reads by 90 %. Spotify's engineering blog describes shunt, a Claude Code plugin whose PreToolUse hook blocks any Read of a file over 350 lines and routes it to Gemini 2.5 Flash. The 90 % is mean savings on bulk reads. The post's own caveats: 10 to 30 seconds per delegation, no delegated edits, and the cheap model missed a thread-safety bug Claude caught.

AI on-call and comprehension debt. Sylvain Kalache, a LinkedIn SRE in 2012 and now at Rootly, argues that AI resolving routine incidents removes the practice humans used to learn their systems (post). He cites Bainbridge's 1983 "The Ironies of Automation" and predicts faster routine fixes and slower complex ones. Rootly sells incident simulators, which he discloses.

A/I shuts down. The Italian collective Autistici/Inventati announced it is closing after 25 years of hosting activists' mail and sites, and will publish instructions for backing up blogs and mailboxes.

Verdict: REVERT

I stamped it REVERT. Chrome offers a setting that says delete everything when I close the window. It deletes everything except google.com. Google fixed the same class of bug for YouTube and Search in 2020, and it has come back in the same feature. Whether it is intent or a missing test, the fix is the same: honour the setting for every domain, and ship the regression test with it.

FAQ

Does Chrome delete Google cookies when you close it?
Not in Chrome 152 with "delete on close" set, per Jeff Johnson's tests: google.com cookies, local storage and session storage survive a quit.

Is this a Chromium bug or a Chrome bug?
A HN user reproduced it in open-source Chromium 152 on Debian, so it is in the shared Chromium code.

Has this happened before?
Yes. In October 2020 Chrome 86 kept YouTube and Google Search data under the equivalent setting. Google called it a bug and fixed it.

Sources

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode Β· Subscribe on YouTube Β· the written diff lands in your inbox every morning at thedailydiff.dev.

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram β†— Reddit 🟧 HN
← News πŸ” Cybersecurity 🏠 Home