返回
原文
Hacker News 热门（buzzing.cc 中文翻译）
精选
78AI 编辑部评分，满分 100

Google Chrome 被曝未经用户同意悄然安装 4 GB AI 模型

2026-05-05 20:25· 92天前· john-doe
AI 导读

据隐私倡导网站报道，Google Chrome 浏览器在未经任何提示或用户同意的情况下，于后台自动下载并安装了一个名为“Nano”、体积达 4 GB 的人工智能模型。该行为旨在增强本地AI功能，但完全隐蔽的安装过程占用了用户设备存储空间，且未提供任何选项或通知，引发了对其数据隐私风险及软件更新透明度的广泛担忧。此事件在Hacker News上获得高度关注，突显了公众对科技公司单方面安装行为的普遍不安。

推荐理由

浏览器里偷偷塞进4GB的AI模型，这件事揭开了一个很多人忽视的趋势，你的设备正在变成AI宿主，而且根本不需要征得同意。

正文 · AI 翻译
Google Chrome silently installs a 4 GB AI model on your device without consent. At a billion-device scale the climate costs are insane.

Google Chrome 在用户设备上静默安装了一个 4GB 的 AI 模型

两周前，我撰文指出 Anthropic 在每台安装了 Claude Desktop 的机器上，静默地在七款基于 Chromium 的浏览器中注册了一个原生消息桥接 [1]。其模式是：用户在启动产品 A 时进行安装，未经询问便将配置写入用户已安装的产品 B、C、D、E、F、G、H 中。这种操作跨越了供应商信任边界。没有同意对话框，没有退出选项的界面。如果用户手动删除，每次启动 Claude Desktop 时，它都会重新安装。

本周，我发现了同样的模式，这次由 Google 执行。Google Chrome 正在侵入用户的机器，未经询问便将一个 4GB 的端侧 AI 模型文件写入磁盘。该文件名为 weights.bin，位于 OptGuideOnDeviceModel 目录下。它是 Google 端侧大语言模型 Gemini Nano 的权重文件。Chrome 没有询问用户，也没有向用户展示该文件。如果用户删除它，Chrome 会重新下载。

法律分析与我对 Anthropic 案例的分析相同。环境分析则是新的。以 Chrome 的规模，推送一个模型所产生的气候账单——由整个地球以大气二氧化碳的形式支付——相当于六千到六万吨二氧化碳当量排放，具体取决于接收该推送的设备数量。这就是一家公司单方面决定让二十亿人的默认浏览器大规模分发一个他们并未请求的 4GB 二进制文件所付出的环境代价。

依我之专业判断，这直接违反了第 2002/58/EC 号指令（《电子隐私指令》）第 5(3) 条 [2]，违反了《通用数据保护条例》（GDPR）第 5(1) 条关于合法性、公正性和透明度的原则 [3]，违反了 GDPR 第 25 条关于设计保护数据的要求 [3]，并且其造成的环境损害规模之大，对于任何在范围内的企业而言，都构成《企业可持续发展报告指令》（CSRD）下的应报告事件 [4]。

磁盘上有什么，以及它是如何被写入的

在任意安装了 Chrome 浏览器的机器上，用户配置文件中都存在一个名为 OptGuideOnDeviceModel 的目录。该目录内有一个名为 weights.bin 的文件，大小约为 4 GB。这是 Gemini Nano 的权重文件。Chrome 利用它来驱动谷歌以“帮我写”等名称推广的功能、设备端诈骗检测以及其他 AI 辅助的浏览器功能。

该文件出现时并未弹出任何同意提示。Chrome 设置中也没有一个名为“下载 4 GB AI 模型”的复选框。当 Chrome 的 AI 功能处于激活状态时，便会触发下载，而在近期的 Chrome 版本中，这些功能默认是开启的。在任何满足硬件要求的机器上，Chrome 都会将用户的硬件视为投放目标，并写入该模型。

这种删除后又重新下载的循环，已在多个关于 Windows 系统的独立报告中得到记录 [5][6][7][8]——用户删除，Chrome 重新下载；用户再次删除，Chrome 再次下载。要让删除操作真正生效，唯一的方法是禁用 Chrome 的 AI 功能（通过 chrome://flags 或普通家庭用户通常没有的企业策略管理工具），或者彻底卸载 Chrome [5]。在 macOS 上，该文件以用户拥有的 600 权限模式存放（因此原则上可以删除），但 Chrome 在写入字节后，会将安装状态保存在 Local State 中，一旦变体服务器下次告知 Chrome 该配置文件符合条件，下载便会再次触发——架构是相同的，只是文件权限不同。

我如何在全新创建的 Apple Silicon 配置文件上验证这一点

关于此行为的现有报告大多来自 Windows 用户，他们注意到自己的磁盘空间被占满——这很有用，但谷歌可能会（而且很可能会）试图将这些报告定性为来自非代表性配置的个例。因此，我决定在另一个平台上寻找一个干净的证据。

我找到的目击者正是 macOS 本身。内核维护着一个名为 .fseventsd 的文件系统事件日志——它在操作系统层面记录每一次文件的创建、修改和删除，独立于任何应用程序的日志记录。Chrome 无法编辑它，Google 无法远程访问它，而记录这些事件的页面文件在它们所引用的文件被删除后依然存在。

我在 2026 年 4 月 23 日创建了一个 Chrome 用户数据目录，用于运行自动化审计（这是 WebSentinel 100 站点隐私扫描的一部分）。审计驱动程序完全基于 Chrome DevTools 协议——它会加载一个页面，停留五分钟且无任何输入，捕获事件，然后在站点之间关闭 Chrome——并且该配置文件在其整个生命周期中从未接收过来自人类的任何键盘或鼠标输入。Chrome 中所有“AI 模式”界面都未被触及——事实上，Chrome 中的所有 UI 界面都未被触及，审计驱动程序仅通过 CDP 与文档交互，且从未访问过地址栏。到 4 月 29 日，该配置文件中包含了 4 GB 的 OptGuideOnDeviceModel 权重——我之所以知道这一点，是因为在清理过程中对审计配置文件目录执行了一次常规的 du -sh 命令时发现了它。

我回到 .fseventsd 去查询那 4 GB 数据具体是在何时写入的。macOS 给出了答案，精确到字节，记录在三个连续的页面文件中：

  • 2026 年 4 月 24 日，欧洲中部夏令时间 16:38:54（世界协调时 14:38:54）——Chrome 在审计配置文件中创建了 OptGuideOnDeviceModel 目录（页面文件 0000000003f7f339）。
  • 2026 年 4 月 24 日，欧洲中部夏令时间 16:47:22（世界协调时 14:47:22）——三个并发的解压子进程在 /private/var/folders/.../com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.*/ 下生成了临时目录。其中一个（5xzqPo）写入了 weights.bin、manifest.json、_metadata/verified_contents.json 和 on_device_model_execution_config.pb。第二个写入了一次证书吊销列表更新。第三个写入了一次浏览器预加载数据更新。Chrome 将一次安全更新、一次预加载刷新和一个 4 GB 的 AI 模型打包在同一个空闲窗口中处理，仿佛它们是同等重要的事情（页面文件 00000000040c8855）。
  • 2026年4月24日，欧洲中部夏令时16:53:22（世界协调时14:53:22）——解压后的 weights.bin 被移动到其最终位置 OptGuideOnDeviceModel/2025.8.8.1141/weights.bin，一同移动的还有 adapter_cache.bin、encoder_cache.bin、_metadata/verified_contents.json 以及执行配置。与此同时，另外四个模型目标（在 Chrome 的 optimization-guide 枚举中编号为 40、49、51 和 59）在 optimization_guide_model_store 中注册了新的条目——这些是与该大语言模型配对的小型文本安全与提示词路由模型。在此刻之前，这些目标均不存在于该用户配置文件中（页面文件 00000000040d0f9c）。

从目录创建到最终移动，总安装时间为14分28秒。在此期间，针对该用户配置文件的人工操作次数为零。审计驱动程序要么停留在某个第三方主页上，要么在站点之间切换——解压程序在后台运行，而一个标签页正在等待一个五分钟计时器到期。

该 fseventsd 记录中的命名，如果说有什么的话，那正是最致命的细节。临时目录名为 com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.5xzqPo——其前缀 com.google.Chrome.chrome_chrome_* 正是 Google Chrome 自身使用的包标识符和子进程命名约定。它不是 com.google.GoogleUpdater.*，也不是 com.google.GoogleSoftwareUpdate.*。写入者是 Chrome——用户已安装并信任用于加载网页的浏览器进程——它主动访问用户的文件系统，在前台标签页执行完全无关的操作时，放下了一个4GB的机器学习二进制文件。

