你猜怎么着？如果你是Chrome用户，从技术上讲，你就是localllama成员！

# Google Chrome 在未经同意的情况下向你的设备静默安装了一个 4 GB 的 AI 模型。在十亿设备规模下，气候成本高得离谱。 来源：https://www.thatprivacyguy.com/blog/chrome-silent-nano-install/ 两周前我写过 Anthropic 在每台安装了 Claude Desktop 的机器上静默注册一个原生消息桥到七款基于 Chromium 的浏览器中 [1]。模式是：用户启动产品 A 时进行安装，在未询问的情况下将配置写入用户已安装的产品 B、C、D、E、F、G、H 中。跨越供应商信任边界。没有同意对话框。没有退出 UI。用户手动删除后，每次启动 Claude Desktop 时都会重新安装。 本周我发现了相同的模式，由 Google 执行。Google Chrome 正在进入用户的机器，在未询问的情况下将一个 4 GB 的本地 AI 模型文件写入磁盘。文件名为 `weights.bin`。它位于 `OptGuideOnDeviceModel` 中。这是 Gemini Nano（Google 的本地 LLM）的权重文件。Chrome 没有询问。Chrome 没有展示出来。用户删除后，Chrome 会重新下载。 法律分析与我在 Anthropic 案例中给出的相同。环境分析则是新的。以 Chrome 的规模，一次模型推送的气候账单——由整个地球以大气中的二氧化碳支付——相当于六千到六万吨二氧化碳当量排放，具体取决于接收推送的设备数量。这就是一家公司单方面决定二十亿用户的默认浏览器将大规模分发一个他们未曾请求的 4 GB 二进制文件的环境成本。 根据我的专业判断，这直接违反了 2002/58/EC 指令（ePrivacy 指令）第 5(3) 条 [2]，违反了 GDPR 第 5(1) 条关于合法性、公平性和透明度的原则 [3]，违反了 GDPR 第 25 条关于数据保护设计的义务 [3]，并且其环境损害程度对于任何在《企业可持续发展报告指令》（CSRD）范围内的企业来说都是一个应报告事件 [4]。 ## 磁盘上的内容及其来源 在任何安装了 Chrome 的机器上，用户配置文件中都有一个名为 `OptGuideOnDeviceModel` 的目录。里面有一个名为 `weights.bin` 的文件。该文件大约 4 GB。这是 Gemini Nano 的权重文件。Chrome 用它来驱动 Google 以“帮写”（Help me write）、设备端诈骗检测以及其他人工智能辅助浏览器功能为名进行营销的功能。 该文件出现在没有同意提示的情况下。Chrome 设置中没有标有“下载 4 GB AI 模型”的复选框。当 Chrome 的 AI 功能激活时就会触发下载，而在最近的 Chrome 版本中，这些功能默认是激活的。在任何满足硬件要求的机器上，Chrome 都将用户的硬件视为交付目标并写入模型。 删除和重新下载的循环在多个独立的 Windows 安装报告中已有记录 [5][6][7][8]——用户删除，Chrome 重新下载，用户再次删除，Chrome 再次重新下载。让删除持久生效的唯一方法是通过 `chrome://flags` 或企业策略工具（普通家庭用户通常没有）禁用 Chrome 的 AI 功能，或者完全卸载 Chrome [5]。 在 macOS 上，该文件以模式 600 存储，归属于用户（因此理论上可以删除），但 Chrome 在写入字节后将安装状态保存在 `Local State` 中，一旦 variations 服务器下次告诉 Chrome 该配置文件符合条件，下载就会再次触发——架构相同，只是文件权限不同。 ## 我在一个全新创建的 Apple Silicon 配置文件上如何验证 关于此行为的大多数现有报告来自注意到磁盘空间占满的 Windows 用户——这很有用，但 Google 可能会（并且很可能将）试图将这些报告描述为来自非典型配置的轶事。因此，我在不同平台上寻找一个干净的证据。 我找到的证据是 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 CEST (14:38:54 UTC)**——Chrome 在审计配置文件中创建 `OptGuideOnDeviceModel` 目录（分页文件 `0000000003f7f339`）。 - **2026 年 4 月 24 日 16:47:22 CEST (14:47:22 UTC)**——三个并发的解包子进程在 `/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 CEST (14:53:22 UTC)**——解包后的 `weights.bin` 被移动到其最终位置 `OptGuideOnDeviceModel/2025.8.8.1141/weights.bin`，同时还有 `adapter_cache.bin`、`encoder_cache.bin`、`_metadata/verified_contents.json` 和执行配置。同时，四个额外的模型目标（在 Chrome 的优化指南枚举中编号为 40、49、51 和 59）在 `optimization_guide_model_store` 中注册了新条目——这些是与 LLM 配对的小型文本安全和提示路由模型。在此刻之前，这些目标在配置文件中都不存在（分页文件 `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——用户已安装并信任用于加载网页的浏览器进程——自行主动进入用户文件系统并在前台标签页做完全不相关的事情时放置一个 4 GB 的机器学习二进制文件。 在同一台机器上的其他位置还有三条进一步佐证： 1. **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 功能出现。 2. **Chrome 的 `ChromeFeatureState`** 中，审计配置文件列出了 `OnDeviceModelBackgroundDownload`、标签组 AI 建议、智能粘贴、页面摘要等，这些功能深埋在文本区域右键菜单和标签组右键菜单中，普通用户平均来说永远都不会发现。 想想这个安排实际上是什么。用户承担静默安装的存储成本（磁盘上 4 GB，加上静默下载的带宽）。用户最可见的 AI 体验——他们实际看到并点击的药丸——根本没有提供任何本地设备的好处，因为它无论如何都路由到 Google 的服务器。因此，本地模型是强加给用户的沉没成本，在透明度最重要的表面没有任何补偿性的透明度好处。 换句话说——如果本地安装本应给用户一个清晰的“你的 AI 模式查询停留在你的设备上”属性，那么该安装将有一个站得住脚的隐私框架（更差的存储，更好的数据流）。但它没有——该安装仅以用户的磁盘和带宽为代价，给 Google 提供了一个未来选项资源（该模型可以被其他 Chrome 子系统调用而无需进一步的服务器往返），而主要的 AI 界面继续像以前一样将用户的查询发送给 Google。本地模型是 Google 放置在用户设备上的资产——它不是用户资产，甚至可以说它只是障眼法，用来隐藏实际上可见的 AI 模式并未使用本地模型这一事实。 这个安排本身至少涉及 EDPB 指南 03/2022 中分类的三个欺骗性设计模式家族 [20]。它是**误导性信息**，因为可见标签“AI 模式”造成了处理地点方面的虚假印象——标签没有说“云端支持”或“查询发送给 Google”，而了解本地 AI 的理性用户会从其磁盘上存在一个 4 GB 本地模型推断出本地处理。它是**跳过**，因为用户没有得到选择纯本地与云端支持的 AI 界面的机会——两者被相同的上游发布同时打开，没有针对每项功能的同意。它是**阻碍**，因为关闭 AI 模式不会同时移除本地安装，而移除本地安装也不会关闭 AI 模式——两者是分别控制的，发现这两个控制都需要同时了解 `chrome://flags` 和 `chrome://settings/ai`，这两者在默认 Chrome 中都不明显。 所以：不仅仅是一个未经同意的安装，而且是一个未经同意的安装，同时为并行的云端支持界面提供了掩护，该界面在用户输入被处理地点上误导了用户。这两个层面共同加剧了同意问题。 ## 为什么这在 EEA 和英国是非法的 2002/58/EC 指令（ePrivacy 指令）第 5(3) 条禁止在订户或用户的终端设备中存储信息或访问已存储的信息，除非用户事先自由给予、具体、知情、明确的同意，除非严格为了提供用户明确请求的信息社会服务所必需 [2]。4 GB 的 Gemini Nano 权重文件是存储在用户终端设备中的信息。用户没有同意。用户没有请求任何严格需要 4 GB 本地 LLM 的服务。Chrome 没有该文件也能运行。直接违反了第 5(3) 条。 GDPR 第 5(1) 条要求处理个人数据应合法、公平、透明 [3]。当用户硬件被特征描述以确定模型推送资格时，安装事件记录在 Google 服务器上，而模型驱动的本地功能处理用户提示（无论这些提示是否离开设备），所有这些处理的合法性、公平性和透明度都取决于用户是否被告知用通俗语言说明正在发生的事。但并没有。 GDPR 第 25 条要求控制者实施适当的技术和组织措施，以确保默认情况下只处理每个特定目的所必需的个人数据 [3]。将 4 GB AI 模型预先放在用户磁盘上，以应对用户将来可能调用 AI 功能的可能性，这与默认最小化的架构原则相反；并且对设备进行特征描述以决定是否推送模型，与用于在线跟踪你的特征描述并无不同，因此该特征描述包含个人数据；如果 AI 模型被使用，将处理个人数据，因此 GDPR 论点在范围内且有效。 根据英国 GDPR 和 2003 年隐私与电子通信法规，分析结果相同。根据加州消费者隐私法案（CCPA），缺少涵盖这一特定预装软件类别的收集通知使 Google 的 CCPA 通知立场受到质疑 [12]。 还有各种国家计算机滥用法规下的刑事违法行为——这同样再怎么强调也不为过。 ## ESG：静默推送的气候成本 我之前写的 Anthropic 案例是一个桌面应用程序在七个目录中安装了一个 350 字节的 JSON 清单。其带宽和能源成本，合计所有 Claude Desktop 用户，可以忽略不计。Chrome 案例则不同。Chrome 正在向数亿设备推送一个 4 GB 的二进制文件。这具有可测量、可量化且令人震惊的环境足迹。 我使用我们的 WebSentinel 审计平台应用于网站环境分析的相同方法进行计算 [13]： - 网络数据传输的能源强度：**0.06 kWh/GB**，基于 Pärssinen 等人 (2018) 《在线广告的环境影响评估》的中值带，《Science of The Total Environment》[14]。该论文报告的区间为 0.04–0.10 kWh/GB，具体取决于固定线路与移动传输的比例以及终端设备能源的包含情况。0.06 是站得住脚的中值点。 - 电网排放因子：**0.25 kg CO2e/kWh**，基于 EEA/IEA 2024 年报告的欧盟 27 国电力供应综合因子 [15]。全球该数值从以可再生能源为主的电网约 0.10 kg/kWh 到以燃煤为主的电网超过 0.70 kg/kWh；0.25 是全球推送的中值带，也是 WebSentinel 默认使用的值。 ### 一次 Nano 推送的每设备成本 - **带宽**：4 GB - **能源**：4 × 0.06 = **0.24 kWh** 每设备每次推送 - **CO2**：0.24 × 0.25 = **0.06 kg CO2e** 每设备每次推送 这是每设备每次推送。单次下载模型。不包括用户尝试删除文件失败而触发的重新下载。不包括后续的模型更新。不包括实际使用模型时的设备端推理能耗。仅是一次交付到一个设备的成本。 ### 整个部署的总成本 Google 不公布有多少设备接收到 Nano 推送。触发推送的资格标准（Chrome 根据 CPU 类别、GPU 类别、系统 RAM 和可用 VRAM 计算的硬件“性能等级”——在 Apple Silicon 上通常需要约 16 GB 统一内存或更好，在 Windows 和 Linux 上需要约 16 GB RAM 和具有足够 VRAM 的独立或集成 GPU）排除了消费级安装中非常低端的设备。