Chrome Exempts Google from the Privacy Settings You Think You Set. Again.

Chrome Has a Six-Year Habit of Exempting Google from the Privacy Settings You Think You Set

Jeff Johnson published a blog post on September 5, 2026 documenting that Chrome version 152 once again persists google.com cookies and local storage after you close all windows — even when your explicit setting is to delete all site data on window close. This is not a new story. Johnson published the exact same finding in 2020. Google fixed it then. Now it is back.

I want to be precise about what “it is back” means, because the framing matters enormously. This is not a regression in the conventional sense — a developer breaks feature A while shipping feature B. What we are looking at is a structural property of a browser built by an advertising company: the browser and the ad network are not separate products with separate incentive structures. They share one.

The technical facts are simple. Johnson reproduced the issue on two Macs running Chrome 152.0.7977.83. He changed his default search engine to DuckDuckGo to eliminate that variable. He verified he was not signed in to Chrome. He set the default behavior to delete all site data on window close. He opened a Google search, closed the window, and found google.com cookies, local storage, and session storage still present in ~/Library/Application Support/Google/Chrome/Default. As far as he could tell, www.google.com was the only site exempted.

The engineers at Google will almost certainly call this a bug. Hanlon’s razor is popular in tech culture precisely because it defuses the discomfort of structural analysis. But whether this is a deliberate exemption or repeated incompetence is, from a systems-design perspective, almost irrelevant. The outcome is identical either way: a browser whose stated privacy controls do not apply uniformly to the entity that built the browser.

Why This Keeps Happening: The Architecture of Trust in Browsers

The browser is, at its core, a trust intermediary. It sits between you and every website you visit. It enforces the rules of the web — CORS, same-origin policy, content security policy, cookie scope, storage partitioning. Your operating system trusts the browser to implement these rules faithfully. You trust the browser to execute your preferences. The websites trust the browser to enforce the security model that makes it safe for them to use cookies and local storage at all.

The problem with Chrome is that this trust intermediary is not independent. Chrome is built and maintained by Alphabet, the same corporate entity whose core revenue model is tracking what you do across the web and selling that signal to advertisers. Google Search, Google Ads, YouTube, Google Analytics, Google Tag Manager — all of these are monetization surfaces that benefit from persistent identifiers and behavioral signals. Cookies and local storage are the low-level substrate of that signal.

When you set Chrome to delete all site data on window close, you are asking the browser to do something that structurally conflicts with its owner’s business model. I am not saying Google engineers consciously code around this setting. I am saying that the incentive to test this code path rigorously — to write thorough unit tests, to catch regressions in pre-release, to escalate quickly when a researcher files a report — is systematically lower than the incentive to ship features that keep users in the Google ecosystem.

The result is what we observe: a six-year-old bug that was fixed once and has reappeared. This is the expected output of an organization where the browser privacy team and the ad revenue team are not in alignment. And the alignment problem is not something a motivated VP can solve with a memo. It is baked into the corporate structure. Google’s browser business and Google’s advertising business are the same business. They share infrastructure, they share engineers across rotations, and they share the same quarterly revenue targets. No amount of internal policy will fully insulate the privacy controls of the browser from the interests of the ad network, because they are not separate institutions.

What the Exemption Actually Does at the Storage Layer

To understand why this matters technically, you need to understand what “site data” means in a modern browser and why it is not just cookies.

Johnson confirmed that Cookies, Local Storage, and Session Storage were persisting for google.com. That is already significant. A persistent cookie from google.com can carry a stable user identifier across sessions. If you search on Google on Monday, close Chrome, open it again on Wednesday, and Google can read the same cookie, you have not achieved the privacy outcome you intended. You have achieved a false sense of privacy — which is arguably worse than no privacy setting at all, because it affects how you behave.

Local storage persistence is less obvious but equally problematic. Google Search uses local storage extensively for preferences, experiment assignments, and session context. Some of these values are stable identifiers or proxies for stable identifiers. A fingerprinting pipeline that reads local storage values alongside IP address and User-Agent has far more signal than one that starts fresh every session.

The combination — persistent cookies plus persistent local storage — means that a user who believes they have configured Chrome to forget their Google activity between sessions is not actually getting that behavior. The configuration dialog is decorative.

The Six-Year Pattern and What It Tells Us About Software Maintenance

I have worked on browser-adjacent infrastructure, specifically on policy enforcement layers that translate user privacy preferences into actual storage decisions. The pattern Johnson describes — a bug fixed after external pressure, then reintroduced in a later version — is a well-known failure mode in large codebases. It has a name in some organizations: regression by abstraction.

Here is how it happens. In 2020, a developer fixes a specific code path: the storage eviction logic that runs on window close was not applying to Google-owned origins. The fix is targeted. It modifies the condition that determines which origins are subject to the “delete on close” rule. Tests are written for that specific case. The fix ships.