另外三项佐证证据位于同一台机器的其他位置：

  1. Chrome 审计配置文件的本地状态 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 在向用户展示任何 AI 功能之前，就已经对我的硬件进行了特征分析（读取 GPU、读取统一内存总量），以判断我是否符合推送该模型的条件。

  2. Chrome 审计配置文件的 ChromeFeatureState 在 enable-features 块中列出了 `OnDeviceModelBackgroundDownload<OnDeviceModelBackgroundDownload` 和 `ShowOnDeviceAiSettings<OnDeviceModelBackgroundDownload`。第一个标志是触发静默下载的开关。第二个标志是在 `chrome://settings` 中显示设备端 AI 设置页面的开关。两者都由同一个发布标志控制——这意味着，根据 Chrome 自身的架构设计，在用户看到任何可以拒绝安装的设置界面之前，安装就已经开始了。那个本应让你发现该功能存在的设置页面，与安装过程是同步启用的——这是设计使然，而非疏忽。

  3. GoogleUpdater 日志记录了设备端模型控制组件（appid {44fc7fe2-65ce-487c-93f4-edee46eeaaab}）从 `http://edgedl.me.gvt1.com/edgedl/diffgen-puffin/%7B44fc7fe2-65ce-487c-93f4-edee46eeaaab%7D/...` 下载的过程——这是一个 7 MB 的压缩控制文件，于 2026 年 4 月 20 日到达，比所讨论的审计配置文件的创建时间早了三天。这就是上游控制平面：它与配置文件无关，由一个每小时触发一次的 LaunchAgent 自动启动，并且 URL 使用的是纯 HTTP（完整性由包内的 CRX-3 签名验证，而非传输层安全协议）。该控制组件向 Chrome 提供了指向实际权重的清单，随后 Chrome 进程内的 OnDeviceModelComponentInstaller（一个独立于 GoogleUpdater 的代码路径）直接从 Google 的 CDN 获取了数 GB 的权重文件。

于是我们得到了一条四重证据链——macOS 内核文件系统事件、Chrome 自身的每个配置文件状态、Chrome 运行时特性标志，以及 Google 组件更新日志——这四者都指向同一行为：一个 4 GB 的 AI 模型在未经同意、未获通知的情况下，于某个周二下午，在 14 分 28 秒内，被下载到了一个从未接收过任何人工输入的配置文件所在的磁盘上。

关于 OptGuideOnDeviceModel 目录和 weights.bin 文件的报告已在社区论坛流传超过一年——2026 年的新变化在于其规模和可验证性。Chrome 的全球市场份额仍保持在 64% 以上[9][10]，根据你采信哪个 2026 年的估算，Chrome 的全球用户量在 34.5 亿到 38.3 亿之间[9][11]，而 Google 正以越来越激进的方式将 Gemini 功能集成到 Chrome 中。这种行为已不再只影响少数平台上的少数高级用户——它正在影响数亿台设备，覆盖 Chrome 所支持的所有桌面操作系统。

与 Anthropic 的逐点对比

同一套暗黑模式剧本。我在此重复我在 Claude Desktop 文章[1]中的分类，因为这些模式完全相同，而这正是关键所在。

1. 跨信任边界的强制捆绑。Anthropic 安装了 Claude Desktop，然后写入了 Brave、Edge、Arc、Vivaldi、Opera 和 Chromium。Google 安装了 Chrome，然后在用户配置文件目录下未经授权写入了一个 4 GB 的 AI 模型。这个二进制文件并非 Chrome 本身。它是一个独立训练的机器学习模型，具有独立的用途、独立的数据保护配置以及独立的同意记录。

2. 不可见的默认设置，无主动选择。首次启动时没有任何对话框。设置中没有任何复选框。模型被下载了；用户数月后才发现，因为磁盘空间满了[5][6][7]。

3. 移除比安装困难得多。添加该文件无需任何点击。移除它则需要：(a) 发现该文件存在，(b) 理解它是什么，(c) 导航进入一个隐藏的用户配置文件路径，(d) 删除它（在 Windows 上，还需先清除只读属性），以及 (e) 接受 Chrome 会在下一个符合条件的窗口静默重新下载它，除非用户还导航到 chrome://flags、企业策略或特定平台的配置工具来禁用底层的 Chrome AI 功能 [5]。这些步骤中，没有一个记录在普通用户会查看的地方——默认的 Chrome 中甚至没有任何提示。

4. 预置用户未请求的功能。Nano 模型存在于用户磁盘上，以便使用它的 Chrome 功能在用户调用时能立即运行。用户并未调用过任何这些功能。该模型仍然存放在那里，占用 4 GB 空间。

5. 通过通用命名造成范围膨胀。OptGuideOnDeviceModel 是 Chrome 内部术语，指“优化指南（OptimizationGuide）设备端模型存储”。一个查看自己磁盘使用情况的用户，即使大致知道自己在看什么，也无法将 OptGuideOnDeviceModel/weights.bin 与“Gemini Nano 大语言模型权重”对应起来。准确的命名应该是 GeminiNanoLLM/weights.bin。谷歌选择了混淆名称。

6. 注册到用户未配置的资源中。一个未打开 Chrome AI 功能的用户仍然会获得该模型。一个曾打开过一次并决定不感兴趣的用户仍然会获得该模型。该文件的存在与用户对其所驱动的任何功能的实际使用情况脱钩。

7. 文档缺失。谷歌面向用户的 Chrome AI 功能文档，并未以与 4 GB 静默下载相称的显著程度，告知用户该功能可用的代价是一个 4 GB 的文件出现在他们的设备上。该行为记录在好奇的管理员会找到的地方。它并未记录在普通用户在安装 Chrome 之前或 Chrome 决定开始推送模型之前会查看的地方。

8. 每次运行时自动重新安装。与 Claude 桌面版相同。删除文件后，Chrome 会重新创建它。用户的删除操作被视为需要纠正的临时状态，而非需要尊重的指令。

9. 任何未来用户同意的追溯效力。如果谷歌未来开始询问用户"您是否希望 Chrome 下载一个 4 GB 的 AI 模型"，该提示并不能追溯性地使已在数亿台设备上发生的静默安装合法化。信任关系已遭破坏。字节已经传输。环境已被写入。

10. 经过代码签名，通过正常发布渠道推送。这不是测试版本的行为。这是 Chrome 稳定版。

"AI 模式"按钮是压轴之笔

以下是应该让在座每一位隐私律师放下咖啡杯的部分。当 Chrome 147 针对符合条件的用户配置文件启动时，多功能框——窗口顶部的地址栏，整个浏览器中最显眼的界面区域——会在 URL 字段右侧显示一个"AI 模式"按钮。一个理性的用户，在 2026 年看到"AI 模式"出现在浏览器最突出的 UI 元素中，同时了解到 Chrome 中已存在广为人知的设备端大语言模型，并且一个 4 GB 的 Gemini Nano 二进制文件已静默安装到磁盘上，自然会得出一个看似显而易见的推论——这个可见的 AI 模式正在使用设备端模型，用户的查询会留在设备上，本地模型正是这个看似本地化的界面的动力来源。

这段推理的每一步都是错的。Chrome 147 地址栏中的 AI 模式按钮是一个云端支持的搜索生成体验界面——用户在其中输入的每一个查询都会通过网络发送到 Google 的服务器，由 Google 托管的模型进行处理。AI 模式界面流程根本不会调用设备端的 Nano 模型。它们是两条完全独立的代码路径——浏览器中最显眼的 AI 功能并未使用用户已被静默安装的本地模型，而真正使用本地模型的功能（在 `<textarea>` 中的“帮我写”、标签组 AI 建议、智能粘贴、页面摘要）则深藏在文本区域右键菜单和标签组右键菜单中，普通用户平均而言永远也不会发现它们。

想想这种安排实际上意味着什么。用户承担了静默安装的存储成本（磁盘占用 4 GB，外加静默下载的带宽消耗）。用户最直观的 AI 体验——那个他们实际看到并点击的按钮——完全没有带来任何设备端的益处，因为它无论如何都会路由到 Google 的服务器。因此，设备端模型是强加给用户的一项沉没成本，而在透明度最关键的界面上却没有带来任何对等的透明度收益。换句话说——如果设备端安装能让用户明确知道“你的 AI 模式查询会留在你的设备上”，那么这种安装还能有一个站得住脚的隐私逻辑（更差的存储，更好的数据流向）。但事实并非如此——这种安装以用户的磁盘和带宽为代价，为 Google 提供了一项未来可用的资源（该模型可以被 Chrome 的其他子系统调用，无需额外的服务器往返），而最显眼的 AI 界面却一如既往地将用户的查询发送到 Google。本地模型是 Google 放置在用户设备上的一项资产——它不是用户的资产，甚至可以说，这不过是障眼法，用来掩盖一个事实：那个可见的 AI 模式实际上并没有使用本地模型。

