Tag: webrequest

其他用 Chromium 核心的瀏覽器不打算跟進 webRequest 的修改

先前提到的「所以 Google 要對 ad blocker 全面宣戰了...」，現在朝著幾個方向在發展：一個是寄託在反托拉斯法的部份，另外一個是市場的替代方案。

Firefox 算是常被提出來的替代方案，但 Firefox 的流暢度比 Chromium 差了一大截，所以目前主要的替代方案應該還是在各家使用 Chromium 核心的瀏覽器身上。

ZDNet 詢問了這些瀏覽器的人，大多數都表態會維持 webRequest 的原來運作：「Opera, Brave, Vivaldi to ignore Chrome's anti-ad-blocker changes, despite shared codebase」。

目前只剩下剛換到 Chromium 核心的 Microsoft Edge 還沒有回應 ZDNet。

先繼續看看吧...

所以 Google 要對 ad blocker 全面宣戰了...

一月的時候 Google 就提出了「Manifest V3」，打算閹掉 extension 透過 webRequest 攔截連線的能力，而這個功能就是 uBlock Origin 這類 ad blocker 的基礎。

當時 Google 宣稱 webRequest 嚴重影響瀏覽器效能，但 Ghostery 的團隊則做了實驗證明影響極小：「Ad blocker performance study in response to Manifest V3 finds that Ghostery's ad blocker beats the competition」、「Google遭證據打臉，廣告封鎖程式幾乎不影響Chrome效能」。

All content-blockers except DuckDuckGo have sub-millisecond median decision time per request.

另外在 Alphabet (Google 母公司) 遞交給美國證管會的資料 (FORM 10-K) 可以看到他們把 ad blocker 視為威脅：「goog10-kq42018.htm」。

New and existing technologies could affect our ability to customize ads and/or could block ads online, which would harm our business.

Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.

所以後續的行為就很清楚了，他們決定 Manifest V3 還是會閹掉 webRequest (以有效抑制 ad blocker 的能力，反正繼續堅持效能問題，當作沒聽到)，只開放企業版本使用：「Google to restrict modern ad blocking Chrome extensions to enterprise users」。

在 Mozilla 愈來愈不成氣候的情況下，現在要看的戲應該是 Google 是否會因此受到 anti-trust 的挑戰呢...

Chrome 的 webRequest...

在變成標準前又改了一次...

從 Google Chrome 17 後，「Web Requests」從 Experimental API 變成正式的 API，有不少地方在這次轉成正式 API 後需要修改：

  • 本來 chrome.experimental.webRequest 都改成 chrome.webRequest。
  • 需要加上 webRequest permission，如果有 blocking 行為則要再加上 webRequestBlocking permission。
  • API 呼叫的參數可能會不一樣，參考官方的文件的說明比較清楚。我遇到的是使用 onBeforeRequest.addListener 時需要多加上 urls 參數。
  • 不再需要 expiermental permission，不過沒拿掉不影響運作。

在 Chrome Web Store 上面已經可以看到一些跟控制 Referrer 有關的延伸套件了...