Firefox AI 开关关闭后 遥测并未停止的真相

在浏览器与人工智能功能深度融合的当下 Mozilla 旗下的 Firefox 一直以保护用户隐私为核心卖点 2026 年初 Mozilla 推出了被外界称为 AI 杀手开关的功能 允许用户一键关闭生成式 AI 特性 表面上看 这是对用户诉求的积极回应 然而 经过半年的实际使用与第三方独立测试 这项功能是否真的如宣传那般有效 引发了广泛讨论 本文基于独立技术作者 Marius Quabeck 的两次详尽测试 重点分析 Firefox 155 中 AI 开关的实际效果 揭示遥测 广告 联盟追踪以及实验分配等机制如何在开关之外继续运行 帮助读者建立对浏览器隐私保护的完整认知 AI 开关的设计初衷与技术原理 Mozilla 在 Firefox 中引入的 AI 开关 被命名为 阻止 AI 增强 其设计初衷是让用户能够便捷地关闭浏览器内置的生成式 AI 功能 这些功能包括智能标签分组 链接预览要点提取 PDF 替代文本生成 侧边栏聊天机器人 翻译功能以及最新的 Smart Window 等 通过设置中的 AI 控件面板 用户可以一键将所有这些功能设置为阻止状态 从技术实现来看 该开关通过修改多个 about:config 首选项来完成其工作 在 Firefox 155 版本中 开关控制的配置项已从最初的九个扩展到十一个 新增的配置包括 browser.ai.control.smartWindow 和 extensions.ml.enabled 后者用于阻止扩展程序使用 Firefox 提供的 AI 能力 此外 浏览器还会将 browser.ml.chat.enabled browser.ml.chat.page browser.ml.linkPreview.enabled 等多项配置一并修改为关闭状态 这一设计的逻辑是清晰的 即为用户提供一个统一的入口 来管理浏览器中所有与 AI 相关的功能 减少用户在繁杂设置中逐项查找的困扰 然而 这一开关的实际作用范围却存在明显的局限性 遥测数据收集不因开关而停止 测试中最令人关注的发现是 当用户启用 AI 阻止开关后 Firefox 的遥测数据收集并未受到任何影响 通过 Wireshark 对网络流量的深度捕获与分析 测试者在解密 TLS 流后能够完整查看浏览器向 Mozilla 服务器发送的数据内容 在用户阻止 AI 后的空闲状态测试中 浏览器在 120 秒内向 incoming.telemetry.mozilla.org 发送了 14 次遥测 POST 请求 这些请求的类别分布与未阻止状态下完全一致 包括 8 次消息系统心跳包 关键的发现是 浏览器使用的客户端标识符 包括 Glean 客户端 ID 旧版客户端 ID 配置文件组 ID 以及两个使用 UUID 在两次运行之间完全相同 没有任何轮换或删除 这意味着 即使用户明确表示希望阻止 AI 功能 浏览器仍然会持续向 Mozilla 报告其使用状态 每次阻止操作本身都成为遥测数据中的一个标记 用户在阻止 AI 后 浏览器的新标签页 ping 会继续报告 pocket.sponsored_stories_enabled 和 topsites.sponsored_enabled 等广告相关设置 还会包含与 Google 搜索相关的合作伙伴代码 使用情况报告则持续包含操作系统 内核版本 浏览器版本 发行版 默认浏览器状态以及活跃时间等详细信息 测试者共重建了 37 个完整的 POST 负载 这些数据来自解密的 HTTP/2 和 HTTP/3 流 充分证明了遥测数据在 AI 开关启用后依然活跃 广告系统继续运转 联盟追踪悄然进行 Firefox 的广告基础设施同样不受 AI 开关的影响 测试显示 在阻止 AI 后的空闲状态下 浏览器仍然会调用 ads.mozilla.org 的预检端点 以及 Merino 的每日图片 API 同时与 ads-img.mozilla.org 建立六次 TLS 握手 这些都是 Firefox 内置广告系统的标准组件 更值得警惕的是联盟追踪的行为 测试中观察到 浏览器在启动后约三秒内就会通过 DNS 预取 temuaffiliateprogram.pxf.io 这个域名 这是 Temu 联盟营销计划的追踪域名 值得注意的是 该域名的解析发生在用户从未访问过 Temu 网站的情况下 而且无论 AI 开关是否启用 这一行为都会发生 在阻止 AI 后重启浏览器时 该域名的预取会在约五秒后再次出现 虽然 DNS 预取本身不一定会导致实际的 TLS 连接 但它表明 Firefox 在用户不知情的情况下 主动解析了一个商业追踪平台的域名 这一行为与 AI 开关的隐私保护承诺形成了鲜明对比 实验分配系统在阻止后依然运行 Mozilla 的 Nimbus 实验系统提供了最具讽刺意味的测试结果 在用户阻止 AI 并重启浏览器后 Nimbus 的上下文报告 ping 如实记录了 browser.ai.control.default 被设置为 blocked 的状态 但与此同时 同一个配置文件仍然被注册在 copilot-chatbot-sunset 实验的控制组中 浏览器首选项中保留着 browser.ml.chat.nimbus 的对应配置 这一发现揭示了一个重要事实 阻止 AI 并不等于退出 Mozilla 的实验系统 相反 用户的阻止状态本身成为实验系统中的一个定位属性 此外 在同一次 ping 中 还列出了十一个与 Smart Window 用户调查 新功能介绍以及推广活动相关的标识符 这些标识符多数显示为未参与状态 但它们的存在表明 Mozilla 围绕 AI 功能建立了一套完整的活动基础设施 CEO 数据声明背后的数据来源 Mozilla 新任 CEO Anthony Enzor-DeMeo 在 2026 年 8 月发表的文章中提到 约百分之一的用户禁用了所有 AI 功能 百分之三的用户禁用了部分功能 这一数据被用来证明 Firefox 在 AI 方面的选择策略获得了用户认可 然而 这些数据恰恰来自被 AI 开关忽略的遥测系统 正是通过持续运行的遥测 Mozilla 才能准确知道有多少用户使用了阻止功能 任何点击阻止 AI 增强按钮的用户 都会自动成为 CEO 成功故事中的一个数据点 这构成了一个有趣的循环 AI 开关的存在产生了遥测数据 这些数据又被用来证明 AI 开关的成功 而遥测本身却不在开关的控制范围内 关于这百分之一数字的可靠性 社交媒体上的讨论也提出了质疑 有评论者指出 Mozilla 能够引用关于 AI 使用和信任的外部数据 但对于自家平台上的开关使用率却无法提供任何原始数据支撑 这一数字的来源和计算方法缺乏透明度 Smart Window 与首启时的 AI 请求 Firefox 155 中新加入的 Smart Window 是 AI 开关扩展的重要部分 这是一项基于提示词的浏览环境 整合了来自 Exa 的 AI 搜索 可选择的语言模型 自动标签分组建议以及可视化历史预览功能 该功能在内部仍被称为 AI Window 测试发现 在浏览器的全新配置文件中 首次启动后 23 至 24 秒内就会请求名为 ai-window-prompts 的远程设置集合 关键的是 在 B 组测试中 此时用户还停留在 Firefox 强制显示的首次运行通知页面 AI 开关根本不可访问 也就是说 第一次与 AI 相关的服务器请求 发生在用户有任何选择机会之前 这与 CEO 文章中 同意是请求来的 的表述形成了直接矛盾 隐私保护的边界需要重新审视 综合以上测试结果 可以得出明确的结论 Firefox 的 AI 开关确实如宣传那样工作 它会关闭生成式 AI 功能 包括翻译 PDF 替代文本 AI 标签分组 链接预览要点 Smart Window 和侧边栏聊天机器人等 但这一开关的边界十分清晰 它不涉及遥测 不涉及广告 不涉及实验分配 也不涉及联盟追踪 对于许多用户而言 这一边界并不直观 社交媒体上的讨论显示 部分用户确实将 AI 开关理解为关闭 AI 遥测和广告的通用开关 另一些用户则对 Firefox 的遥测规模感到惊讶 这种认知差异提示 Mozilla 需要在产品设计中提供更清晰的说明 或考虑将隐私相关的开关整合在一起 从技术角度来看 Mozilla 完全有能力扩展这一开关 当前的实现已经证明 将多个功能整合到一个控制入口是可行的 遥测和广告同样可以通过类似的方式提供给用户进行统一管理 更理想的解决方案是采用选择加入而非选择退出的模式 在浏览器首次启动时 就明确询问用户是否希望启用生成式 AI 功能 这种方式既能解决发现性问题 也将 同意是请求来的 这一理念真正落到实处 替代方案与实际选择 对于真正关心隐私的用户 测试者推荐了几种选择 LibreWolf 是桌面端的 Gecko 内核浏览器 移除了 Firefox 中的遥测和其他隐私问题 同样 基于 Firefox 的 IronFox 适用于 Android 设备 这些分叉版本通过更激进的隐私策略 满足了部分用户的需求 不过 这些替代方案也意味着用户需要接受可能的兼容性损失和功能差异 主流浏览器在隐私保护与功能丰富之间寻求平衡 用户的不同需求决定了不同的选择 技术细节补充 对于希望自行调整 Firefox 隐私设置的用户 测试中收集到一些额外的配置项值得参考 这些配置可能超出 AI 开关的范围 但有助于进一步减少浏览器的数据收集 包括 browser.ml.chat.menu browser.ml.chat.shortcuts browser.ml.chat.sidebar 等聊天相关配置 browser.ml.enable 作为总开关 browser.ml.linkPreview.optin 控制链接预览的参与度 browser.ml.modelHubRootUrl 用于指定模型中心根地址 留空可以阻止相关请求 browser.ml.pageAssist.enable 控制页面助手功能 这些配置项的调整需要用户对 about:config 有基本了解 并清楚每项修改的影响 行业反思与未来展望 Firefox 的案例实际上反映了整个浏览器行业在 AI 时代面临的挑战 主流浏览器都在集成 AI 功能 用户的隐私需求与厂商的商业策略之间存在天然张力 Mozilla 通过 AI 开关迈出了第一步 但这一步的局限性也清晰可见 作者在文章结尾引用了技术社会学家 Jürgen Geuter 的观点 即最重要的不是构建一个逃生舱口 而是不去构建用户群所厌恶的系统 这一观点直指问题的核心 即隐私保护的真正进步 应该来自于产品设计的根本转变 而非在现有架构上增加例外 回到 Mozilla 自身的表现 相比三月测试 Firefox 155 在首次启动时确实更加安静 TLS 主机数量从 25 个减少到 14 个 DNS 查询从 76 次减少到 70 次 这些改进值得肯定 但它们与 AI 开关无关 而是浏览器整体的优化结果 AI 开关的边界 从 2026 年三月到九月 没有移动一毫米 对于希望在 Firefox 中获得更全面隐私控制的用户 仍然需要 about:config Wireshark 以及对浏览器行为的持续关注 AI 开关是一个有用的工具 但它只是隐私保护拼图中的一块 而非全部 。