这种安排本身至少涉及 EDPB 指南 03/2022 [20] 中列出的三类欺骗性设计模式。首先，这是误导性信息，因为可见的“AI 模式”标签让用户对处理发生的位置产生了错误印象——该标签并未写明“云端支持”或“查询发送至 Google”，而一个了解设备端 AI 的普通用户会从磁盘上存在的 4GB 设备端模型推断出本地处理。其次，这是跳过式设计，因为用户没有机会在纯本地与云端支持的 AI 界面之间做出选择——两者通过同一次上游推送同时开启，且没有针对每项功能的单独同意。第三，这是阻碍式设计，因为关闭 AI 模式并不会同时移除设备端安装，而移除设备端安装也不会关闭 AI 模式——两者是分开控制的，要发现这两项控制，用户需要同时了解 `chrome://flags` 和 `chrome://settings/ai`，而这两者在默认 Chrome 中都不显眼。

因此：这不仅仅是一次未经同意的安装，更是一次未经同意的安装，同时充当了并行云端支持界面的掩护，向用户错误地表示他们的输入内容是在何处处理的。这两个层面共同加剧了同意问题。

为何这在欧洲经济区和英国属于违法行为

第 2002/58/EC 号指令（《电子隐私指令》）第 5(3) 条禁止在未获得用户事先、自由给予、具体、知情且明确的同意的情况下，在用户或订户的终端设备中存储信息，或获取已存储信息的访问权限，除非该行为对于提供用户明确要求的信息社会服务是严格必要的 [2]。4GB 的 Gemini Nano 权重文件是存储在用户终端设备中的信息。用户并未同意。用户也未请求任何严格需要 4GB 设备端大语言模型的服务。没有该文件，Chrome 仍可正常运行。因此，该行为直接违反了第 5(3) 条。

GDPR 第 5 条第 1 款要求个人数据的处理必须对数据主体合法、公正且透明 [3]。当用户硬件被分析以确定是否有资格推送模型，当安装事件被记录在谷歌服务器上，并且当模型驱动的设备端功能处理用户提示词时（无论这些提示词是否离开设备），所有这些处理的合法性、公正性和透明度都取决于用户是否被以通俗易懂的语言告知正在发生什么。而用户并未被告知。

GDPR 第 25 条要求控制者实施适当的技术和组织措施，以确保默认情况下仅处理每个特定目的所必需的个人数据 [3]。在用户磁盘上预先暂存一个 4 GB 的 AI 模型，以应对用户未来可能调用某项 AI 功能的偶然情况，这恰恰与默认最小化原则背道而驰；而通过分析设备来决定是否推送模型，与用于在线追踪你的分析行为并无不同，因此该分析包含个人数据，并且如果 AI 模型被使用，将处理个人数据，所以 GDPR 的相关论点均在适用范围内且有效。

根据英国 GDPR 和 2003 年《隐私与电子通信条例》，分析结果相同。根据《加州消费者隐私法案》，由于缺乏针对此类预暂存软件的收集通知，谷歌的 CCPA 通知合规性存疑 [12]。

此外，还涉及各国计算机滥用法规下的刑事违法问题——这一点同样不容低估。

ESG：静默推送的气候成本

我之前写到的 Anthropic 案例是一个桌面应用程序在七个目录中安装了一个 350 字节的 JSON 清单。将所有 Claude Desktop 用户加总，其带宽和能源成本可以忽略不计。但 Chrome 的情况不同。Chrome 正在向数亿台设备推送一个 4 GB 的二进制文件。这会产生可测量、可量化且坦率地说令人担忧的环境足迹。

我使用与我们的 WebSentinel 审计平台分析网站环境相同的方法进行计算 [13]。

  • 网络数据传输的能源强度：每 GB 0.06 千瓦时，取自 Pärssinen 等人（2018 年）《在线广告的环境影响评估》（发表于《整体环境科学》）[14] 的中位值。该论文报告的范围为 0.04-0.10 千瓦时/GB，具体取决于固定线路与移动传输的比例以及是否包含终端用户设备的能耗。0.06 是一个合理的中间值。
  • 电网排放因子：每千瓦时 0.25 千克二氧化碳当量，取自欧洲环境署/国际能源署为 2024 年报告编制的欧盟 27 国综合电力供应因子 [15]。全球范围内，该数值从以可再生能源为主的电网约 0.10 千克/千瓦时，到以煤电为主的电网超过 0.70 千克/千瓦时不等；0.25 是全球平均水平的中位值，也是 WebSentinel 默认使用的数值。

单次 Nano 推送的每设备成本

  • 带宽：4 GB
  • 能耗：每次推送每设备 4 × 0.06 = 0.24 千瓦时
  • 二氧化碳排放：每次推送每设备 0.24 × 0.25 = 0.06 千克二氧化碳当量

这是每台设备、每次推送的数值。这是单次下载模型的数据。它不包括用户尝试删除文件失败后触发的重新下载，也不包括后续的模型更新，更不包括实际使用模型时设备上的推理能耗。这仅仅是向一台设备一次性交付的成本。

部署范围内的总成本

谷歌并未公布有多少设备收到了 Nano 推送。推送的资格标准（由 Chrome 根据 CPU 类别、GPU 类别、系统内存和可用显存计算得出的硬件“性能等级”——在 Apple Silicon 上通常需要约 16 GB 统一内存或更高，在 Windows 和 Linux 上则需要约 16 GB 内存以及具备足够显存的独立或集成 GPU）排除了消费级设备中最低端的部分，但符合条件的用户群体仍然极其庞大。我将使用三个说明性的部署区间，以便读者自行选择他们认为最接近现实的数值。对于一项默认开启的 Chrome 功能来说，这些区间规模都不算离谱。

接收推送的设备数量 推送的总字节数 总能耗 总二氧化碳当量排放
1 亿台（低区间：约占 Chrome 用户的 3%） 400 PB 24 GWh 6,000 吨二氧化碳当量
5 亿台（中区间：约占 Chrome 用户的 15%） 2 EB 120 GWh 30,000 吨二氧化碳当量
10 亿台（高区间：约占 Chrome 用户的 30%） 4 EB 240 GWh 60,000 吨二氧化碳当量

为了将这些数字与 ESG 报告可能对比的指标进行比较：

  • 24 GWh（低区间）大约相当于约 7000 户英国家庭的年用电量 [16]。

  • 120 GWh（中区间）大约相当于约 36000 户英国家庭的年用电量，或一台 14 MW 风力发电机按英国典型容量系数运行时的年发电量。

  • 240 GWh（高区间）大约相当于约 72000 户英国家庭的年用电量，或约 28 MW 已安装风电装机容量的年发电量。

  • 6000 吨 CO2e（低区间）大约相当于欧盟约 1300 辆普通乘用车的年排放量 [17]。

  • 30000 吨 CO2e（中区间）大约相当于 6500 辆汽车的排放量，或约 8000 名乘客乘坐经济舱从伦敦到悉尼的一次往返航班。

  • 60000 吨 CO2e（高区间）大约相当于 13000 辆汽车的排放量。

这些仅是交付环节的数据。它们统计的是在网络中恰好传输一次的字节量。它们不包括：

  • 用户硬件上持续存在的约 4 GB × N 台设备的磁盘存储成本。SSD 每 GB 的隐含碳排放成本约为每 GB 制造 NAND 产生 0.16 kg CO2e [18]；对于 10 亿台设备 × 4 GB，这意味着约 640,000 吨 CO2e 的 SSD 隐含碳排放被分配到了一个用户并未同意的用例上。这是一次性的制造碳排放影响，但存储负担却由用户设备永久承担，而这些空间本可用于存储用户数据。
  • 调用 Nano 时的设备端推理能耗。单次推理的能耗很小。但当 Chrome 有 20 亿日活用户时，这个数字就不再小了。
  • 尝试删除该文件的用户重新下载的循环。每次成功触发重新下载，每台设备每次重新下载就会产生额外的 4 GB × 0.06 kWh × 0.25 kg = 0.06 kg CO2e。
  • 未来的模型更新。Gemini Nano 并非一次性产物；它是一个不断演进的模型，会定期更新权重。每次更新都会重复上述计算。

在 ESG 报告的语言体系中，当前模型的一次性推送，对谷歌而言属于范围 3 类别 11（"已售产品的使用"）排放，其归因于在谷歌分发的免费产品运行过程中，用户端接收了一个用户并未请求的二进制文件 [4]。