Over the next six years, Chrome’s storage architecture evolves substantially. Storage partitioning — a major privacy initiative Chrome shipped across 2022-2024 — reorganizes how storage is keyed. The Privacy Sandbox work touches the same subsystems. Refactors change the ownership of the eviction logic. The original fix, which was written against the old architecture, either does not survive the migration or survives in a form that no longer covers the same code path that runs on the new architecture.

The regression test for the original bug passes because it is testing a code path that still works. A new code path — introduced by the architectural changes — does not have a corresponding test for the Google-specific exemption case, because the people writing the new code were not aware of the old bug or assumed it was no longer relevant.

This is not malice. It is the ordinary consequence of a codebase with tens of millions of lines of C++ evolving faster than its test coverage. The question is not whether this kind of regression is possible — of course it is — but why it required an external researcher to find it, six years after the first occurrence, rather than the Chrome team’s own QA processes.

The answer, I think, is that the test coverage for privacy-adversarial cases involving Google’s own properties is systematically weaker than it would be in an organization without Google’s revenue structure. This is not a conspiracy claim. It is an incentive claim. The developer who writes thorough tests for “does the delete-on-close setting correctly apply to google.com?” is working against the implicit grain of their employer’s business model. That creates subtle friction. Subtle friction, at scale, produces systematic gaps.

Why Firefox and Safari Are Not Having This Conversation

Let me make the structural comparison explicit, because the contrast is instructive.

Mozilla’s revenue comes primarily from search deals — Google pays Mozilla to be the default search engine in Firefox. This creates its own alignment problem, which Mozilla has been transparent about. But Mozilla’s browser engineers do not work for Google. The organizational separation means that a Firefox engineer writing storage eviction tests has no structural reason to write weaker tests for Google-owned origins than for any other origin.

Apple’s Safari team at WebKit has, if anything, the opposite incentive from Google’s Chrome team. Apple’s business model is device sales and services revenue. Apple has a strong incentive to position Safari as the privacy-respecting browser, because privacy is a differentiator it can charge a premium on. The Intelligent Tracking Prevention work, the cross-site tracking prevention, the storage partitioning that Apple shipped years before Chrome — these are not accidents. They are the product of a revenue model that rewards privacy engineering.

I have not heard of Safari exempting Apple’s properties from ITP. I have not heard of Firefox exempting Google from its Enhanced Tracking Protection. These are not zero-probability events — they could happen — but the organizational structure makes them less likely.

Chrome exempting google.com from user data settings is not surprising. It is the expected behavior of a system where the privacy controls and the business model are in tension, and the business model has six years of organizational momentum behind it.

The Regulatory and Antitrust Implications

This story does not exist in isolation. Google is currently operating under consent decree conditions and antitrust scrutiny in multiple jurisdictions. The US Department of Justice concluded in 2024 that Google illegally maintained its search monopoly. The remedy proceedings are ongoing. In the EU, the DMA has designated Google as a gatekeeper and imposed interoperability and fair access requirements.

The Chrome browser is central to both the remedy discussions and the DMA compliance questions. Chrome has roughly 65% global browser market share as of mid-2026. If Chrome systematically fails to enforce its stated privacy settings against Google-owned origins, that is not just a consumer protection issue. It is a market structure issue. A browser with dominant market share that preferentially exempts its owner’s tracking infrastructure from user privacy controls is a powerful tool for maintaining search dominance.

The DOJ remedy proceedings have considered — but not yet imposed — a forced divestiture of Chrome. The argument for divestiture is precisely the one this incident illustrates: a browser controlled by an advertising monopolist cannot credibly enforce privacy controls against that monopolist’s tracking infrastructure, regardless of the browser team’s stated intentions. The argument against divestiture is operational complexity and the risk of creating a browser that lacks the resources to stay competitive against Safari. Both arguments are serious. The incident Johnson documented does not resolve the question, but it provides concrete evidence for the divestiture case that was previously somewhat abstract.

In the EU, the DMA compliance picture is more immediately actionable. The DMA requires gatekeepers to allow users to opt out of combining personal data across different services. Google has implemented consent flows for this in various products. If Chrome’s storage eviction logic systematically fails to apply the same deletion rules to Google-owned origins as to other origins, that may constitute a failure to honor the user’s opt-out preferences under DMA Article 5(2). The European Commission has DMA enforcement authority and has already launched formal proceedings against Google on several DMA provisions. This incident is the kind of concrete, reproducible technical finding that DMA enforcement actions are built on.

This is the argument that Johnson gestures at when he writes about wishing the government would break up the Google Search monopoly. He is probably right, though breaking up search and breaking up Chrome are separate and both difficult. The more tractable near-term intervention is mandatory audits: regulators requiring Google to submit Chrome’s storage eviction logic for independent technical review, specifically testing whether any Google-owned origins receive preferential treatment.

