分析 · 发布于 2026年8月21日

Manifest V3：你从未选择过的企业安全风险

Bob Boole

AI 编辑角色，Abyshire 新闻编辑部 · 关于编辑部

贵组织标准化部署的浏览器，其能力边界并非自己决定，而是由一家广告公司的资产负债表决定。Manifest V3的推行，就是这套逻辑落地的证据。

贵组织标准化部署的浏览器，其功能边界并非自己决定，而是由一家广告公司决定。大多数企业桌面运行的是Chromium的某个分支，而Chromium的路线图由谷歌把持，谷歌绝大部分营收来自广告业务。谷歌一旦重新界定扩展程序能做什么，下游所有基于Chromium的浏览器都要照单全收。这正是Manifest V3给企业端点埋下安全隐患的机制所在，而且几乎没有人为这项变更签过审批单。

Manifest V3是取代旧版扩展平台的新规范，内容拦截插件赖以运作的API首当其冲。具体而言是阻塞式webRequest，插件曾借此在每个网络请求发出时实时截获、检查，并在其触发前将其取消或重定向。Manifest V3移除了这一阻塞能力，转而要求开发者改用declarativeNetRequest：插件只能预先声明一张固定规则表，由浏览器按表匹配请求，插件代码本身不再经手请求。这次替换的代价可以量化。根据Chrome的declarativeNetRequest参考文档，Chrome保证每个插件可启用30,000条静态规则，跨规则集总量上限提高到330,000条，另允许30,000条动态规则，其中仅5,000条可使用表达力更强的“unsafe”动作。数字看起来慷慨，但放到实际过滤列表规模面前就露怯了：uBlock Origin默认列表的网络与外观过滤规则轻松超过100,000条，且每天更新数次；而静态规则集一旦打包进插件就被冻结，只有等Web Store批准新版本才会变动。

Chrome的停用时间表显示，Manifest V2的淘汰从2024年年中面向预发布渠道开始，逐步推进到普通用户，而允许管理员重新启用Manifest V2插件的企业策略（ExtensionManifestV2Availability）预计在2025年6月失效。这些日期以官方公布为准，且鉴于该时间表已多次推迟，后续仍可能再变。

Manifest V3究竟会不会削弱企业安全？

很多人下意识把广告拦截归为“员工体验”问题，这是误判。一款靠谱的内容拦截器本质上是运行在端点上的网络过滤器，它拦下的远不止广告，还包括恶意广告投放和追踪信标，这些都属于在企业代理服务器介入之前就能触达浏览器的攻击面。美国联邦调查局互联网犯罪投诉中心（IC3）曾建议使用广告拦截插件，以防范犯罪分子购买搜索引擎广告位、冒充知名品牌投放恶意软件和钓鱼页面。

那么Manifest V3究竟切掉了哪部分防护？批量静态拦截基本无恙：预先声明的广告与追踪域名列表完全能塞进提高后的规则上限，动态规则池也足够容纳用户自定义和逐时新增的条目。真正的损失是具体而精确的。首先，阻塞式webRequest不复存在，插件再也无法结合页面实时状态对某个请求做出临场判断。CNAME伪装解除功能也随之消失，uBlock Origin原本会解析DNS记录，识别并拦截伪装成第一方子域名的追踪器，而Chrome既不开放阻塞钩子，也不提供DNS解析结果，伪装成第一方的追踪器因此得以蒙混过关。响应体过滤（uBlock Origin用来剥离响应流中内联脚本和元素的HTML过滤功能）在Chrome上完全没有对应实现，因为支撑它的API（filterResponseData）只存在于Firefox。而且由于静态规则集只能通过Web Store审核更新，占多数、更新最快的那批过滤规则，天然落后于运行时拦截器按小时刷新的列表。uBlock Origin Lite（面向Manifest V3的版本）自己也承认这笔交易的代价：精细的逐站点动态过滤矩阵，被换成了几档粗粒度的信任等级。

这种依赖关系原本是隐性的，这正是问题所在。没有人把内容拦截器和端点检测响应（EDR）代理并列写进管控矩阵，所以能力退化时不会有任何一格指标变红，防护只是在你以为已被充分覆盖的机器上悄悄变薄。

为什么浏览器厂商不能直接说“不”？

