Google 證明限制廣告攔截器使用的 webRequest API 是合理的

Chrome 瀏覽器開發者 嘗試過 證明合法 停止支援 webRequest API 的封鎖操作模式，該模式可讓您動態變更接收的內容，並在外掛程式中積極使用來封鎖廣告，
防止惡意軟體、網路釣魚、監視使用者活動、家長監護和隱私。

Google的動機：

• 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 的唯讀、非阻塞模式仍然存在，仍然允許惡意插件控制所有流量，但不提供在網路上乾擾它的能力。飛行（更改內容、放置廣告、運行礦工並分析輸入表單的內容，可以在頁面載入完成後使用）；
• 瀏覽器開發者 勇敢, Opera и 維瓦爾第，基於 Chromium 引擎構建，打算在其產品中保留對 webRequest 阻塞模式的支援。

來源： opennet.ru