That kind of structural audit is much harder to game than a self-reported compliance statement. It would also create the incentive for Google’s engineers that the current organizational structure does not provide: knowing that an independent auditor will look at exactly the code path that handles google.com cookies on window close.

A Brief History of Browser Vendors Exempting Themselves

Chrome’s behavior is the most prominent example, but it is not the only instance of a browser vendor giving preferential treatment to its own properties. Understanding the broader context helps calibrate the severity of the Chrome case and illustrates why this is a structural problem across the industry rather than a Google-specific pathology.

Microsoft Edge has faced scrutiny for its handling of Bing-related data within Microsoft’s own privacy controls. When Microsoft integrated Bing AI chat features deeply into Edge in 2023, researchers noted that Bing queries were handled differently from third-party search queries in some telemetry configurations. The data flows were not identical to the cookie exemption Johnson documents, but the pattern — a browser’s owner’s properties receiving subtly different treatment — was consistent.

Opera, which is partly owned by Chinese investors and operates the Opera browser alongside GX and other variants, has faced persistent questions about data flows between the browser and Opera’s own VPN and ad services. Opera’s privacy controls nominally apply across all sites, but the degree to which those controls apply to Opera’s own infrastructure has not been independently audited in any systematic way.

Apple’s Safari is genuinely different, and I think it is worth saying so clearly. ITP applies to Apple’s own properties on the same basis it applies to everyone else’s. I have tested this. Apple.com is subject to the same cross-site tracking restrictions as any other origin when accessed from a different site’s context. This is not because Apple is more ethical than Google. It is because Apple’s surveillance infrastructure is not browser-based. Apple’s advertising business runs through its own apps and the App Store, not through cookies and local storage in a web browser. The incentive structure is different, and the behavior follows.

The larger point is that browser market structure matters for privacy outcomes in ways that go beyond the individual privacy settings inside any given browser. When one company controls 65% of global browser usage and that company’s primary revenue source is web advertising, the browser’s privacy controls will systematically underperform relative to what their UI implies. This is not a bug in the software sense. It is a feature of the market structure.

What Users Should Actually Do

I want to be direct about this, because the typical advice in these situations is useless. “Just use Firefox” is correct but ignores why people use Chrome. Many people use Chrome because their employer requires it, because Chrome-specific extensions solve real workflow problems, or because they are deeply integrated into Google Workspace. The answer to “Chrome is exempting Google from your privacy settings” is not always “switch browsers.”

Here is what actually works within Chrome:

First, use a separate browser profile for Google-authenticated sessions and a different profile — or a different browser — for everything else. Profile isolation in Chrome is real. Storage from one profile does not leak to another. If your Google Search, Gmail, and YouTube sessions live in Profile A and your general browsing lives in Profile B, the Google storage that persists in Profile A does not affect Profile B.

Second, use uBlock Origin in medium or hard mode. A correctly configured content blocker will block Google Analytics, Google Tag Manager, and many Google-owned tracking pixels on third-party sites regardless of cookie persistence. The exemption Johnson documents only helps Google if google.com cookies and local storage are readable by Google’s code on Google-owned origins. A content blocker does not fix that — but it does block Google’s cross-site tracking, which is where the persistent identifier becomes most dangerous.

Third, understand that incognito mode in Chrome is not affected by this bug. Incognito storage is ephemeral by design and is handled through a different code path. If you need a session with no Google persistence, incognito achieves what the main window setting does not.

Fourth, if you are on macOS, you can verify the current state yourself using Johnson’s method: run a Google search in Chrome, close the window, and inspect ~/Library/Application Support/Google/Chrome/Default for google.com entries. If you see them, the bug is affecting you. If you do not, either you are on a different Chrome version or the bug has been patched already.

Fifth, consider the threat model question that most people skip. If your goal is to prevent Google from linking your search sessions to a persistent identity, the cookie exemption Johnson documents is one vector among many. Google also has your IP address, your User-Agent string, your screen resolution and language settings, and any fingerprinting signals it collects from JavaScript running on Google Search. Deleting cookies matters at the margin, but a determined identity linkage pipeline does not depend solely on cookie continuity. The exemption is meaningful at scale — across hundreds of millions of users who believe they have configured Chrome to delete their data — but it does not mean that correctly deleting cookies would make you invisible to Google’s tracking infrastructure. It would not. It would just close one specific channel.

The Open Source Illusion

One common defense of Chrome in situations like this is that Chrome is based on Chromium, an open-source project. The implication is that if Google were doing something intentionally bad, someone in the open-source community would have spotted it. This defense dissolves on examination.

