Build1 publisher3 min readPublished
Chrome 152 again exempts google.com from its delete-site-data-on-close setting
Chrome 152 keeps google.com's cookies and storage after 'delete on close' is switched on, developer Jeff Johnson found. Google fixed a similar exemption in 2020, and the same behaviour in open-source Chromium means other browsers and test rigs need their own check.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Hacker News user saint_yossarian reproduced the behaviour the same day in open-source Chromium 152.0.7977.75 on Debian sid.
- In October 2020, Chrome 86 kept YouTube and Google Search data under the equivalent quit-time setting while wiping Apple.com's data.
- Nobody outside Google knows why the google.com data survives or which Chrome release brought the behaviour back.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure People using the setting as a middle ground short of incognito carry google.com tracking state from one session to the next, on a domain owned by the company that wrote the setting.
- constraint Test suites that rely on the setting to reset sign-in or consent-banner state cannot assume google.com starts clean, so every run has to confirm the reset from the cookie store.
- decision Maintainers and users of Chromium-based browsers have to test their own builds, because whether a fork inherits the exemption depends on what it changed.
- precedent The 2020 fix did not last, so any new fix will stay in place only if a regression test covering Google's own domains ships with it.
In Chrome's settings, site data covers more than cookies. It also includes local storage, session storage, IndexedDB and service workers, which is everything a site can leave on disk to recognise the browser on its next visit [2]. The strictest default on chrome://settings/content/siteData is "Delete data sites have saved to your device when you close all windows" [2]. Developers use it to get a clean browser for testing sign-in flows and consent banners without clearing state by hand [11].
Johnson set up the cleanest test he could. Chrome sign-in was off and disallowed, the default search engine was DuckDuckGo, and chrome://settings/content/all listed no sites before the test started [4]. After one Google search and a restart, the leftover data was in the Cookies, Local Storage and Session Storage stores under ~/Library/Application Support/Google/Chrome/Default [5]. "As far as I can tell, www.google.com is the only site exempted by Chrome," Johnson wrote [7].
The Chromium result means more people have to check. Hacker News user saint_yossarian reproduced the behaviour in open-source Chromium 152.0.7977.75 on Debian sid [6]. If that result holds, the exemption is in shared code and not only in Google's branded build [6]. Most other browsers are built on Chromium, several of them marketed on privacy. Whether each one inherits the behaviour depends on what its maintainers changed [8]. So far the evidence from outside Google Chrome is that single Chromium reproduction on a single Linux distribution.
The 2020 exemption covered different sites and data. In Chrome 86.0.4240.75, with "Clear cookies and site data when you quit Chrome" enabled, Apple.com's data was wiped. YouTube kept its database storage, local storage and service workers, and Google Search kept its local storage [9]. The Verge reported that Google called it a bug and fixed it [10]. In 152 the setting has a new name, and google.com keeps its cookies as well [1][2][9]. Chrome 86 and Chrome 152 are 66 major versions apart [17].
Nobody outside Google knows the cause or which release brought it back [12]. Johnson did not accuse Google of doing it on purpose. "I'm personally inclined to cite Hanlon's razor here rather than engage in conspiracy theories," he wrote [13]. He ended the same passage with: "Move slower and don't break things." [14] The dev.to write-up argues that when a fixed bug comes back in the same feature, for the same owner, a regression test should have caught it [15]. A test that Google's own domains obey the deletion setting would have caught this one, the post says [15]. I agree. Every exemption found in this feature so far has been on a Google site [7][9]. A test should cover Google's domains before any others.
Checking a machine takes a few minutes. Quit Chrome completely first, because it locks its databases while it runs [16]. The cookie store is an SQLite database with a cookies table, so listing the hosts in that table after a delete-on-close session shows exactly what survived [16]. For a test harness, I'd run that query as an assertion after each teardown and stop trusting the setting to reset the browser. On Linux the profile is usually at ~/.config/google-chrome/Default [16].
What to watch
- Whether Google acknowledges the Chrome 152 behaviour as a bug and ships a fix with a regression test that covers its own domains.
- Reproductions, or clean results, in specific Chromium-based browsers, especially those marketed on privacy.
- A bisect of Chromium builds that identifies the release where the google.com exemption came back.