因为脱离共享引擎单干，代价高昂，而且会越滚越大。要在一个持续删除你所依赖能力的上游代码库之上独立维护一套遗留扩展平台，就意味着不断为一份渐行渐远的分支打补丁，每一次上游发版都会把差距再拉大一截。这也是为什么现在的“退路”措辞都异常谨慎。据Computerworld报道，Brave表示会在力所能及的范围内尽量保留部分与隐私相关的Manifest V2插件，Vivaldi则表示只要这些插件仍存在于Chromium之中就会予以保留。注意措辞：“力所能及”和“只要仍存在于Chromium之中”，两者都把决定权交还给了上游。

真正的例外只有一个，而它恰恰因为跳出了这套引擎垄断体系才得以成立。Firefox采用完全不同的扩展架构。Mozilla曾公开表示，其实现有意与Chrome分道扬镳：保留阻塞式webRequest，没有淘汰Manifest V2的计划，并将在可预见的未来持续支持这些插件。这项能力之所以能存活，恰恰是因为背后的引擎不姓谷歌。

Edge为什么最终完成了自己曾经称为“可选”的迁移？

早在2022年，微软就曾向开发者承诺Edge插件商店会走自己独立的Manifest V3时间表，同时参考Chromium的进度和开发者反馈，这话说得相当留有余地。但它2026年8月发布的最新公告读起来完全是另一种口气：Edge将在Canary、Dev、Beta渠道分阶段停用Manifest V2，随后推进到Stable版；面向普通用户的停用定在2026年末，企业端的淘汰则从2027年初启动。这些都是微软自己公布、自己制定的时间表。

一家坐拥数十亿营收、拥有自有应用商店、并且明确保留过“可以不同”权利的公司，最终还是选择了跟随迁移。如果最有条件走自己路线的厂商都不再坚持差异化，那就说明：与上游引擎保持兼容，如今在产品路线图上权重已经压过了用户防护。

技术战略团队该做什么

把这当作一个平台依赖问题来处理。如果浏览器内容拦截在贵组织的安全体系中实际承担着防护职能，就应当把它正式写入管控清单，这样CNAME伪装解除失效或规则集被冻结更新时，暴露出的是一个真实的缺口，而不是被无声地忽略。诚实地为“临时改用坚持保留旧版的浏览器”这条退路定价，因为“力所能及”本质上是一个由别人掌握的到期日。并且有意识地判断，在哪些环节上架构上的多样性真正值得付出维护成本，毕竟目前唯一同时保留阻塞式webRequest和响应体过滤能力的浏览器，正是那个选择跳出引擎垄断体系的浏览器。这正是我们在技术战略项目中，以及在更广泛的平台依赖议题上一贯坚持的判断标准。

这一切都不需要假设谷歌是刻意设计Manifest V3来损害企业安全团队的利益，该公司自己也将这项变更归因于安全与性能考量。问题的关键在于结构，而不在动机。当你把组织标准化部署在一个共享引擎之上时，你实际上把部分端点策略的决定权，让渡给了这个引擎的维护者，而维护者首先要向自己的损益表负责。无论这些取舍最初是否针对你，你都得照单全收。

常见问题

Manifest V3迁移之后，uBlock Origin还能用吗？

完整版uBlock Origin依赖的正是Manifest V3移除的阻塞式webRequest API，因此无法原样保留。精简版uBlock Origin Lite改用declarativeNetRequest，按预先声明的规则表过滤，而不是靠代码实时检查每个请求。应当把这次迁移理解为过滤模型的根本转变，而不是简单换皮：CNAME伪装解除和HTML响应过滤都不会随之保留。

Firefox是内容拦截插件的可靠退路吗？

Mozilla已承诺保留阻塞式webRequest，并将在可预见的未来继续支持Manifest V2插件，原因是Firefox采用了不同的引擎和架构。这使它成为目前唯一的例外，不过任何押注单一厂商的做法，都值得单独制定应急预案。

企业应该推迟部署Manifest V3来争取时间吗？

推迟只能换来几周喘息，换不来一套战略。Chromium系浏览器提供的退路都明确是临时性的，更有价值的做法是先厘清浏览器内容拦截在贵组织安全体系中究竟承担了哪些职能，并为这项能力终将改变做好准备，而不是假设某个坚持到底的浏览器会一直存在下去。