带宽方面为何本身也很重要

除了碳排放成本，网络带宽成本由互联网服务提供商、移动网络运营商、按流量计费的用户以及每一段必须将 4 GB 非请求数据载荷传输到未请求目的地的网络基础设施承担。根据 Pärssinen 的参考文献，该传输能耗中约 50% 发生在接入网络和 CDN 边缘，约 30% 发生在用户侧设备（路由器、调制解调器、网卡），其余部分发生在核心网络。这些基础设施没有哪一部分是免费的。Chrome 推送的每一个字节，都在与用户真正想要的字节竞争。

对于使用有流量上限的移动数据套餐的用户，尤其是在智能手机作为唯一互联网接入方式占主导地位的地区（非洲大部分地区、南亚和东南亚大部分地区、拉丁美洲大部分地区），4 GB 的非请求下载量大约相当于一个月的流量配额，被 Chrome 代表用户白白消耗掉了。据我所知，谷歌尚未发布任何关于此行为对按流量计费上网人群福利影响的分析。

请记住，许多没有光纤、有线或 ADSL 接入的家庭都在使用移动数据套餐（4G 和 5G），并且这些套餐也用于台式设备以及移动设备——因此，认为谷歌不会将此功能推送到移动设备上的论点（尽管我无论如何也没有找到任何官方证据支持该论点）是站不住脚的。

谷歌本应怎么做

这并不是一个难以实现的清单。它与我之前在 Claude Desktop 文章中给 Anthropic 的建议清单相同，只是应用到了谷歌身上。

  1. 征求用户同意。当 Chrome 首次即将下载 Nano 模型时，弹出一个对话框。"Chrome 希望向您的设备下载一个 4 GB 的 AI 模型文件，以支持以下功能。允许，或跳过并稍后决定。"两个按钮。搞定。

  2. 拉取，而非推送。将下载触发为用户首次调用 AI 功能的后续结果。让功能本身成为同意事件。不要基于可能性预先部署。

  3. 将其可视化。在 chrome://settings/ 中，列出 Chrome 已下载的 AI 模型文件、文件大小、所支持的功能，以及每个模型对应的"移除并停止下载"按钮。让移除操作持久生效，而非 Chrome 在下次启动时就会纠正的临时状态。

  4. 将其文档化。在微软商店的 Chrome 描述中、在 Chrome 安装程序中、在 Google Chrome 下载页面上，明确告知用户：Chrome 将在支持的硬件上下载体积较大的额外模型文件。目前，这对普通用户而言基本处于无文档说明的状态。

  5. 尊重删除。如果用户删除了 weights.bin 文件，不要重新创建它。如果用户对自己磁盘上的内容有强烈偏好，应用程序无权因为自认为更懂而推翻这一偏好。

  6. 规模化披露。在 Google 的年度 ESG 报告中，公布所有 AI 功能模型推送至用户设备所消耗的总带宽和碳足迹，并按地区细分。将其视为它本应归属的范围三第 11 类排放。为其负责。

  7. 追溯通知。对于未经同意已收到模型的用户，应在下次启动 Chrome 时告知他们发生了什么，展示相关文件，并提供一键撤销与卸载的选项。这也是 Anthropic 本应采取的同等的追溯同意步骤。

结语

这两起事件——我两周前写到的 Anthropic Claude Desktop 清单安装，以及我今天正在写的 Google Chrome Gemini Nano 推送——背后是相同的决策逻辑。大型 AI 供应商的某个工程团队认定，用户的机器是一个需要为供应商产品路线图优化的部署面，而非一台其所有者对运行内容拥有合法决定权的个人设备。

Anthropic 的案件涉及在大约三百万台 Claude Desktop 用户设备上预先授权浏览器自动化操作 [19]。而 Google 的案件，根据我的中等估算，则是在大约五亿台 Chrome 用户设备上放置了 4 GB 的 AI 模型权重，并相应带来了更大的 ePrivacy（电子隐私）、GDPR（通用数据保护条例）以及环境风险敞口。

两家公司都公开宣称自己关心安全、伦理和负责任的 AI。然而，根据本文记录的那些静默安装行为，两家公司都破坏了作为其任何立场合法性的基础——用户同意。这些字节是 AI 字节这一事实，并不能使它们免受管辖未经许可写入用户设备的其他所有字节的法律约束。这些字节相对于用户磁盘而言“很小”这一事实，也不能免除其累积的碳足迹对气候造成的真实、可衡量且持续存在的危害。

如果 Google 的下一次 Chrome 更新静默移除这些未经同意的安装，并将该行为替换为明确的用户主动选择加入机制，那么我们就知道这家公司能够审时度势。如果它不这样做，那么我们就知道这家公司关于负责任 AI 和可持续发展的公开立场究竟价值几何。

鉴于这正日益成为一种默认行为，人们不得不提出一个非常简单的问题：监管机构和公诉机关何时才会开始执行自 2002 年以来就已存在的法律？还是说，全球科技公司可以免于刑事和民事法律的制裁？

参考文献

[1] Hanff, A. 《Anthropic 在你安装 Claude Desktop 时秘密安装间谍软件》，That Privacy Guy!，2026 年 4 月 18 日。https://www.thatprivacyguy.com/blog/anthropic-spyware

[2] 欧洲议会与欧盟理事会。关于隐私和电子通信的第 2002/58/EC 号指令（ePrivacy 指令），第 5 条第 3 款。https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219

[3] 欧洲议会与欧盟理事会。(EU) 2016/679 号法规（GDPR），第 5 条第 1 款、第 25 条。https://eur-lex.europa.eu/eli/reg/2016/679/oj

[4] 欧洲议会与欧盟理事会。关于企业可持续发展报告（CSRD）的第 2022/2464 号指令，修订第 537/2014 号法规、第 2004/109/EC 号指令、第 2006/43/EC 号指令和第 2013/34/EU 号指令。https://eur-lex.europa.eu/eli/dir/2022/2464/oj

[5] Pure Infotech。“阻止 Chrome 在 Windows 11 上静默下载 Gemini Nano AI 模型”。https://pureinfotech.com/stop-chrome-gemini-nano-download-windows-11/

[6] Dhavale, V.“Chrome 在我的电脑上安装了一个 4GB 的大语言模型。以下是我的发现。”https://www.vishwamdhavale.com/blog/chrome-gemini-nano-on-device

[7] WinAero。“Google Chrome 秘密下载大型本地 AI 模型”。https://winaero.com/google-chrome-secretly-downloads-huge-local-ai-models/

[8] AIBase。“Google Chrome 被曝强制安装 4GB AI 模型”。https://www.aibase.com/news/25955

[9] StatCounter。“全球浏览器市场份额”。https://gs.statcounter.com/browser-market-share

[10] 维基百科。“网页浏览器的使用份额”。https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[11] DemandSage。“有多少人使用 Google Chrome（2026 年更新数据）”。https://www.demandsage.com/chrome-statistics/

[12] 加利福尼亚州。2018 年加州消费者隐私法案，加州民法典第 1798.100 条及以下条款。https://oag.ca.gov/privacy/ccpa

[13] Hanff, A。“WebSentinel ESG 考量章节方法论”。WebSentinel 报告模板，第 08 章。（来源：本文作者的审计平台，代码位于 /backend/lib/transparency/esg-calculator.js。）

[14] Pärssinen, M., Kotila, M., Cuevas, R., Phansalkar, A., Manner, J。“在线广告的环境影响评估”，《整体环境科学》，2018 年。https://www.sciencedirect.com/science/article/pii/S0195925517303505

[15] 欧洲环境署。“发电的温室气体排放强度”。https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1

[16] 英国天然气与电力市场办公室。“平均天然气和电力使用量”。（英国家庭平均用电量：约 2,700 千瓦时/年，“低”TDCV 2024。）https://www.ofgem.gov.uk/

[17] 欧洲环境署。“新乘用车平均二氧化碳排放量”（欧盟27国，2024年报告基准约109克/公里 × 约12,000公里/年 ≈ 每辆普通汽车每年约1.3吨）。https://www.eea.europa.eu/

[18] Tannu, S., Nair, P. J. “固态硬盘不为人知的秘密：隐含碳”，ACM SIGENERGY能源信息学评论，2023年。https://dl.acm.org/doi/10.1145/3630614.3630618

[19] Anthropic。2026年第一季度披露的Claude Desktop安装基数估算。（估算值；Anthropic未公布确切数字。）https://www.anthropic.com/

[20] 欧洲数据保护委员会。“关于社交媒体平台界面中欺骗性设计模式的03/2022号指南”，2.0版，2023年2月14日通过。https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-032022-deceptive-design-patterns-social-media_en

WebSentinel
Google端侧行业动态

