Simeon Vincent，负责与 Chrome 团队中的扩展开发人员互动（担任扩展开发倡导者职位）， Google 目前对第三版 Chrome 宣言的立场， 许多附加组件可以阻止不当内容并确保安全。 该公司并不打算放弃原来的计划，即停止支持 webRequest API 的阻止模式，该模式允许您即时更改接收到的内容。 仅 Chrome 企业版例外（），其中对 webRequest API 的支持将像以前一样保留。
对于常规 Chrome API 用户 将被限制为只读模式。 已提出使用声明式 API 来替换 webRequest API 以进行内容过滤 ，它仅涵盖现代广告拦截器中使用的功能的有限部分。 本质上，不是提供完全访问网络请求的专有处理程序，而是提供现成的通用内置过滤引擎来自行处理阻止规则。 例如，declarativeNetRequest API 不允许您使用自己的过滤算法，也不允许您创建根据条件相互重叠的复杂规则。
广告拦截插件开发者共同准备 ，其中列出了 declarativeNetRequest API 的缺点。 Google 同意许多评论并添加到 declarativeNetRequest API 中。 特别是，添加了对动态更改和添加规则的支持，并且可以删除 HTTP 标头，但仅限于白名单中的标头（Referer、Cookie、Set-Cookie）。 我们计划实现对添加和替换 HTTP 标头的支持（例如，Set-Cookie 替换和 CSP 指令）以及删除和替换请求参数的功能。
第三版清单的初步版本定义了向 Chrome 插件提供的功能和资源列表，计划在未来几个月内用于 Chrome Canary 实验版本的测试。
与此同时，禁止通过 webRequest API 更改接收内容的动机仍不完全清楚。 声称 webRequest API 的阻塞模式会对性能产生负面影响，因为浏览器会在渲染页面之前等待附加处理程序完成其工作，这一说法经不起批评。 之前进行过 广告拦截插件的性能表明，它们带来的延迟可以忽略不计。 平均而言，使用拦截器只会使请求的执行速度减慢几分之一毫秒，与整体背景相比，这可以忽略不计。
第二个论点与保护用户免受附加组件对内容不受控制的访问的愿望相关，看起来也没有说服力，因为不是删除合法附加组件中长期建立和广泛的功能，而是可以添加新的功能。权限类型，并为用户提供安装是否具有对网络请求的完全访问权限的附加组件的最终选择。 此外，Google 还保留了对以只读模式使用 webRequest API 的支持，允许在无需低级干预的情况下进行全面流量监控。
附加组件可以通过其他 API 更改加载的网页内容（例如，恶意附加组件仍然可以投放广告、启动挖矿程序并分析输入表单的内容）。
Raymond Hill 是用于阻止不需要的内容的 uBlock Origin 和 uMatrix 系统的作者，他的要求相当严格 谷歌代表的回应，暗示了煽动和幕后游戏，谷歌打着良好机会的幌子，试图推进其在互联网广告领域的商业利益，控制其过滤机制，并为自己辩护。这些行为都在公众的眼中。
他从未收到过令人信服的论据来证明需要停止在附加开发人员中广泛流行的 API。 根据 Raymond 的说法，性能下降并不是一个论据，因为页面加载缓慢是由于其膨胀，而不是由于在正确实现的附加组件中使用了 webRequest 阻塞模式。 如果 Google 真的关心性能，他们会基于该机制重新设计 webRequest ，类比 Firefox 中的 webRequest。
雷蒙德表示，谷歌的策略是在扩大Chrome用户群与使用内容拦截器造成的业务损失之间确定最佳平衡点。 在 Chrome 扩张的第一阶段，谷歌被迫忍受广告拦截器作为最受用户欢迎的插件之一。 但在 Chrome 获得主导地位后，该公司试图通过推广来扭转局面，并获得对屏蔽的控制权。 将不适当的广告拦截功能集成到 Chrome 中。 webRequest API 无法实现这一目的，因为对内容拦截的控制目前掌握在第三方广告拦截器开发人员手中。
来源： opennet.ru