凌晨，4GB 悄然落盘
2026 年 4 月 24 日下午四点三十八分（中欧夏令时），Alexander Hanff 的一台 Apple Silicon Mac 上，一个名为 OptGuideOnDeviceModel 的目录在 Chrome 用户配置文件夹里悄然出现。十四分钟二十八秒后，这个目录里多了一个文件：weights.bin，体积约 4 GB。那是 Gemini Nano 的模型权重，Google 的本地端大型语言模型。
这台 Mac 的用户配置文件，整个存在期间没有收到过任何人工输入。Hanff 是隐私审计员，他用这个配置文件运行自动化的隐私扫描任务——脚本通过 Chrome DevTools Protocol 控制浏览器，加载目标页面、停留五分钟、采集数据，再关闭 Chrome，整个过程地址栏从未被触碰，任何 AI 功能入口从未被点击。
让这件事得以被精确还原的，是 macOS 内核本身。系统维护一份名为 .fseventsd 的文件系统事件日志，以内核级权限记录每一次文件的创建、修改和删除，Chrome 无法篡改，Google 的远程服务器无法覆盖。三份连续的页文件给出了完整的时间戳：目录创建于 16:38:54，解包进程在 16:47:22 展开，最终文件在 16:53:22 移至目标位置。临时解包目录的命名是 com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.5xzqPo——写入主体不是 Google 的后台更新程序，而是 Chrome 浏览器进程本身，在前台标签页静静等待计时器到期的间隙，完成了这次 4 GB 的写盘动作。
Hanff 发现这件事是在几天后做例行清理时，一次 du -sh 命令的输出让他停顿了一下。社区论坛里关于 weights.bin 的抱怨其实已经流传超过一年，用户删了文件，Chrome 重新下载，再删，再下，循环往复。但那些报告大多来自 Windows 用户，Google 完全可以将其定性为”非典型配置下的个案”。这一次，Hanff 有的是内核日志、Chrome 自身的状态文件、运行时特性标记和组件更新服务器记录——四条独立证据链，指向同一个事实。
它如何瞒过你
这枚 4 GB 的文件之所以能在数以亿计的设备上悄无声息地落地，不是因为 Google 的工程师犯了粗心的错误，而是因为它的部署方式经过了精心的设计选择。
Hanff 在报告中列出了这套机制的十个特征，逐条比照一个月前 Anthropic Claude Desktop 被记录的行为，发现几乎一一对应。Chrome 安装后，未经任何提示直接开始下载模型——没有首次启动对话框，没有设置页面里的勾选项，没有通知。用户若想删除这个文件，需要先知道它的存在，再找到它藏身的隐藏路径，再手动删除，再接受它会在下次 Chrome 判定设备”符合条件”时自动重新出现这一现实，最后还要自己去 chrome://flags 或企业策略工具里关掉底层特性——这些操作步骤，没有一步出现在任何面向普通用户的文档里。
最能说明”设计意图”的，是 Chrome 自身的特性标记结构。Hanff 在审计配置文件的 ChromeFeatureState 里发现，控制静默下载的标记 OnDeviceModelBackgroundDownload 和控制设置页面显示的标记 ShowOnDeviceAiSettings，受同一个 rollout 标志管理——换句话说，让用户有机会在设置里”发现”这个功能并作出选择的界面，和开始下载模型这个动作，是同时发生的。用户在任何设置页面看到这个功能之前，模型早已开始传输。这不是时序的疏忽，这是工程架构的必然结果。
还有一个细节更值得停留：目录名称。OptGuideOnDeviceModel 是 Chrome 内部对”优化指南本地模型存储”的缩写，对任何不熟悉 Chromium 源码的用户而言，这串字符和一个随机哈希值没有区别。Hanff 指出，如果 Google 选择将目录命名为 GeminiNanoLLM，那么任何会用磁盘清理工具的用户都能一眼看出这是什么。混淆命名，是让用户无从发现的最后一道防线。
当你访问 LinkedIn，LinkedIn 在访问你
Google 的行为是向设备写入。一个月前被记录的另一种行为，方向相反：从设备读取。
2026 年 4 月初，科技安全媒体 BleepingComputer 独立核实了一项指控：当用户访问 LinkedIn 时，该平台向页面注入一段带有随机文件名的 JavaScript 脚本，通过尝试访问各扩展程序的静态资源 URL，逐一探测用户浏览器中安装的扩展——这是浏览器指纹识别领域的一种已知技术手段。BleepingComputer 的测试显示，这份探测名单包含 6,236 个 Chrome 扩展。同一份列表在 2025 年被首次记录时约含 2,000 项，两个月前的版本已增至 3,000 项，增长轨迹说明这是一项持续演进的主动工程，而非偶发的残留代码。
除扩展探测外，这段脚本还收集设备指纹：CPU 核心数、可用内存、屏幕分辨率、时区、语言偏好、电池状态、音频配置、存储特性。这些数据的组合，足以唯一识别一台设备，进而实现跨站追踪。
LinkedIn 并未否认扫描行为本身，官方声明将其定性为反抓取和平台保护机制：”我们确实会检测某些可能违反服务条款的扩展程序。”这一解释在技术层面有其逻辑，因为确实有扩展工具被用于从 LinkedIn 批量抓取会员数据。但 BrowserGate 报告——最初揭露这一行为的文件——指出了一个更令人不安的维度：LinkedIn 扫描名单中包含超过 200 款与 LinkedIn 自身销售工具存在竞争关系的产品，包括 Apollo、Lusha、ZoomInfo 等 B2B 数据服务。由于 LinkedIn 账户与真实身份、雇主和职位直接挂钩，这种扫描实质上可以让 LinkedIn 知晓”哪些公司的员工在使用哪些竞品工具”，从而在无需任何公开市场调研的情况下，获取竞争对手的企业客户分布图。
值得注意的是，BrowserGate 报告的发布者此前因抓取行为被 LinkedIn 封号，随后在德国法院申请禁令被驳回。LinkedIn 称整个报告是”败诉后转向舆论场的翻案行动”。这一背景意味着，报告中关于”数据被用于商业竞争情报”的指控尚缺乏直接证据。但 BleepingComputer 独立核实的扫描行为本身——6,000 个扩展，随机混淆的脚本名，设备指纹收集——不依赖于 BrowserGate 的立场就可以成立。
同一个决策，三家公司
将这两个案例并置，会浮现一个令人不安的规律。
时间线上：Anthropic Claude Desktop 的 Native Messaging Bridge 静默注入事件发生在四月中旬，LinkedIn 的扩展扫描被独立核实在四月初，Chrome 的 Gemini Nano 静默安装在四月底被法证记录。三起事件在不足六周内相继曝光，涉及的公司分别来自 AI 应用、职业社交和操作系统级浏览器三个领域，彼此之间并无共谋关系。
共同之处不在于协调，而在于独立收敛到了同一种工程哲学：用户的设备是一个可以被优化利用的部署端点。Anthropic 的决策是：将 Claude Desktop 安装到用户机器上，顺便在七个 Chromium 系浏览器里注册一个预授权的自动化通道，每次启动重新写入，没有提示，没有撤销界面。Google 的决策是：Chrome 已经在用户机器上了，模型权重可以趁机写进去，用户不需要知道细节，等他们哪天想用 AI 功能时，速度会更快。LinkedIn 的决策是：用户已经登录了，有浏览器，有扩展，这些信息在 Session 期间触手可及，读一读不会有人发现。
这三个决策都没有经过用户同意，都没有在用户最先看到的地方加以说明，都在被记者和研究者发现后才被动承认（或部分承认）。用 Hanff 的原话来说：这些工程团队”决定用户的设备是一个需要为厂商产品路线图服务的部署端点，而不是一台其所有者拥有合法权威的个人设备”。
在 eBay 2021 年被发现用 JavaScript 对访客设备进行端口扫描以检测远程支持软件之后，Citibank、TD Bank、Equifax 等金融机构被陆续发现在使用同一套指纹脚本。今天的浏览器生态，与那时相比，探测的规模更大，写入的内容更重，法律框架也远比五年前更具体。
边界去哪了
这些事件发生时，各公司都没有违反自己的服务条款——那些条款通常足够宽泛，可以容纳任何合理的技术实现。它们也没有在自己的法务团队面前讨论过”这是否越界”之后得出肯定的结论，然后继续推进。更可能的情况是：这些决策在工程层面被合理化为”提升用户体验”，在产品层面被归类为”后台优化”，在法务层面被认定为服务条款覆盖范围内，然后就上线了。
这是技术伦理中一种已被充分研究的决策模式：当”对用户有益”的论据与”对厂商有益”的工程选择高度重合时，同意步骤就会从流程中消失。Chrome 的本地 AI 功能确实在某些场景下让响应更快，LinkedIn 的反抓取保护确实在某种程度上保护了部分会员数据，Anthropic 的 Native Bridge 确实为 Claude 提供了跨应用的操作能力。这些功能本身不是问题，问题是它们都在用户不知情的情况下，使用用户的设备资源实现了。
Hanff 列出的应然清单并不复杂：在首次写入前弹出对话框，询问用户是否允许；把已写入的 AI 模型文件在设置页面里列出来，提供持久有效的删除选项；在应用商店描述和安装引导里告知用户会有这种行为；尊重用户的删除指令，不要把删除视为需要纠正的瞬态异常。这些要求，任何一条都不需要等待新的法规出台才能实现，它们只需要工程团队在一个优先项清单上，把”用户知情”列在”后台预加载”之前。
这里存在一个值得追问的结构性问题：如果”用户知情同意”在工程决策链条上的优先级始终低于”产品体验优化”，那么任何公司发布的隐私承诺，都只是一份在下一次产品迭代前有效的临时文件。三家公司、三个月、三种手法——写入、读取、注册——这不是巧合，这是一种关于谁拥有你的设备的默认答案，在没有人明说的情况下，已经被确立了。
报道文章：
https://www.thatprivacyguy.com/blog/chrome-silent-nano-install