来源：Hacker News 热门（buzzing.cc 中文翻译） · thatprivacyguy.com

导出 Markdown
返回
精选78打开原文
导出 Markdown

Google Chrome 被曝未经用户同意悄然安装 4 GB AI 模型

Hacker News 热门（buzzing.cc 中文翻译）·2026-05-05 20:25·92天前·john-doe
AI 导读

据隐私倡导网站报道，Google Chrome 浏览器在未经任何提示或用户同意的情况下，于后台自动下载并安装了一个名为“Nano”、体积达 4 GB 的人工智能模型。该行为旨在增强本地AI功能，但完全隐蔽的安装过程占用了用户设备存储空间，且未提供任何选项或通知，引发了对其数据隐私风险及软件更新透明度的广泛担忧。此事件在Hacker News上获得高度关注，突显了公众对科技公司单方面安装行为的普遍不安。

正文 · AI 翻译
Google Chrome silently installs a 4 GB AI model on your device without consent. At a billion-device scale the climate costs are insane.

Google Chrome 在用户设备上静默安装了一个 4GB 的 AI 模型

两周前，我撰文指出 Anthropic 在每台安装了 Claude Desktop 的机器上，静默地在七款基于 Chromium 的浏览器中注册了一个原生消息桥接 [1]。其模式是：用户在启动产品 A 时进行安装，未经询问便将配置写入用户已安装的产品 B、C、D、E、F、G、H 中。这种操作跨越了供应商信任边界。没有同意对话框，没有退出选项的界面。如果用户手动删除，每次启动 Claude Desktop 时，它都会重新安装。

本周，我发现了同样的模式，这次由 Google 执行。Google Chrome 正在侵入用户的机器，未经询问便将一个 4GB 的端侧 AI 模型文件写入磁盘。该文件名为 weights.bin，位于 OptGuideOnDeviceModel 目录下。它是 Google 端侧大语言模型 Gemini Nano 的权重文件。Chrome 没有询问用户，也没有向用户展示该文件。如果用户删除它，Chrome 会重新下载。

法律分析与我对 Anthropic 案例的分析相同。环境分析则是新的。以 Chrome 的规模，推送一个模型所产生的气候账单——由整个地球以大气二氧化碳的形式支付——相当于六千到六万吨二氧化碳当量排放，具体取决于接收该推送的设备数量。这就是一家公司单方面决定让二十亿人的默认浏览器大规模分发一个他们并未请求的 4GB 二进制文件所付出的环境代价。

依我之专业判断，这直接违反了第 2002/58/EC 号指令（《电子隐私指令》）第 5(3) 条 [2]，违反了《通用数据保护条例》（GDPR）第 5(1) 条关于合法性、公正性和透明度的原则 [3]，违反了 GDPR 第 25 条关于设计保护数据的要求 [3]，并且其造成的环境损害规模之大，对于任何在范围内的企业而言，都构成《企业可持续发展报告指令》（CSRD）下的应报告事件 [4]。

磁盘上有什么，以及它是如何被写入的

在任意安装了 Chrome 浏览器的机器上，用户配置文件中都存在一个名为 OptGuideOnDeviceModel 的目录。该目录内有一个名为 weights.bin 的文件，大小约为 4 GB。这是 Gemini Nano 的权重文件。Chrome 利用它来驱动谷歌以“帮我写”等名称推广的功能、设备端诈骗检测以及其他 AI 辅助的浏览器功能。

该文件出现时并未弹出任何同意提示。Chrome 设置中也没有一个名为“下载 4 GB AI 模型”的复选框。当 Chrome 的 AI 功能处于激活状态时，便会触发下载，而在近期的 Chrome 版本中，这些功能默认是开启的。在任何满足硬件要求的机器上，Chrome 都会将用户的硬件视为投放目标，并写入该模型。

这种删除后又重新下载的循环，已在多个关于 Windows 系统的独立报告中得到记录 [5][6][7][8]——用户删除，Chrome 重新下载；用户再次删除，Chrome 再次下载。要让删除操作真正生效，唯一的方法是禁用 Chrome 的 AI 功能（通过 chrome://flags 或普通家庭用户通常没有的企业策略管理工具），或者彻底卸载 Chrome [5]。在 macOS 上，该文件以用户拥有的 600 权限模式存放（因此原则上可以删除），但 Chrome 在写入字节后，会将安装状态保存在 Local State 中，一旦变体服务器下次告知 Chrome 该配置文件符合条件，下载便会再次触发——架构是相同的，只是文件权限不同。

我如何在全新创建的 Apple Silicon 配置文件上验证这一点

关于此行为的现有报告大多来自 Windows 用户，他们注意到自己的磁盘空间被占满——这很有用，但谷歌可能会（而且很可能会）试图将这些报告定性为来自非代表性配置的个例。因此，我决定在另一个平台上寻找一个干净的证据。

我找到的目击者正是 macOS 本身。内核维护着一个名为 .fseventsd 的文件系统事件日志——它在操作系统层面记录每一次文件的创建、修改和删除，独立于任何应用程序的日志记录。Chrome 无法编辑它，Google 无法远程访问它，而记录这些事件的页面文件在它们所引用的文件被删除后依然存在。

我在 2026 年 4 月 23 日创建了一个 Chrome 用户数据目录，用于运行自动化审计（这是 WebSentinel 100 站点隐私扫描的一部分）。审计驱动程序完全基于 Chrome DevTools 协议——它会加载一个页面，停留五分钟且无任何输入，捕获事件，然后在站点之间关闭 Chrome——并且该配置文件在其整个生命周期中从未接收过来自人类的任何键盘或鼠标输入。Chrome 中所有“AI 模式”界面都未被触及——事实上，Chrome 中的所有 UI 界面都未被触及，审计驱动程序仅通过 CDP 与文档交互，且从未访问过地址栏。到 4 月 29 日，该配置文件中包含了 4 GB 的 OptGuideOnDeviceModel 权重——我之所以知道这一点，是因为在清理过程中对审计配置文件目录执行了一次常规的 du -sh 命令时发现了它。

我回到 .fseventsd 去查询那 4 GB 数据具体是在何时写入的。macOS 给出了答案，精确到字节，记录在三个连续的页面文件中：

  • 2026 年 4 月 24 日，欧洲中部夏令时间 16:38:54（世界协调时 14:38:54）——Chrome 在审计配置文件中创建了 OptGuideOnDeviceModel 目录（页面文件 0000000003f7f339）。
  • 2026 年 4 月 24 日，欧洲中部夏令时间 16:47:22（世界协调时 14:47:22）——三个并发的解压子进程在 /private/var/folders/.../com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.*/ 下生成了临时目录。其中一个（5xzqPo）写入了 weights.bin、manifest.json、_metadata/verified_contents.json 和 on_device_model_execution_config.pb。第二个写入了一次证书吊销列表更新。第三个写入了一次浏览器预加载数据更新。Chrome 将一次安全更新、一次预加载刷新和一个 4 GB 的 AI 模型打包在同一个空闲窗口中处理，仿佛它们是同等重要的事情（页面文件 00000000040c8855）。
  • 2026年4月24日，欧洲中部夏令时16:53:22（世界协调时14:53:22）——解压后的 weights.bin 被移动到其最终位置 OptGuideOnDeviceModel/2025.8.8.1141/weights.bin，一同移动的还有 adapter_cache.bin、encoder_cache.bin、_metadata/verified_contents.json 以及执行配置。与此同时，另外四个模型目标（在 Chrome 的 optimization-guide 枚举中编号为 40、49、51 和 59）在 optimization_guide_model_store 中注册了新的条目——这些是与该大语言模型配对的小型文本安全与提示词路由模型。在此刻之前，这些目标均不存在于该用户配置文件中（页面文件 00000000040d0f9c）。

从目录创建到最终移动，总安装时间为14分28秒。在此期间，针对该用户配置文件的人工操作次数为零。审计驱动程序要么停留在某个第三方主页上，要么在站点之间切换——解压程序在后台运行，而一个标签页正在等待一个五分钟计时器到期。

该 fseventsd 记录中的命名，如果说有什么的话，那正是最致命的细节。临时目录名为 com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.5xzqPo——其前缀 com.google.Chrome.chrome_chrome_* 正是 Google Chrome 自身使用的包标识符和子进程命名约定。它不是 com.google.GoogleUpdater.*，也不是 com.google.GoogleSoftwareUpdate.*。写入者是 Chrome——用户已安装并信任用于加载网页的浏览器进程——它主动访问用户的文件系统，在前台标签页执行完全无关的操作时，放下了一个4GB的机器学习二进制文件。

