Chrome删除Manifest V2扩展的真实时间线早已发生,8月31日只是商店清理。深入解析Manifest V3的三大变革、背后的安全考量,以及对广告拦截工具的真实影响。
Chrome删除Manifest V2扩展的倒计时又出现在了各大科技网站的头条位置。8月31日这一天被渲染成一个分水岭,仿佛浏览器里的一切都会在这一天轰然倒塌。然而事实远比这些耸人听闻的标题要平淡得多。真正决定性的时刻早在一年多以前就已经悄然发生,如今的8月31日不过是Chrome网上应用商店的一次数据库清理罢了。理解这一点,需要回溯Manifest V2退场的完整时间线,看清每一步究竟抽走了什么、留下了什么。 Manifest V2是Chrome扩展的原始格式,从2012年起服役了超过十年。
它的继任者Manifest V3在2021年1月19日进入稳定版Chrome,但谷歌花了整整四年时间才把所有能让旧格式继续运行的后门一一封死。这个过程像是一道逐渐收紧的闸门,每一步都移除了不同的逃生通道。 2024年6月3日是首个预警信号,但只对开发者和早期采用者可见。Chrome的Beta、Dev和Canary渠道在扩展页面上为Manifest V2扩展添加了警告横幅,这些扩展在商店里也失去了"精选"徽章。当时如果你使用稳定版Chrome - - 也就是几乎所有人 - - 你什么都看不到。属于你的时刻要等到十月份才会到来。
2024年10月9日,事情开始真正咬人了。Chrome开始在稳定版渠道逐步禁用Manifest V2扩展。如果你的扩展被关掉了,那时候还能手动把它再打开。 2025年3月31日,"关闭"变成了所有渠道的默认状态。Manifest V2扩展在每个渠道上都被默认禁用,尽管用户仍然可以手动重新启用。企业在这一刻获得了一个宽限:一项名为ExtensionManifestV2Availability的管理策略让Manifest V2在受管机器上继续运行,这一宽限期被延长到了2025年6月。
但真正的分水岭是2025年7月24日发布的Chrome 138。从这一天起,Manifest V2对所有渠道的所有用户都被禁用,手动重新启用的开关也消失了。你再也无法把那些旧扩展打开。Chrome 138也是最后一个能够运行Manifest V2扩展的Chrome版本,而且即便如此,也只能通过那项企业策略实现。 紧接着的Chrome 139删除了那项企业策略。最后一扇门就此关闭。
从Chrome 139起,没有任何受支持的方式 - - 没有开关、没有标记、没有管理覆盖 - - 可以在Chrome上运行Manifest V2扩展。这一变化同时降临在每一个Chrome 139用户头上。 到了Chrome 150和151,即2026年的6月和7月,最后的尘埃也被扫净。Chrome 150移除了kExtensionManifestV2Disabled功能标志,谷歌的提交说明称其为死代码。Chrome 151大约在7月28日进入稳定版,它带走了剩余的东西:那个能让Manifest V2在开发构建中复活的功能开关,以及那个允许开发者模式加载未打包Manifest V2扩展的命令行参数。 重读这份时间线,注意真正的转折点在哪里。
所有关键节点都发生在2024年10月到2025年中的Chrome 139之间。等到你读到这篇文章的时候,Manifest V2在普通Chrome上已经死去了整整一年。 那么8月31日究竟发生了什么?Chrome网上应用商店删除了剩余的Manifest V2条目。仅此而已。谷歌的时间表说得很清楚:剩余的Manifest V2扩展从商店中下架,任何仍然安装在Chrome 138或更早版本上的扩展"将保持安装状态,但无法接收任何更新,并且一旦从Chrome网上应用商店下架就无法重新安装"。 这带来两个后果,都不是那些耸动标题所承诺的。
第一个是你再也无法获取那些扩展了。不能安装、不能重装、不能更新。第二个后果更加微妙,值得仔细体会。8月31日你正在运行的浏览器里不会发生任何变化,因为在当前版本的Chrome上,受影响的扩展早已无法运行。商店下架不是一个终止开关;终止开关在Chrome 138和139就已经触发了。这是谷歌在牛奶已经变质之后收拾货架。
那些死掉的Manifest V2条目仍然可能显示着数十万的"用户"数量,这些数字被引用起来仿佛有那么多人即将在8月31日失去什么。但这些计数中的大部分是困在Chrome 138及更早版本上的安装、因为企业管理策略而停留在旧版的机器,以及运行自己时间表的非谷歌Chromium分支。在最新的Chrome上,那个扩展自去年夏天起就没有执行过一行代码。 8月31日故事的诚实版本毫不戏剧性:一个条目被删除,少数使用旧版或不寻常浏览器的用户失去了重装某个对其他所有人来说早已失效的东西的能力,而我们其余的人根本不会注意到。这不是个好倒计时。 你几乎不需要做任何检查。
实际的测试就是那个我反复强调的标准:如果你的扩展在运行,它们就是V3,你已经完成了。Manifest V2无法在你的Chrome上运行,所以"它在运行"本身就是证明。 如果你还是想看一眼,打开chrome://extensions。Chrome会为你标记出那些死掉的扩展。Manifest V2的遗留物会显示为灰色、开关被关闭,通常附带一条说明它不再受支持的消息,以及一个让你删除它的小垃圾桶提示。其他所有已启用且正常工作的扩展,都是Manifest V3。
没有隐藏的Manifest V2在悄悄运行;"悄悄运行"恰恰是Chrome 138让之成为不可能的事情。 现在到了让这篇文章区别于新闻简报的部分。Manifest V3不是表面文章。谷歌重建了三个具体的机制,每一个都用某种能力换取了一项谷歌想要的特性。我认为其中两项交换是明确站得住脚的,而一项确实存在争议。让我公平地逐一说明,因为互联网基本上已经选好了阵营并且停止了阅读。
在Manifest V2下,扩展可以在运行时从服务器获取代码并执行。后台页面可以拉取一个脚本然后执行它,或者注入一个远程的script标签,突然开始运行从未进入谷歌审核包中的逻辑。这种模式完全被Manifest V3禁止。所有可执行逻辑都必须随经过审核的扩展包一起发布。Manifest V2默认情况下就已经阻止了eval和远程脚本,但它允许开发者放宽内容安全策略来允许它们。V3移除了这个安全阀:没有任何受支持的方式可以把策略弱化回运行时获取代码的状态。
从用户角度来看,这一点很难反驳。在Manifest V2下,谷歌审核的东西和在你浏览器里运行的东西可能是两个不同的程序。一个扩展可以以一个整洁的小工具的身份通过审核,然后一周后回连服务器变成一个键盘记录器,而本应保护你的审核覆盖的是一个早已不存在的版本。禁止远程代码意味着被审核的工件和运行的工件是同一个工件。这是一个真实的安全胜利,也是我会毫不犹豫捍卫的改变。 代价虽然有限但确实存在:一些合法的模式 - - 某些A/B测试框架、携带行为而非仅仅数据的远程功能标志、无需经过商店往返的快速热修复 - - 都被迫在包内重建。
对开发者来说很烦人。对用户来说是好事。我接受这个交换。 这是人们真正愤怒的地方,他们愤怒得并不全无道理。 Manifest V2给了扩展一个阻塞版本的webRequest API。它允许扩展注册一个监听器,Chrome会为浏览器发出的每一个网络请求调用它,把详细信息交给它,然后等待扩展自己的JavaScript在那一刻决定是允许、阻止还是重写这个请求。
这赋予了扩展巨大的权力,也赋予了它巨大的可见性:为了做出这个决定,扩展能够看到你请求的每一个URL,用它完全控制的代码。 Manifest V3用declarativeNetRequest取代了它。扩展不是对每个请求运行你的代码,而是提前声明它的规则,然后浏览器自己的网络栈来强制执行这些规则。区别就是整个争论的核心。有了declarativeNetRequest,扩展永远看不到你的流量。它交给Chrome一本规则书,Chrome执行屏蔽,扩展被排除在循环之外。
谷歌的理由是隐私加上性能:你的广告拦截器不再能够逐个请求地读取你整个浏览历史,也没有扩展JavaScript坐在每个网络调用的热路径上。这些都是真的,对于中位数扩展来说这是一次干净的升级。 代价是声明式规则无法表达代码所能表达的一切。declarativeNetRequest限制了你能够发布的规则数量:保证至少30000条静态规则、多达30000条动态规则和5000条会话规则。谷歌已经多次提高这些预算。安全动态规则上限在Chrome 121中从5000跃升到了30000。
但数量从来不是真正的天花板。声明式规则不能做出依赖于响应实际内容的决策,也不能像真正的代码那样串联逻辑。动态的、情境化的、"看着这个然后决定"的拦截正是高级工具的全部意义,而规则书模式无法复现其全部功能。这正是重型内容拦截器被削弱的原因,反弹是应得的。 那些真正愤怒的人值得被公平地倾听,而不是被轻蔑对待。承认谷歌的隐私论点完全成立。
但有一点仍然真实:declarativeNetRequest的表达能力严格弱于阻塞式webRequest,再多的善意也无法弥合这个差距。而且这底下还坐着一个尴尬的观感问题:告诉你广告拦截器必须变弱、"是为了你好"的公司,恰好是那家卖广告的公司。你可以相信隐私收益是真实的,也可以相信同样的收益本可以用更小的附带损害来实现 - - 一项更严格的权限、针对受信拦截器的审计路径、一个更窄的API而非一个更钝的API。 第三个变化是开发者抱怨最多而用户最少注意到的。Manifest V2扩展有一个持久的后台页面:一个隐藏的页面,在扩展启动时加载,在整个浏览器会话期间保持驻留,用普通变量持有它喜欢的任何状态。Manifest V3把它换成了服务工作者。
服务工作者是事件驱动且短暂的:Chrome启动它来处理一个事件,让它进入空闲,然后在大约30秒不活动后终止它。 摩擦在于"你的后台上下文可能随时被杀"迫使了一次真正的重写。你放在全局变量里的任何状态在工作者卸载时都会蒸发。监听器必须在顶层同步注册,否则唤醒工作者的那个事件就会被错过。任何超过空闲窗口的setTimeout都是一个陷阱,因为计时器会随工作者一起消亡;你得改用chrome.alarms。这些都不是什么稀奇古怪的东西,但都是不同的东西,并且十年的Manifest V2代码和教程都假设相反的情况。
这是大多数人在搜索框里真正输入的问题,所以这里给出直接答案:你心目中的那个uBlock Origin - - Raymond Hill的原作,那个建立在阻塞式webRequest之上的 - - 不再在Chrome上运行。它在2025年中期和所有其他Manifest V2扩展一起熄灭了。在Chrome上,那个特定的东西已经结束了。 但"消失"有点言过其实。Hill(网名gorhill)构建了一个名为uBlock Origin Lite的Manifest V3版本,简称uBOL。它使用declarativeNetRequest,在构建时将过滤列表预编译为静态规则集。
对于大多数人、多数网站来说,它能拦截大多数广告,并且比原作占用更少的资源。 它在设计上确实能力较弱,gorhill也从未假装不是这样。因为uBOL依赖静态规则而非实时代码,它无法做到完整版本所擅长的动态的、逐站的、"观察页面行为并做出反应"的过滤。它的元素过滤功能(隐藏残余空广告框和页面装饰的部分)更为有限,并且在gorhill通过商店审核队列发布新的规则集并由你更新之前,它无法适应新的反广告拦截技巧。对于普通用户来说,uBOL足够了。对于那些因为需要高级旋钮而运行完整uBlock Origin的人来说,"够用"是一种降级,把uBOL说成是即插即用的替代品是不诚实的。
完整的uBlock Origin并未灭绝。它只是不再住在Chrome上。Firefox保留了阻塞式webRequest API,所以完整的、未删节的uBlock Origin今天仍然在那里运行。Brave走了一条完全不同的路:它的广告和跟踪拦截是原生构建在浏览器中的,而不是作为扩展发布的,所以Manifest V3对扩展的规则根本不适用于它:请求在Brave自己的网络栈深处由Rust引擎过滤,完全不受这一切影响。 对于你,作为一个只想让自己的浏览器正常工作的人:基本上什么都不需要做。你的扩展是V3的,否则它们无法运行。
8月31日删除的是你从未访问过的一些商店条目。互联网的倒计时器正在倒数到一次数据库删除。 唯一真正实际要做的事情是为未来做准备,而不是救火。如果在你的世界里仍有一个Manifest V2扩展在某个地方苟延残喘(团队从未更新的旧机器、被锁死的工作笔记本、有自己规则的Chromium分支),要知道一旦条目下架,那个扩展就无法在新设备上重装或迁移。所以如果你依赖某个扩展,现在就去找它的V3继任者,趁你还能在商店里搜索到它。8月31日之后,线索就断了。
关于其他浏览器:Edge、Brave、Opera以及其余的都是Chromium内核,所以它们都继承了Manifest V3平台,并最终会到达同一个地方。但它们设定自己的时钟。Brave如上所述是原生拦截,大体上绕过了扩展API的戏剧性。微软独立设定了Edge的Manifest V2时间表而非镜像Chrome的日期。不同的时钟,同样的目的地。 这个故事从来不是关于8月31日的。
这是谷歌所做的四年交换:一些具体的用户权力 - - 主要在运行严肃内容拦截器的人手中 - - 换取了一个平台,在这个平台上,经过审核的扩展不能秘密地重写自己、不能读取你所有的流量、不能在后台空闲着吃内存。这三件事中有两件是我会向任何人捍卫的胜利。第三件让真实的人失去了真实的工具,而谷歌对此最干净的隐私论点尴尬地来自地球上最大的广告公司。同时持有这两者。倒计时器做不到。 Firefox是持久的答案 - - Mozilla已经承诺同时保留Manifest V2和阻塞式webRequest API,这也是为什么完整的uBlock Origin能够未经修改地在那里运行。
。
