重新构想 uMatrix：将细粒度请求控制引入 Manifest V3

对于高级用户和隐私爱好者来说，已废弃的 uMatrix 扩展不仅仅是一个工具；它是浏览器的指挥中心。由 Raymond Hill（uBlock Origin 的开发者）创建，uMatrix 提供了直观的矩阵式界面来控制站点权限和子资源请求。它让用户能够精确限制第三方可以提供的内容——脚本、框架、字体和视频——将繁琐的手动过程转化为可管理的工作流。

虽然 uBlock Origin（uBO）吸收了其中许多功能，但向 Chrome 的 Manifest V3（MV3）过渡却留下了空白。符合 MV3 的继任者 uBO Lite 缺乏使 uMatrix 不可或缺的细粒度控制。这促使 Tavis Ormandy 探索在新扩展架构的限制下，是否仍有可能实现类似 uMatrix 的体验。

技术挑战：MV2 与 MV3

复制 uMatrix 的主要障碍在于从 Manifest V2 向 Manifest V3 的转变。在 MV2 中，扩展可以使用“阻塞”网络请求，通过执行 JavaScript 回调实时决定是否允许或阻止请求。

MV3 移除了此功能。相反，扩展必须使用 declarativeNetRequest API。这意味着扩展无法对每个请求运行逻辑；必须预先声明一套规则，由浏览器执行。虽然批评者认为这削弱了广告拦截器和隐私工具的能力，Ormandy 认为对于 uMatrix 替代品的特定使用场景，这些规则足够灵活，实用性仍然可行。

matrix³ 的提议架构

为了恢复 uMatrix 的细粒度控制，Ormandy 提出了一个利用现有 Web 标准而非与浏览器新限制抗争的设计。该策略包括两个主要组件：

1. 利用内容安全策略（Content Security Policy，CSP）

与其尝试通过 declarativeNetRequest 规则管理每个请求，不如使用该 API 注入自定义的 Content-Security-Policy（CSP）头。CSP 是浏览器原生机制，用于控制可以加载哪些资源以及从何处加载。通过将实际阻塞工作交给浏览器自身的 CSP 引擎，扩展仅充当这些策略的管理界面。

2. 通过 report-to 自动发现

uMatrix 最佳的功能之一是能够向用户准确展示站点尝试加载的子资源，让他们即时批准或拒绝。为在 MV3 中复现此功能，Ormandy 建议使用 CSP 中的 report-to 指令。

当发生 CSP 违规时，浏览器可以被指示向特定端点发送报告。通过使用 declarativeNetRequest 拦截这些报告，扩展能够实时填充被阻止资源的列表。这形成了一个反馈回路：浏览器阻止请求，报告违规，扩展向用户展示该违规以便可能的“允许”规则。

当前状态：matrix³

该概念框架已产生一个名为 matrix³ 的概念验证。虽然目前仍处于原型阶段，用户体验简陋，但它证明了在 Manifest V3 下“阻止 $\rightarrow$ 报告 $\rightarrow$ 用户决定 $\rightarrow$ 允许”的核心循环是可行的。

社区观点与替代方案

围绕该项目的讨论凸显了浏览器生态系统中更深层的紧张关系。许多用户认为，这类变通方案的需求直接源于 Google 推动 MV3，以限制广告拦截器的有效性。

替代路径

多位社区成员指出了对功能不妥协的用户的替代方案：

• Firefox: 由于 Firefox 并未采用与 Chrome 相同的 MV3 限制方式，uBlock Origin 在其上仍能完整运行。其他人建议使用 nuMatrix 作为 Firefox 用户的现代替代方案。
• Brave: 有用户指出 Brave 已明确宣布支持类似 uMatrix 的功能。
• Chrome Flags: 对于坚持使用 Chrome 的用户，有人建议使用命令行标志（例如 --disable-features=ExtensionManifestV2Unsupported）暂时保留 MV2 扩展，尽管这是一种脆弱的解决方案。

“用户代理”哲学

除了技术实现之外，讨论还涉及了浏览器作为“用户代理”的哲学。批评者认为现代浏览器缺乏原生的细粒度请求控制是一种系统性失误。正如一位评论者所指出的：

“类似 uMatrix 的功能应该直接内置于浏览器……它是唯一绝对必需的扩展……能够在点击按钮的瞬间看到大多数站点想要加载的各种垃圾，真是大开眼界。”

当这些控制被迁移到扩展中——随后又通过 MV3 对这些扩展进行限制——浏览器不再充当用户的代理，而是成为网络广告生态系统的守门人。