另外三项佐证证据位于同一台机器的其他位置：

  1. Chrome 审计配置文件的本地状态 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 在向用户展示任何 AI 功能之前，就已经对我的硬件进行了特征分析（读取 GPU、读取统一内存总量），以判断我是否符合推送该模型的条件。

  2. Chrome 审计配置文件的 ChromeFeatureState 在 enable-features 块中列出了 `OnDeviceModelBackgroundDownload<OnDeviceModelBackgroundDownload` 和 `ShowOnDeviceAiSettings<OnDeviceModelBackgroundDownload`。第一个标志是触发静默下载的开关。第二个标志是在 `chrome://settings` 中显示设备端 AI 设置页面的开关。两者都由同一个发布标志控制——这意味着，根据 Chrome 自身的架构设计，在用户看到任何可以拒绝安装的设置界面之前，安装就已经开始了。那个本应让你发现该功能存在的设置页面，与安装过程是同步启用的——这是设计使然，而非疏忽。

  3. GoogleUpdater 日志记录了设备端模型控制组件（appid {44fc7fe2-65ce-487c-93f4-edee46eeaaab}）从 `http://edgedl.me.gvt1.com/edgedl/diffgen-puffin/%7B44fc7fe2-65ce-487c-93f4-edee46eeaaab%7D/...` 下载的过程——这是一个 7 MB 的压缩控制文件，于 2026 年 4 月 20 日到达，比所讨论的审计配置文件的创建时间早了三天。这就是上游控制平面：它与配置文件无关，由一个每小时触发一次的 LaunchAgent 自动启动，并且 URL 使用的是纯 HTTP（完整性由包内的 CRX-3 签名验证，而非传输层安全协议）。该控制组件向 Chrome 提供了指向实际权重的清单，随后 Chrome 进程内的 OnDeviceModelComponentInstaller（一个独立于 GoogleUpdater 的代码路径）直接从 Google 的 CDN 获取了数 GB 的权重文件。

于是我们得到了一条四重证据链——macOS 内核文件系统事件、Chrome 自身的每个配置文件状态、Chrome 运行时特性标志，以及 Google 组件更新日志——这四者都指向同一行为：一个 4 GB 的 AI 模型在未经同意、未获通知的情况下，于某个周二下午，在 14 分 28 秒内，被下载到了一个从未接收过任何人工输入的配置文件所在的磁盘上。

关于 OptGuideOnDeviceModel 目录和 weights.bin 文件的报告已在社区论坛流传超过一年——2026 年的新变化在于其规模和可验证性。Chrome 的全球市场份额仍保持在 64% 以上[9][10]，根据你采信哪个 2026 年的估算，Chrome 的全球用户量在 34.5 亿到 38.3 亿之间[9][11]，而 Google 正以越来越激进的方式将 Gemini 功能集成到 Chrome 中。这种行为已不再只影响少数平台上的少数高级用户——它正在影响数亿台设备，覆盖 Chrome 所支持的所有桌面操作系统。

与 Anthropic 的逐点对比

同一套暗黑模式剧本。我在此重复我在 Claude Desktop 文章[1]中的分类，因为这些模式完全相同，而这正是关键所在。

1. 跨信任边界的强制捆绑。Anthropic 安装了 Claude Desktop，然后写入了 Brave、Edge、Arc、Vivaldi、Opera 和 Chromium。Google 安装了 Chrome，然后在用户配置文件目录下未经授权写入了一个 4 GB 的 AI 模型。这个二进制文件并非 Chrome 本身。它是一个独立训练的机器学习模型，具有独立的用途、独立的数据保护配置以及独立的同意记录。

2. 不可见的默认设置，无主动选择。首次启动时没有任何对话框。设置中没有任何复选框。模型被下载了；用户数月后才发现，因为磁盘空间满了[5][6][7]。

3. 移除比安装困难得多。添加该文件无需任何点击。移除它则需要：(a) 发现该文件存在，(b) 理解它是什么，(c) 导航进入一个隐藏的用户配置文件路径，(d) 删除它（在 Windows 上，还需先清除只读属性），以及 (e) 接受 Chrome 会在下一个符合条件的窗口静默重新下载它，除非用户还导航到 chrome://flags、企业策略或特定平台的配置工具来禁用底层的 Chrome AI 功能 [5]。这些步骤中，没有一个记录在普通用户会查看的地方——默认的 Chrome 中甚至没有任何提示。

4. 预置用户未请求的功能。Nano 模型存在于用户磁盘上，以便使用它的 Chrome 功能在用户调用时能立即运行。用户并未调用过任何这些功能。该模型仍然存放在那里，占用 4 GB 空间。

5. 通过通用命名造成范围膨胀。OptGuideOnDeviceModel 是 Chrome 内部术语，指“优化指南（OptimizationGuide）设备端模型存储”。一个查看自己磁盘使用情况的用户，即使大致知道自己在看什么，也无法将 OptGuideOnDeviceModel/weights.bin 与“Gemini Nano 大语言模型权重”对应起来。准确的命名应该是 GeminiNanoLLM/weights.bin。谷歌选择了混淆名称。

6. 注册到用户未配置的资源中。一个未打开 Chrome AI 功能的用户仍然会获得该模型。一个曾打开过一次并决定不感兴趣的用户仍然会获得该模型。该文件的存在与用户对其所驱动的任何功能的实际使用情况脱钩。

7. 文档缺失。谷歌面向用户的 Chrome AI 功能文档，并未以与 4 GB 静默下载相称的显著程度，告知用户该功能可用的代价是一个 4 GB 的文件出现在他们的设备上。该行为记录在好奇的管理员会找到的地方。它并未记录在普通用户在安装 Chrome 之前或 Chrome 决定开始推送模型之前会查看的地方。

8. 每次运行时自动重新安装。与 Claude 桌面版相同。删除文件后，Chrome 会重新创建它。用户的删除操作被视为需要纠正的临时状态，而非需要尊重的指令。

9. 任何未来用户同意的追溯效力。如果谷歌未来开始询问用户"您是否希望 Chrome 下载一个 4 GB 的 AI 模型"，该提示并不能追溯性地使已在数亿台设备上发生的静默安装合法化。信任关系已遭破坏。字节已经传输。环境已被写入。

10. 经过代码签名，通过正常发布渠道推送。这不是测试版本的行为。这是 Chrome 稳定版。

"AI 模式"按钮是压轴之笔

以下是应该让在座每一位隐私律师放下咖啡杯的部分。当 Chrome 147 针对符合条件的用户配置文件启动时，多功能框——窗口顶部的地址栏，整个浏览器中最显眼的界面区域——会在 URL 字段右侧显示一个"AI 模式"按钮。一个理性的用户，在 2026 年看到"AI 模式"出现在浏览器最突出的 UI 元素中，同时了解到 Chrome 中已存在广为人知的设备端大语言模型，并且一个 4 GB 的 Gemini Nano 二进制文件已静默安装到磁盘上，自然会得出一个看似显而易见的推论——这个可见的 AI 模式正在使用设备端模型，用户的查询会留在设备上，本地模型正是这个看似本地化的界面的动力来源。

这段推理的每一步都是错的。Chrome 147 地址栏中的 AI 模式按钮是一个云端支持的搜索生成体验界面——用户在其中输入的每一个查询都会通过网络发送到 Google 的服务器，由 Google 托管的模型进行处理。AI 模式界面流程根本不会调用设备端的 Nano 模型。它们是两条完全独立的代码路径——浏览器中最显眼的 AI 功能并未使用用户已被静默安装的本地模型，而真正使用本地模型的功能（在 `<textarea>` 中的“帮我写”、标签组 AI 建议、智能粘贴、页面摘要）则深藏在文本区域右键菜单和标签组右键菜单中，普通用户平均而言永远也不会发现它们。

想想这种安排实际上意味着什么。用户承担了静默安装的存储成本（磁盘占用 4 GB，外加静默下载的带宽消耗）。用户最直观的 AI 体验——那个他们实际看到并点击的按钮——完全没有带来任何设备端的益处，因为它无论如何都会路由到 Google 的服务器。因此，设备端模型是强加给用户的一项沉没成本，而在透明度最关键的界面上却没有带来任何对等的透明度收益。换句话说——如果设备端安装能让用户明确知道“你的 AI 模式查询会留在你的设备上”，那么这种安装还能有一个站得住脚的隐私逻辑（更差的存储，更好的数据流向）。但事实并非如此——这种安装以用户的磁盘和带宽为代价，为 Google 提供了一项未来可用的资源（该模型可以被 Chrome 的其他子系统调用，无需额外的服务器往返），而最显眼的 AI 界面却一如既往地将用户的查询发送到 Google。本地模型是 Google 放置在用户设备上的一项资产——它不是用户的资产，甚至可以说，这不过是障眼法，用来掩盖一个事实：那个可见的 AI 模式实际上并没有使用本地模型。

