Chrome 浏览器开发者 停止支持 webRequest API 的阻止操作模式，该模式允许您动态更改接收到的内容，并在插件中积极使用来阻止广告，
防止恶意软件、网络钓鱼、监视用户活动、家长控制和隐私。
谷歌的动机：
- API阻塞模式 导致资源消耗高。
使用此 API 时，浏览器首先向插件发送网络请求中包含的所有数据，插件对其进行分析并返回修改后的版本，以便在浏览器中进一步处理或发出阻止指令。 在这种情况下，主要延迟不是出现在附加组件处理流量的阶段，而是由于协调附加组件执行的开销成本而出现。 特别是，此类操作需要启动单独的进程来补充，以及使用IPC与此进程交互以及数据序列化机制； - 该插件完全控制低水平的所有流量，这为滥用和侵犯隐私提供了巨大的机会。 根据 Google 统计，在所有检测到的恶意加载项中，42% 使用了 webRequest API。 值得注意的是，Chrome Web Store 目录中每月平均会阻止 1800 个恶意加载项的尝试。 不幸的是，审查不允许我们无一例外地捕获所有恶意加载项，因此为了增强保护，决定在 API 级别限制加载项。 主要思想是为附加组件提供不访问所有流量的访问权限，而仅访问实现预期功能所需的数据。 特别是，要阻止内容，无需授予附加组件对所有机密用户数据的完全访问权限；
- 提议的替换声明式 API 负责高性能内容过滤的所有工作，只需要加载过滤规则的插件。 插件不会干扰流量，用户的私人数据不受侵犯；
- Google 考虑到了许多关于 declarativeNetRequest API 缺乏功能的评论，将过滤规则的数量限制从最初提议的每个扩展 30 万条扩大到全局最大 150 万条，并且还增加了动态过滤规则的能力。更改和添加规则，删除和替换 HTTP 标头（Referer、Cookie、Set-Cookie）和请求参数；
- 对于企业来说，可以使用 webRequest API 的阻塞操作模式，因为使用附加组件的策略是由了解基础设施特性并意识到风险的管理员确定的。 例如，指定的API可以在企业中用于记录员工流量并与内部系统集成；
- 谷歌的目标不是破坏或压制广告拦截插件，而是能够创建更安全、更强大的广告拦截器；
- 不愿放弃 webRequest API 的阻塞操作模式以及新的 declarativeNetRequest 的原因是希望限制附加组件对机密数据的访问。 如果您保留 webRequest API 不变，大多数插件将不会使用更安全的 declarativeNetRequest，因为在安全性和功能性之间进行选择时，大多数开发人员通常会选择功能性。
:
- 由附加开发人员进行 显示对广告拦截插件的性能总体影响并不显着（在测试期间，比较了各种插件的性能，但没有考虑在拦截模式下协调处理程序执行的额外进程的开销网络请求 API）；
- 完全停止支持附加组件中积极使用的 API 是不切实际的。 您可以添加单独的权限并严格控制其在附加组件中使用的充分性，而不是删除它，这将使许多流行附加组件的作者免于完全重新设计其产品并避免削减功能；
- 为了减少开销成本，不能删除该API，而是基于Promise机制重新制作，类似于Firefox中webRequest的实现；
- 提议的替代方案 declarativeNetRequest 并不能满足插件开发人员对广告拦截和安全/隐私的所有需求，因为它不提供对网络请求的完全控制，不允许使用自定义过滤算法，并且不允许根据条件使用相互重叠的复杂规则；
- 根据 declarativeNetRequest API 的当前状态，不可能在不改变的情况下重新创建 uBlock Origin 和 uMatrix 附加组件的现有功能，并且也使得进一步开发 Chrome 的 NoScript 端口变得毫无意义；
- 对隐私的担忧是牵强的，因为 webRequest API 的只读、非阻塞模式仍然存在，仍然允许恶意插件控制所有流量，但不提供在网络上干扰它的能力。飞行（更改内容、放置广告、运行矿工并分析输入表单的内容，可以在页面加载完成后使用）；
- 浏览器开发者 , и ，基于 Chromium 引擎构建，打算在其产品中保留对 webRequest 阻塞模式的支持。
来源： opennet.ru