主持人 > 博客 > 網絡新聞 > Google 證明限制廣告攔截器使用的 webRequest API 是合理的
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,因為在安全性和功能性之間進行選擇時,大多數開發人員通常會選擇功能性。