这种安排本身至少涉及 EDPB 指南 03/2022 [20] 中列出的三类欺骗性设计模式。首先，这是误导性信息，因为可见的“AI 模式”标签让用户对处理发生的位置产生了错误印象——该标签并未写明“云端支持”或“查询发送至 Google”，而一个了解设备端 AI 的普通用户会从磁盘上存在的 4GB 设备端模型推断出本地处理。其次，这是跳过式设计，因为用户没有机会在纯本地与云端支持的 AI 界面之间做出选择——两者通过同一次上游推送同时开启，且没有针对每项功能的单独同意。第三，这是阻碍式设计，因为关闭 AI 模式并不会同时移除设备端安装，而移除设备端安装也不会关闭 AI 模式——两者是分开控制的，要发现这两项控制，用户需要同时了解 `chrome://flags` 和 `chrome://settings/ai`，而这两者在默认 Chrome 中都不显眼。

因此：这不仅仅是一次未经同意的安装，更是一次未经同意的安装，同时充当了并行云端支持界面的掩护，向用户错误地表示他们的输入内容是在何处处理的。这两个层面共同加剧了同意问题。

为何这在欧洲经济区和英国属于违法行为

第 2002/58/EC 号指令（《电子隐私指令》）第 5(3) 条禁止在未获得用户事先、自由给予、具体、知情且明确的同意的情况下，在用户或订户的终端设备中存储信息，或获取已存储信息的访问权限，除非该行为对于提供用户明确要求的信息社会服务是严格必要的 [2]。4GB 的 Gemini Nano 权重文件是存储在用户终端设备中的信息。用户并未同意。用户也未请求任何严格需要 4GB 设备端大语言模型的服务。没有该文件，Chrome 仍可正常运行。因此，该行为直接违反了第 5(3) 条。

GDPR 第 5 条第 1 款要求个人数据的处理必须对数据主体合法、公正且透明 [3]。当用户硬件被分析以确定是否有资格推送模型，当安装事件被记录在谷歌服务器上，并且当模型驱动的设备端功能处理用户提示词时（无论这些提示词是否离开设备），所有这些处理的合法性、公正性和透明度都取决于用户是否被以通俗易懂的语言告知正在发生什么。而用户并未被告知。

GDPR 第 25 条要求控制者实施适当的技术和组织措施，以确保默认情况下仅处理每个特定目的所必需的个人数据 [3]。在用户磁盘上预先暂存一个 4 GB 的 AI 模型，以应对用户未来可能调用某项 AI 功能的偶然情况，这恰恰与默认最小化原则背道而驰；而通过分析设备来决定是否推送模型，与用于在线追踪你的分析行为并无不同，因此该分析包含个人数据，并且如果 AI 模型被使用，将处理个人数据，所以 GDPR 的相关论点均在适用范围内且有效。

根据英国 GDPR 和 2003 年《隐私与电子通信条例》，分析结果相同。根据《加州消费者隐私法案》，由于缺乏针对此类预暂存软件的收集通知，谷歌的 CCPA 通知合规性存疑 [12]。

此外，还涉及各国计算机滥用法规下的刑事违法问题——这一点同样不容低估。

ESG：静默推送的气候成本

我之前写到的 Anthropic 案例是一个桌面应用程序在七个目录中安装了一个 350 字节的 JSON 清单。将所有 Claude Desktop 用户加总，其带宽和能源成本可以忽略不计。但 Chrome 的情况不同。Chrome 正在向数亿台设备推送一个 4 GB 的二进制文件。这会产生可测量、可量化且坦率地说令人担忧的环境足迹。

我使用与我们的 WebSentinel 审计平台分析网站环境相同的方法进行计算 [13]。

  • 网络数据传输的能源强度：每 GB 0.06 千瓦时，取自 Pärssinen 等人（2018 年）《在线广告的环境影响评估》（发表于《整体环境科学》）[14] 的中位值。该论文报告的范围为 0.04-0.10 千瓦时/GB，具体取决于固定线路与移动传输的比例以及是否包含终端用户设备的能耗。0.06 是一个合理的中间值。
  • 电网排放因子：每千瓦时 0.25 千克二氧化碳当量，取自欧洲环境署/国际能源署为 2024 年报告编制的欧盟 27 国综合电力供应因子 [15]。全球范围内，该数值从以可再生能源为主的电网约 0.10 千克/千瓦时，到以煤电为主的电网超过 0.70 千克/千瓦时不等；0.25 是全球平均水平的中位值，也是 WebSentinel 默认使用的数值。

单次 Nano 推送的每设备成本

  • 带宽：4 GB
  • 能耗：每次推送每设备 4 × 0.06 = 0.24 千瓦时
  • 二氧化碳排放：每次推送每设备 0.24 × 0.25 = 0.06 千克二氧化碳当量

这是每台设备、每次推送的数值。这是单次下载模型的数据。它不包括用户尝试删除文件失败后触发的重新下载，也不包括后续的模型更新，更不包括实际使用模型时设备上的推理能耗。这仅仅是向一台设备一次性交付的成本。

部署范围内的总成本

谷歌并未公布有多少设备收到了 Nano 推送。推送的资格标准（由 Chrome 根据 CPU 类别、GPU 类别、系统内存和可用显存计算得出的硬件“性能等级”——在 Apple Silicon 上通常需要约 16 GB 统一内存或更高，在 Windows 和 Linux 上则需要约 16 GB 内存以及具备足够显存的独立或集成 GPU）排除了消费级设备中最低端的部分，但符合条件的用户群体仍然极其庞大。我将使用三个说明性的部署区间，以便读者自行选择他们认为最接近现实的数值。对于一项默认开启的 Chrome 功能来说，这些区间规模都不算离谱。

接收推送的设备数量 推送的总字节数 总能耗 总二氧化碳当量排放
1 亿台（低区间：约占 Chrome 用户的 3%） 400 PB 24 GWh 6,000 吨二氧化碳当量
5 亿台（中区间：约占 Chrome 用户的 15%） 2 EB 120 GWh 30,000 吨二氧化碳当量
10 亿台（高区间：约占 Chrome 用户的 30%） 4 EB 240 GWh 60,000 吨二氧化碳当量

为了将这些数字与 ESG 报告可能对比的指标进行比较：

  • 24 GWh（低区间）大约相当于约 7000 户英国家庭的年用电量 [16]。

  • 120 GWh（中区间）大约相当于约 36000 户英国家庭的年用电量，或一台 14 MW 风力发电机按英国典型容量系数运行时的年发电量。

  • 240 GWh（高区间）大约相当于约 72000 户英国家庭的年用电量，或约 28 MW 已安装风电装机容量的年发电量。

  • 6000 吨 CO2e（低区间）大约相当于欧盟约 1300 辆普通乘用车的年排放量 [17]。

  • 30000 吨 CO2e（中区间）大约相当于 6500 辆汽车的排放量，或约 8000 名乘客乘坐经济舱从伦敦到悉尼的一次往返航班。

  • 60000 吨 CO2e（高区间）大约相当于 13000 辆汽车的排放量。

这些仅是交付环节的数据。它们统计的是在网络中恰好传输一次的字节量。它们不包括：

  • 用户硬件上持续存在的约 4 GB × N 台设备的磁盘存储成本。SSD 每 GB 的隐含碳排放成本约为每 GB 制造 NAND 产生 0.16 kg CO2e [18]；对于 10 亿台设备 × 4 GB，这意味着约 640,000 吨 CO2e 的 SSD 隐含碳排放被分配到了一个用户并未同意的用例上。这是一次性的制造碳排放影响，但存储负担却由用户设备永久承担，而这些空间本可用于存储用户数据。
  • 调用 Nano 时的设备端推理能耗。单次推理的能耗很小。但当 Chrome 有 20 亿日活用户时，这个数字就不再小了。
  • 尝试删除该文件的用户重新下载的循环。每次成功触发重新下载，每台设备每次重新下载就会产生额外的 4 GB × 0.06 kWh × 0.25 kg = 0.06 kg CO2e。
  • 未来的模型更新。Gemini Nano 并非一次性产物；它是一个不断演进的模型，会定期更新权重。每次更新都会重复上述计算。

在 ESG 报告的语言体系中，当前模型的一次性推送，对谷歌而言属于范围 3 类别 11（"已售产品的使用"）排放，其归因于在谷歌分发的免费产品运行过程中，用户端接收了一个用户并未请求的二进制文件 [4]。

带宽方面为何本身也很重要

