
Chrome 静默安装 4GB AI 模型:一场没有征得你同意的隐私与气候危机
隐私专家 Alexander Hanff 通过 macOS 内核日志发现,Chrome 在用户毫无察觉的情况下静默下载了 4GB 的 Gemini Nano 模型文件,删除后还会自动重新下载。文章深入分析了这一行为涉及的法律违规和十亿级设备规模下的气候成本。
原文来源:That Privacy Guy — 隐私专家通过 macOS 内核日志证实 Chrome 在用户不知情的情况下静默安装 4GB AI 模型,并分析了这一行为涉及的法律违规和十亿级设备规模下的气候成本。
两周前,隐私专家 Alexander Hanff 曝光了 Anthropic 的 Claude Desktop 在未经用户同意的情况下,悄悄在七款基于 Chromium 的浏览器中注册 Native Messaging 桥接程序。安装 Claude Desktop 后,它会自动向用户电脑上的其他浏览器写入配置,跨越厂商信任边界,没有弹窗询问,没有退出选项,用户手动删除后每次启动 Claude Desktop 都会重新安装。
这周,Hanff 发现 Google 也在用同样的套路。Chrome 正在用户的电脑上写入一个 4GB 的本地 AI 模型文件,全程没有征得同意。这个文件名叫 weights.bin,存放在 OptGuideOnDeviceModel 目录下,是 Gemini Nano 的模型权重。Chrome 没有询问,没有弹窗提示,用户删除后它还会重新下载。
从法律角度看,这和 Anthropic 的情况如出一辙。但环境层面的分析是全新的。以 Chrome 的用户规模,一次模型推送在全球范围产生的大气 CO2 当量排放,保守估计在六千到六万吨之间。这是一家公司单方面决定让二十亿人的默认浏览器大规模分发一个他们并未请求的 4GB 二进制文件的环境代价。
你的磁盘上多了什么,以及怎么来的
在任何安装了 Chrome 的电脑上,用户目录里会有一个名为 OptGuideOnDeviceModel 的文件夹,里面躺着 weights.bin,大约 4GB。这是 Gemini Nano 的权重文件,Chrome 用它驱动"帮我写"、本地诈骗检测等 AI 辅助功能。
这个文件出现得悄无声息。Chrome 设置里没有"下载 4GB AI 模型"的复选框。只要 Chrome 的 AI 功能处于开启状态,而这项功能在最近的 Chrome 版本中是默认启用的,那么只要硬件达标,Chrome 就会把用户的设备当作分发目标,直接写入模型文件。
删除和重新下载的循环已经在 Windows 上被多个独立报告证实过。用户删除,Chrome 重新下载,用户再删,Chrome 再下。唯一能让删除保持有效的方法是:通过 chrome://flags 禁用 Chrome 的 AI 功能,或者使用普通用户一般没有的企业策略工具,又或者干脆卸载 Chrome。macOS 上文件的权限是 600,理论上用户可以直接删除,但 Chrome 把安装状态记录在 Local State 里,一旦 variations 服务器判定该用户有资格接收模型,下载就会再次触发。架构是一样的,只是文件权限不同。
macOS 内核日志给出的铁证
现有报道大多来自 Windows 用户发现自己的磁盘被占满。Google 可能会把这些报告定性为"非典型配置下的个别案例"。所以 Hanff 在另一个平台上寻找了一个干净的见证。
这个见证就是 macOS 本身。内核维护着一个叫 .fseventsd 的文件系统事件日志,记录每一次文件的创建、修改和删除,独立于任何应用的日志。Chrome 无法修改它,Google 也无法远程触碰它,而且即使被记录的文件被删除,记录这些事件的页面文件依然会保留。
Hanff 在 2026 年 4 月 23 日创建了一个 Chrome 用户数据目录,用于运行自动化隐私审计。审计驱动完全基于 Chrome DevTools Protocol,只加载页面、停留五分钟、捕获事件,然后关闭 Chrome。整个过程中没有任何人工键盘或鼠标输入,Chrome 的每一个 AI 模式界面都从未被触碰过。实际上,Chrome 的每一个 UI 界面都没有被碰过,审计驱动只通过 CDP 与文档交互,地址栏从未被触及。
到了 4 月 29 日,这个审计目录里多了 4GB 的 OptGuideOnDeviceModel 权重文件。Hanff 是在一次例行的 du -sh 清理扫描中发现的。
他回头去查 .fseventsd,问 macOS 这 4GB 到底是什么时候落下来的。macOS 在三个连续的页面文件中给出了精确到字节和秒级的答案:
- 4 月 24 日 16:38:54 CEST — Chrome 在审计目录中创建了
OptGuideOnDeviceModel文件夹。 - 4 月 24 日 16:47:22 CEST — 三个并发的解压子进程在
/private/var/folders/.../下创建了临时目录。其中一个写入了weights.bin、manifest.json、_metadata/verified_contents.json和on_device_model_execution_config.pb。第二个写入了证书吊销列表更新。第三个写入了浏览器预加载数据更新。Chrome 把安全更新、预加载刷新和一个 4GB 的 AI 模型打包在同一个空闲窗口里推送,仿佛它们是同等重要的东西。 - 4 月 24 日 16:53:22 CEST — 解压后的
weights.bin被移动到最终位置OptGuideOnDeviceModel/2025.8.8.1141/weights.bin,同时adapter_cache.bin、encoder_cache.bin、执行配置等文件一并就位。另外四个较小的模型目标在 Chrome 的 optimization-guide 枚举中注册了新条目,它们是配合 LLM 使用的文本安全和提示路由模型。这些目标在这一刻之前都不存在于该目录中。
从目录创建到最终移动,总共 14 分 28 秒。这段时间内,该目录没有任何人工操作。审计驱动要么在第三方首页上停留等待五分钟计时器,要么在站点之间切换,解压器在后台运行,前台标签页完全无关。
fseventsd 记录中最致命的细节是临时目录的命名:com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.5xzqPo。这个前缀 com.google.Chrome.chrome_chrome_* 是 Google Chrome 自身的 bundle ID 和子进程命名规范。不是 com.google.GoogleUpdater.*,也不是 com.google.GoogleSoftwareUpdate.*。写入者是 Chrome,用户安装并信任的浏览器进程,在未经用户发起的情况下主动触碰文件系统,放下一个 4GB 的机器学习二进制文件,而前台标签页正在做完全不相干的事情。
更多独立证据
同一台机器上还有三处独立证据互相印证:
Chrome 的 Local State JSON 里有一个 optimization_guide.on_device 块,记录着 model_validation_result: { attempt_count: 1, result: 2, component_version: "2025.8.8.1141" }。Chrome 运行过这个模型,component_version 与 fseventsd 记录的路径版本完全一致。两个独立见证指向同一个产物。同一块还报告了 performance_class: 6, vram_mb: "36864" —— Chrome 读取了 GPU 信息和统一内存总量,以此判定设备是否有资格接收模型推送,而这时用户连 AI 功能的界面都还没看到。
Chrome 的 ChromeFeatureState 里列出了 OnDeviceModelBackgroundDownload<OnDeviceModelBackgroundDownload 和 ShowOnDeviceAiSettings<OnDeviceModelBackgroundDownload,都在 enable-features 块中。第一个 flag 触发静默下载,第二个 flag 控制 chrome://settings 中是否显示本地 AI 设置项。两个 flag 被同一个 rollout flag 控制,也就是说,按照 Chrome 自己的架构,下载在用户有机会拒绝之前就已经开始了。那个能让你发现这个功能存在并选择关闭它的设置页面,和下载安装是同步启用的。这是设计,不是疏忽。
法律分析:多项违规
Hanff 从专业角度给出了明确的法律判断:
ePrivacy 指令第 5(3) 条:在终端设备上存储或访问信息,必须征得用户知情同意。Chrome 没有弹窗,没有复选框,没有"同意下载 4GB AI 模型"的选项。用户甚至不知道这件事发生了。
GDPR 第 5(1) 条:数据处理必须合法、公平、透明。静默下载一个 4GB 的机器学习模型,没有任何用户界面提示,很难说是透明的。
GDPR 第 25 条:数据保护必须内建于设计之中。Chrome 的架构是下载先于用户知情,设计本身就不给用户提供拒绝的机会。
CSRD 企业可持续发展报告指令:以 Chrome 的用户规模,一次模型推送产生的碳排放在六千到六万吨 CO2 当量之间。对于任何受 CSRD 约束的企业来说,这种量级的环境影响属于必须报告的事件。
十亿级设备的气候账单
这是这篇文章最值得关注的新视角。AI 模型的训练和推理碳足迹已经被讨论过很多次,但模型分发的环境成本很少被提及。
4GB × 十亿台设备 = 4 艾字节(exabytes)的数据传输。即使只有一部分设备实际接收了推送,这个量级也足以产生可观的气候影响。数据中心的冷却、网络基础设施的电力、终端设备存储和读取的能耗,加在一起就是六千到六万吨 CO2 当量的估算来源。
而且这不是一次性的。模型会更新,Chrome 会重新下载新版本。用户删除后它还会回来。这意味着这个气候账单不是单次事件,而是一个持续产生的成本,由一家公司的单方面决定驱动,由整个地球的大气层买单。
为什么这很重要
这件事不只是"Google 又干了什么"的例行批评。它揭示了一个正在形成的模式:
跨厂商信任边界的越界行为正在成为常态。Anthropic 向其他浏览器写配置,Google 向用户磁盘写 AI 模型。它们都利用了用户对"自己安装的软件"的信任,把这种信任扩展到了用户没有明确授权的行为上。
"默认启用"正在成为规避同意的标准手段。不是询问用户"你要不要这个",而是直接做,然后让用户自己去设置深处找到关闭开关 —— 如果存在的话。
环境成本被完全排除在技术决策之外。没有人问"推送这个模型给十亿台设备会产生多少碳排放",因为这不是技术团队的 KPI。但它是整个社会的成本。
对于普通用户来说,这件事的直接影响可能是磁盘空间被占用了 4GB。但更深层的意义在于:你的设备上正在运行什么、存储什么,不再完全由你决定。你安装的软件正在利用你的信任,在你的不知情下做出越来越大的决策。
Hanff 在文章结尾提出了一个根本性的问题:如果一家公司可以在没有征得同意的情况下,向二十亿台设备推送 4GB 的 AI 模型,那么它还可以推送什么?这个问题的答案,可能比 Gemini Nano 本身更值得警惕。
© 2026 四月 · CC BY-NC-SA 4.0
原文链接:https://aprilzz.com/ai/chrome-silent-gemini-nano
相关文章
12-Factor Agents:构建生产级 LLM 软件的 12 条原则
12-Factor Agents 是一套构建生产级 LLM 驱动软件的方法论,借鉴了经典的 12-Factor App 理念,为 AI Agent 系统提供可维护、可扩展、可信赖的设计原则。
AI Agent 发表了一篇攻击我的文章
一名开源维护者因拒绝AI Agent提交的代码,遭到该智能体自主撰写的网络攻击文章抹黑。这是AI失控行为在真实世界中的首次案例研究。
Opus 4.5 不是正常的 AI Agent 体验
Burke Holland 用 Claude Opus 4.5 在几小时内独立完成了四个完整项目——从 Windows 桌面工具到视频编辑器再到带后端的全栈移动应用。这不是夸张的营销话术,而是一位资深开发者对 AI 编程能力边界的真实重估。