对于许多用户来说，浏览器是他们数字世界的中心。它显示网站并且通常还显示广告。广告拦截器是为容易分心或担心通过广告感染恶意软件的用户提供的解决方案。自从几年前关于广告拦截器的大辩论以来，我就没有使用过拦截扩展程序。到目前为止，它工作正常，没有任何损坏。
无论如何，这些广告拦截器通常作为 Google Chrome 扩展安装。 当前存在的变化风险可能会导致某些内容拦截器不再起作用。这是 uBlock Origin 的开发者 Raymond Hill 的解释，uBlock Origin 是一个非常流行的内容拦截扩展。
因此，Manifest V3 限制 webRequest API 来阻止内容，并允许使用 declarativeNetRequest API 来阻止内容。但是，该界面的功能仅限于 AdBlock Plus 使用的功能。这是一个非常简单的过滤过程，但是其他广告拦截器的过滤过程更加复杂，并且无法使用新接口来实现。
此更改尚未最终确定，但属于Manifest V3提案的一部分。不过，一旦达成协议，恐怕就没有回头路了。您可以仅阻止需要以特定方式查看的特定内容。检测不需要的内容的复杂算法变得不可能。
从 declarativeNetRequest API 的描述中，我们了解到其目的只是强制执行 Adblock Plus（“ABP”）兼容的过滤功能。它们共享相同的基本过滤语法。使用双竖线锚定主机名，使用单竖线锚定 URL 的开头或结尾，并使用插入符号作为特殊占位符。所描述的匹配算法正是像ABP这样的过滤引擎的匹配算法。
如果这个（相当有限的）声明性 NetRequest API 成为内容拦截器完成其使命的唯一方式，这本质上意味着我维护多年的两个内容拦截器 uBlock Origin (uBO”) 和 uMatrix 不再存在。
我们非常担心所提出的 declarativeNetRequest API 将阻止我们提出新的和创新的过滤引擎设计，因为不仅 uBO 和 uMatrix 无法存在，而且 declarativeNetRequest API 只是一种特定过滤的实现。 。这个引擎相当有限（30,000 的限制不足以仅应用著名的 EasyList）。
uBlock Origin 的主要部分和 uMatrix 的所有部分使用与 declarativeNetRequest API 不同的匹配算法。阻止/允许规则根据其特殊性进行应用，但阻止/允许规则可以无限制地相互覆盖。这无法转换为 declarativeNetRequest API（假设 30,000 个条目限制本身并不是一个重大限制）。
还有一些其他功能无法使用 declarativeNetRequest API 实现（据我所知，许多用户非常重视该功能）。例如，阻止大于设定大小的媒体元素、CSP 指令、删除传出 cookie 标头等 – 所有这些都可以配置为覆盖不太具体的设置。这意味着您可以选择在全球范围内阻止大型媒体元素，但在少数特定网站上允许它们。您还可以使用更具体的规则覆盖这些规则。
扩展代表用户工作并向*用户代理*添加功能。此外，通过弃用 webRequest API 的阻止功能，我们实质上降低了 Chromium 中的用户代理级别，这显然有利于愿意这样做的网站。关于页面可以获取/执行/渲染哪些资源的最终决定。
鉴于这种有限的声明性 NetRequest API 以及 webRequest API 的阻止功能的弃用，我怀疑“用户代理”是否仍然是对 Chromium 进行分类的合适类别。
如果按照建议进行设置，则可能意味着 Chrome 中某些内容拦截器的终止。顺便说一句，改变的原因确实是总是有扩展加载不应该加载的东西。但这是正确的方法吗？
