A two-Mac report about 1,216 KB of leftover Google storage reached 524 points and 96 comments on Hacker News within hours. The crowd is much larger than the test pool, which is exactly why the details matter. On Chrome 152 for macOS, developer Jeff Johnson found that www.google.com data remained after he closed the browser's only window, even though Chrome was set to delete saved site data when all windows close. Google's help page describes that setting in similarly unqualified terms.
The finding is specific enough to check and narrow enough to resist a sweeping verdict. Johnson repeated the result on two Macs, with Chrome sign-in disabled and DuckDuckGo selected as the default search engine. His screenshots show the storage returning after manual deletion and another Google search. They do not reveal why it happened, how many installations are affected, or whether any retained value was used for tracking.
The test in plain view
Johnson started at chrome://settings/content/siteData, where the default behavior was set to "Delete data sites have saved to your device when you close all windows." He was not signed in to Chrome and had disabled Chrome sign-in. At chrome://settings/content/all, the profile initially showed zero bytes of saved site data. He then ran one Google search and closed the only open Chrome window, according to his September 5 report.
When he returned to Chrome's all-sites page, the browser listed 1,216 KB for www.google.com. Quitting and reopening Chrome did not remove the entry. Johnson deleted it by hand, repeated the sequence, and got the same result. Inspection of Chrome's profile directory led him to identify cookies, Local Storage and Session Storage among the saved material, though the post does not publish their values.
The version number fixes the result to ordinary release software rather than an experimental build. Google's September 3 desktop release notice lists 152.0.7977.82/.83 as the Stable channel update for Windows and Mac. Johnson tested 152.0.7977.83, placing his result on the current Mac stable build named by Google.
Chrome's documentation leaves little ambiguity about the user-facing promise. The browser lets people allow on-device data, delete it when every window closes, or prevent sites from saving it. Google says the middle choice should make sites less likely to remember a visitor between visits. It does not document a google.com exception on the on-device site data help page.
What 1,216 KB proves, and what it does not
The screenshots establish that Chrome's settings interface reported stored data for www.google.com after the configured deletion event. Johnson also saw files associated with several browser storage mechanisms in the Mac profile folder. That is evidence of retention on those two machines. The published test includes no packet capture, decoded cookie values, or account activity linking the residue to advertising or user identification.
Size alone says little about sensitivity. A cookie may contain an identifier or a mundane preference; Local Storage can hold application state; the settings total does not explain what occupies each byte. The report provides the aggregate 1,216 KB figure and names the storage classes, so claims about the data's contents would go beyond the evidence Johnson released.
The test also lacks a visible non-Google control run in the current post. Johnson writes that www.google.com appears to be the only exempt site, yet the article does not show another data-writing site going through the same clean-profile sequence beside Google. One response in the Hacker News discussion asked for precisely that comparison. The comment is a useful request for evidence, not independent reproduction.
There are more open variables. The post covers macOS only and does not name either machine's macOS version. It does not test Windows, Linux, Android, a fresh temporary Chrome profile, another Chrome build, or another Chromium browser. Johnson says he is unsure when the behavior began, and the report links no current Chromium issue.
The result stands within those boundaries. The current report does not support calling the residue a deliberate Google tracking system. Google's release notice also establishes that build .83 is a Mac Stable channel release, so the tested version was neither old nor pre-release.
The 2020 episode complicates the diagnosis
Johnson found a related failure six years ago. In Chrome 86.0.4240.75 on macOS, he reported that YouTube retained database storage, Local Storage and service workers after a quit and relaunch; Google Search retained Local Storage. An Apple site used as a comparison lost its data as requested. The 2020 test therefore supplied the control that is absent from the new post.
That earlier story also produced independent confirmation and a less dramatic explanation for part of the behavior. The Verge reproduced similar YouTube retention, then reported Google's acknowledgement of a Chrome bug. Google said the problem affected cookie clearing on some of its first-party sites and promised a fix. The Verge found YouTube storage clearing after updating to Chrome 86.0.4240.111.
Google treated the google.com portion differently in 2020. It told The Verge that Chrome's new-tab page could recreate Google data because the page contained a search box and sign-in link. The publication changed Chrome to open a website instead of an empty tab and no longer saw the Google Local Storage reappear. That relaunch explanation is a warning against assuming that every post-restart entry survived deletion; some data may have been created again.
The 2026 sequence reduces that possibility without closing it. Johnson switched the default search engine to DuckDuckGo, disabled Chrome sign-in, and first saw the google.com entry after closing the last window, before describing a quit and relaunch. Yet the new post does not show a custom startup page or a trace of when each stored item was written. The exact sequence in his report makes the old explanation incomplete, while leaving room for a different Chrome component to recreate data.
The two episodes may share a symptom without sharing code or cause. In 2020, Google acknowledged a first-party clearing bug and explained separate google.com behavior as new-tab recreation. In 2026, the public record so far is Johnson's two-machine test plus community discussion. The older account supports taking the symptom seriously and checking the reproduction path before naming the mechanism.
A better reproduction would settle more
A useful follow-up can remain simple. Start with a fresh Chrome profile on build 152.0.7977.83, set the documented delete-on-close behavior, and visit two pages that demonstrably write site data: Google Search and a neutral control. Record chrome://settings/content/all before the visits, after closing every window, after quitting the process, and after reopening to a non-Google startup page. That matrix directly combines Johnson's current steps with the startup-page lesson from the 2020 investigation.
Repeating the same sequence on Windows and Linux would separate a macOS lifecycle issue from a cross-platform Chrome behavior. Testing .82 and .83 would also clarify whether the Mac-specific build suffix matters. Google's release post says the Stable rollout covers both versions on Windows and Mac, while Linux received .82, giving testers a defined version map rather than a vague request to try "the latest Chrome."
A Chromium bug report would add the missing engineering trail: reproducible steps, platform labels, component ownership and, eventually, a change list or explanation. Google's Stable release notice directs users who find a new issue to file a bug, and Johnson explicitly asks for unit tests in his post. A regression test would matter here because the same user-visible symptom has now surfaced six years after the acknowledged Chrome 86 problem.
Why the setting's wording matters
Delete-on-close is a small privacy control with a plain contract. A person chooses it because retained state should end with the browser session. Google describes the expected tradeoff as sites being less likely to remember the user on the next visit. If one domain remains in the all-sites panel after that event, the observable result conflicts with the documented behavior, regardless of whether the stored bytes later prove harmless.
The optics are harsher because the browser maker owns the domain that Johnson says survived. That coincidence can fuel claims of self-preferencing, but the current evidence supplies no intent. Johnson himself favors a quality-control explanation over conspiracy in the new report. The 2020 history shows why restraint is useful: one Google-owned site had an acknowledged bug, while another could recreate data through Chrome's own new-tab interface.
The next useful evidence will be a clean-profile control test, a Chromium issue, or a response from Google that explains when the 1,216 KB was written. Watch whether the result reproduces on Chrome 152 Stable outside macOS and whether a later desktop build changes it. Until one of those arrives, the precise claim remains the strongest one: two Macs running 152.0.7977.83 retained a www.google.com entry after Chrome was told to delete on-device site data when its last window closed.