一台Mac,把默认搜索引擎从Google换成DuckDuckGo,开启「关闭窗口时自动删除所有网站数据」,搜一次Google,关掉窗口,再重新打开——网站数据设置里本该清零的存储空间里,躺着1,216 KB的google.com数据。删掉,重复一遍,数据又回来了。
这是独立开发者Jeff Johnson在Chrome 152.0.7977.83版本上做的复现实验,他在两台不同的Mac上都得到了同样的结果。而这个场景,他六年前就见过一次。
发生了什么
2020年,Johnson发现Chrome的「关闭清空数据」功能会豁免Google自家网站,那次报道被The Verge、Gizmodo、Hacker News大量转载,压力之下Google修复了问题。
六年后,同一个人、同一套测试方法,在Chrome 152上又复现了几乎一样的现象:www.google.com是目前唯一被排除在自动清理之外的站点,留存的数据包括Cookies、Local Storage和Session Storage。他特意排除了账号登录和默认搜索引擎的干扰,确认问题不是设置误配置,而是Chrome本身的行为。
Johnson自己的态度很克制,他援引「Hanlon剃刀」:能用愚蠢解释的,不要用阴谋论。但他补了一句——Google的体量和工程资源,不该是QA疏漏的挡箭牌。
官方记录里找不到这件事
这才是比bug本身更值得琢磨的部分。
翻遍Chromium的官方issue tracker,没有和「Chrome 152上google.com数据在关窗后残留」完全匹配的公开报告。最接近的一条issue处理的是Chrome 127上的企业策略登录问题,已经标记为Fixed,症状和这次对不上。Chrome 152的官方发布说明里,同样没有任何一行字提到网站数据清理机制的改动。
也就是说,这个问题目前处在「民间发现、官方沉默」的灰色地带:没人证实Google已经知道,更谈不上修复计划。
而Chromium底层负责这项功能的session-data-deleter机制,设计初衷就是关窗时无差别清除被标记为session-only的站点数据,连带的浏览器测试用例也明确要求这么做。理论上不该有例外,现实里却总有一个域名是例外。
这不是第一次有人发现,只是第一次有人被听见
比2020年那次曝光更早,老论坛Super User上就有用户报告过几乎一模一样的症状:几乎所有localStorage都被清空了,唯独https_www.google.com_0.localstorage活了下来。那条帖子从没进入Chromium的官方问题追踪系统,自然也没人跟进。
三条线索拼在一起,故事就变了味:这不是一次孤立的回归bug,而更像一条从未被彻底堵上的代码路径——2020年修的可能只是那次触发它的具体表现,底层的例外逻辑本身没动。
Johnson在文章末尾顺手提了一句更烦人的细节:未登录Google账号时,搜索结果链接如今都变成了不透明的google.com/goto?url=跳转,而不是直接显示目标网址。这和数据豁免不是同一个bug,但指向同一个方向——用户对自己数据和跳转路径的可见度,正在被系统性地收紧。
谁在意这件事,该看什么
受影响的是所有开着隐私清理设置、又会打开Google搜索或Gmail的普通用户——他们以为关窗就清空了痕迹,实际上Google那一份留了下来。对已经在审视Google搜索垄断问题的监管机构来说,这也是浏览器层面「自己人特殊对待」的又一个佐证,尽管目前还没有证据表明这是故意设计。
- 风险.这个bug尚未进入Chromium官方issue tracker,意味着修复没有时间表,也没人对外确认责任归属。
Google既写Chrome的清理规则,又是被清理对象里访问量最大的那个,这个结构性矛盾六年前没解决,六年后又冒出来,并不让人意外。真正该盯着的不是这次会不会道歉修复,而是这条代码路径下次会不会换个马甲,再让下一个较真的人重新发现一遍。
六年修一次治标,治不了标的是Google自己既当裁判又当选手的位置。