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。
雷蒙德表示，Google的策略是在擴大Chrome用戶群與使用內容攔截器造成的業務損失之間確定最佳平衡點。 在 Chrome 擴充的第一階段，Google被迫忍受廣告攔截器作為最受用戶歡迎的插件之一。 但在 Chrome 獲得主導地位後，該公司試圖透過推廣來扭轉局面，並獲得對屏蔽的控制權。 將不適當的廣告攔截功能整合到 Chrome 中。 webRequest API 無法實現這一目的，因為對內容攔截的控制目前掌握在第三方廣告攔截器開發人員手中。
來源： opennet.ru