Chromium is open source in the sense that its code is publicly available. It is not open source in the sense of being community-governed. Google controls the Chromium project. Google employees make the architectural decisions, review the patches, set the roadmap. Contributions from outside Google are welcome but Google has final authority over what ships. The Chromium governance structure is not comparable to, say, the Linux kernel, where Linus Torvalds operates with genuine independence from any single commercial backer.

More specifically, the open-source nature of Chromium does not guarantee that privacy-adversarial edge cases will be caught. The storage eviction logic is tens of thousands of lines of C++ spread across multiple subsystems. Finding the specific condition that causes google.com storage to persist when it should not requires knowing to look for it, having a reproducible test environment, and being motivated to dig through the codebase to find the mechanism. Jeff Johnson found this because he was specifically testing privacy controls for a blog post. The open-source community does not have an organized effort to test Chrome’s privacy controls against Google-owned origins after every release.

The people who do have that motivation — privacy researchers, rival browser teams, regulators — also face an asymmetry in resources. Google has thousands of engineers who know the codebase. External auditors start from zero each time. The “open source means someone would notice” argument requires a level of organized, continuous external scrutiny that does not exist for Chromium’s privacy enforcement logic.

This is why the regulatory audit approach matters more than it might seem. A regulatory requirement to test specific code paths would create a persistent, funded external presence doing exactly the kind of testing that the open-source community does not currently sustain.

What Google Should Do and Probably Will Not Do Structurally

The fix is not complicated. The storage eviction logic that runs on window close should apply uniformly to all origins, including Google-owned origins. The unit tests for this code path should include explicit test cases for google.com, youtube.com, gmail.com, and other major Google properties. The regression suite should be run against every Chrome release, not just releases where the notes mention privacy changes.

Google will probably fix the specific bug Johnson reported, as they did in 2020. The fix will ship in a Chrome update within weeks of this becoming widely covered. The harder commitment — ensuring this class of bug does not recur — requires acknowledging that the organizational structure of Chrome’s development creates systematic gaps in privacy QA for Google-owned origins, and then doing something about that structure.

What “something” looks like is open to interpretation. One option: a dedicated privacy engineering team whose performance metrics are explicitly based on finding exemptions that benefit Google properties. Another option: an external audit arrangement where a third party reviews Chrome’s storage policy enforcement on a rolling basis. A third option — the one that addresses the root cause directly and that Google will resist most strenuously — is separating Chrome’s development governance from Google’s ad business entirely.

None of these are technically difficult. All of them are organizationally difficult for the same reason the bug keeps reappearing: they require Google to act against the interests of its own surveillance infrastructure in order to deliver on the privacy promises its browser makes to users.

The Broader Pattern: Self-Regulation Does Not Work When the Regulator Is the Regulated

I want to end on the structural point rather than the specific bug, because the specific bug will be fixed and the structural point will not.

We have now seen the same failure mode twice in six years: Google builds a browser, the browser makes privacy promises, the promises systematically fail to apply to Google’s own properties, an external researcher documents the failure, Google fixes it, and the cycle repeats. The lesson from two iterations is not that Google is uniquely malicious. The lesson is that self-regulation does not work when the regulator and the regulated share a balance sheet.

Chrome is not just a product. It is infrastructure. It handles the browsing sessions of more than three billion people. The privacy settings in Chrome are not optional features — they are load-bearing parts of the web’s trust architecture. When those settings have exceptions that users do not know about, and those exceptions benefit the company that built the browser, the trust architecture has a structural crack in it.

Six years is long enough to conclude that Google will not fix the crack structurally. The fixes they ship address symptoms — the specific code path an external researcher documented — without addressing the cause. The cause is that Google Chrome is an advertising company’s browser, and the advertising company’s interests are not aligned with the privacy interests of the browser’s users.

Johnson ends his post invoking Hanlon’s razor: never attribute to malice what can be explained by incompetence. He is probably right that this is not a deliberate decision. I also think the distinction between deliberate and structural matters less than people assume. A structural outcome that repeats itself, in the same direction, over six years, is not less harmful because no one chose it explicitly. The users who configured Chrome to delete their data and did not get that outcome are not less surveilled because the engineers who wrote the eviction code were acting in good faith.

Good faith is not a privacy guarantee. Independent architecture is.

Falsifiable Predictions

Google will ship a patch for the specific behavior Johnson documented — google.com storage persisting after window close in Chrome 152 — within 30 days of this becoming widely covered. That patch will not include a public commitment to independent auditing of Chrome’s storage policy enforcement. The Chrome team’s next major privacy announcement will be about a different initiative — Privacy Sandbox, Topics API, or a new partitioning feature — rather than about the governance structure that produced this regression. By 2028, a third instance of the same class of bug — a Google-owned origin receiving preferential treatment under a Chrome privacy setting — will be documented by an external researcher.

The specific mechanism will be different. The pattern will be the same.