除了碳排放成本，网络带宽成本由互联网服务提供商、移动网络运营商、按流量计费的用户以及每一段必须将 4 GB 非请求数据载荷传输到未请求目的地的网络基础设施承担。根据 Pärssinen 的参考文献，该传输能耗中约 50% 发生在接入网络和 CDN 边缘，约 30% 发生在用户侧设备（路由器、调制解调器、网卡），其余部分发生在核心网络。这些基础设施没有哪一部分是免费的。Chrome 推送的每一个字节，都在与用户真正想要的字节竞争。

对于使用有流量上限的移动数据套餐的用户，尤其是在智能手机作为唯一互联网接入方式占主导地位的地区（非洲大部分地区、南亚和东南亚大部分地区、拉丁美洲大部分地区），4 GB 的非请求下载量大约相当于一个月的流量配额，被 Chrome 代表用户白白消耗掉了。据我所知，谷歌尚未发布任何关于此行为对按流量计费上网人群福利影响的分析。

请记住，许多没有光纤、有线或 ADSL 接入的家庭都在使用移动数据套餐（4G 和 5G），并且这些套餐也用于台式设备以及移动设备——因此，认为谷歌不会将此功能推送到移动设备上的论点（尽管我无论如何也没有找到任何官方证据支持该论点）是站不住脚的。

谷歌本应怎么做

这并不是一个难以实现的清单。它与我之前在 Claude Desktop 文章中给 Anthropic 的建议清单相同，只是应用到了谷歌身上。

  1. 征求用户同意。当 Chrome 首次即将下载 Nano 模型时，弹出一个对话框。"Chrome 希望向您的设备下载一个 4 GB 的 AI 模型文件，以支持以下功能。允许，或跳过并稍后决定。"两个按钮。搞定。

  2. 拉取，而非推送。将下载触发为用户首次调用 AI 功能的后续结果。让功能本身成为同意事件。不要基于可能性预先部署。

  3. 将其可视化。在 chrome://settings/ 中，列出 Chrome 已下载的 AI 模型文件、文件大小、所支持的功能，以及每个模型对应的"移除并停止下载"按钮。让移除操作持久生效，而非 Chrome 在下次启动时就会纠正的临时状态。

  4. 将其文档化。在微软商店的 Chrome 描述中、在 Chrome 安装程序中、在 Google Chrome 下载页面上，明确告知用户：Chrome 将在支持的硬件上下载体积较大的额外模型文件。目前，这对普通用户而言基本处于无文档说明的状态。

  5. 尊重删除。如果用户删除了 weights.bin 文件，不要重新创建它。如果用户对自己磁盘上的内容有强烈偏好，应用程序无权因为自认为更懂而推翻这一偏好。

  6. 规模化披露。在 Google 的年度 ESG 报告中，公布所有 AI 功能模型推送至用户设备所消耗的总带宽和碳足迹，并按地区细分。将其视为它本应归属的范围三第 11 类排放。为其负责。

  7. 追溯通知。对于未经同意已收到模型的用户，应在下次启动 Chrome 时告知他们发生了什么，展示相关文件，并提供一键撤销与卸载的选项。这也是 Anthropic 本应采取的同等的追溯同意步骤。

结语

这两起事件——我两周前写到的 Anthropic Claude Desktop 清单安装，以及我今天正在写的 Google Chrome Gemini Nano 推送——背后是相同的决策逻辑。大型 AI 供应商的某个工程团队认定，用户的机器是一个需要为供应商产品路线图优化的部署面，而非一台其所有者对运行内容拥有合法决定权的个人设备。

Anthropic 的案件涉及在大约三百万台 Claude Desktop 用户设备上预先授权浏览器自动化操作 [19]。而 Google 的案件，根据我的中等估算，则是在大约五亿台 Chrome 用户设备上放置了 4 GB 的 AI 模型权重，并相应带来了更大的 ePrivacy（电子隐私）、GDPR（通用数据保护条例）以及环境风险敞口。

两家公司都公开宣称自己关心安全、伦理和负责任的 AI。然而，根据本文记录的那些静默安装行为，两家公司都破坏了作为其任何立场合法性的基础——用户同意。这些字节是 AI 字节这一事实，并不能使它们免受管辖未经许可写入用户设备的其他所有字节的法律约束。这些字节相对于用户磁盘而言“很小”这一事实，也不能免除其累积的碳足迹对气候造成的真实、可衡量且持续存在的危害。

如果 Google 的下一次 Chrome 更新静默移除这些未经同意的安装，并将该行为替换为明确的用户主动选择加入机制，那么我们就知道这家公司能够审时度势。如果它不这样做，那么我们就知道这家公司关于负责任 AI 和可持续发展的公开立场究竟价值几何。

鉴于这正日益成为一种默认行为，人们不得不提出一个非常简单的问题：监管机构和公诉机关何时才会开始执行自 2002 年以来就已存在的法律？还是说，全球科技公司可以免于刑事和民事法律的制裁？

参考文献

[1] Hanff, A. 《Anthropic 在你安装 Claude Desktop 时秘密安装间谍软件》，That Privacy Guy!，2026 年 4 月 18 日。https://www.thatprivacyguy.com/blog/anthropic-spyware

[2] 欧洲议会与欧盟理事会。关于隐私和电子通信的第 2002/58/EC 号指令（ePrivacy 指令），第 5 条第 3 款。https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219

[3] 欧洲议会与欧盟理事会。(EU) 2016/679 号法规（GDPR），第 5 条第 1 款、第 25 条。https://eur-lex.europa.eu/eli/reg/2016/679/oj

[4] 欧洲议会与欧盟理事会。关于企业可持续发展报告（CSRD）的第 2022/2464 号指令，修订第 537/2014 号法规、第 2004/109/EC 号指令、第 2006/43/EC 号指令和第 2013/34/EU 号指令。https://eur-lex.europa.eu/eli/dir/2022/2464/oj

[5] Pure Infotech。“阻止 Chrome 在 Windows 11 上静默下载 Gemini Nano AI 模型”。https://pureinfotech.com/stop-chrome-gemini-nano-download-windows-11/

[6] Dhavale, V.“Chrome 在我的电脑上安装了一个 4GB 的大语言模型。以下是我的发现。”https://www.vishwamdhavale.com/blog/chrome-gemini-nano-on-device

[7] WinAero。“Google Chrome 秘密下载大型本地 AI 模型”。https://winaero.com/google-chrome-secretly-downloads-huge-local-ai-models/

[8] AIBase。“Google Chrome 被曝强制安装 4GB AI 模型”。https://www.aibase.com/news/25955

[9] StatCounter。“全球浏览器市场份额”。https://gs.statcounter.com/browser-market-share

[10] 维基百科。“网页浏览器的使用份额”。https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[11] DemandSage。“有多少人使用 Google Chrome（2026 年更新数据）”。https://www.demandsage.com/chrome-statistics/

[12] 加利福尼亚州。2018 年加州消费者隐私法案，加州民法典第 1798.100 条及以下条款。https://oag.ca.gov/privacy/ccpa

[13] Hanff, A。“WebSentinel ESG 考量章节方法论”。WebSentinel 报告模板，第 08 章。（来源：本文作者的审计平台，代码位于 /backend/lib/transparency/esg-calculator.js。）

[14] Pärssinen, M., Kotila, M., Cuevas, R., Phansalkar, A., Manner, J。“在线广告的环境影响评估”，《整体环境科学》，2018 年。https://www.sciencedirect.com/science/article/pii/S0195925517303505

[15] 欧洲环境署。“发电的温室气体排放强度”。https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1

[16] 英国天然气与电力市场办公室。“平均天然气和电力使用量”。（英国家庭平均用电量：约 2,700 千瓦时/年，“低”TDCV 2024。）https://www.ofgem.gov.uk/

[17] 欧洲环境署。“新乘用车平均二氧化碳排放量”（欧盟27国，2024年报告基准约109克/公里 × 约12,000公里/年 ≈ 每辆普通汽车每年约1.3吨）。https://www.eea.europa.eu/

[18] Tannu, S., Nair, P. J. “固态硬盘不为人知的秘密：隐含碳”，ACM SIGENERGY能源信息学评论，2023年。https://dl.acm.org/doi/10.1145/3630614.3630618

[19] Anthropic。2026年第一季度披露的Claude Desktop安装基数估算。（估算值；Anthropic未公布确切数字。）https://www.anthropic.com/

[20] 欧洲数据保护委员会。“关于社交媒体平台界面中欺骗性设计模式的03/2022号指南”，2.0版，2023年2月14日通过。https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-032022-deceptive-design-patterns-social-media_en

WebSentinel

来源：Hacker News 热门（buzzing.cc 中文翻译）· thatprivacyguy.com