今回のニュース内容は「Google Chromeの広告ブロック対策に関する大規模なアップデートと、それに関連する回避策、そしてそれが修正されたというニュース」
出典:Google Chromeの大規模な広告ブロック対策アップデートの回避策を見つけた方法、ただし今は修正済み
Google Chromeは、拡張機能の仕様をManifest V2(MV2)からManifest V3(MV3)へと移行しました。この移行に伴い、拡張機能がウェブサイトへのリクエストを動的にブロックする「webRequestBlocking」というAPIが利用できなくなりました。多くの広告ブロッカーはこのWebRequestBlockingに依存していたため、MV3への移行は広告ブロッカーに大きな影響を与えるとされていましたが、Derin Eryılmaz氏が、このMV3の制約を回避してwebRequestBlockingを有効にできるバグを2023年に発見したと報告しています。
ニュースサイト https://gigazine.net/news/20250714-chrome-webrequestblocking-bag/
これは主にGoogleの新しい拡張機能プラットフォームである「Manifest V3 (MV3)」への移行に関連するものです。
Manifest V3 (MV3)とは何か、そして広告ブロックへの影響
Googleは、Chromeの拡張機能のセキュリティ、プライバシー、パフォーマンスを向上させることを目的として、拡張機能の仕様をManifest V2からManifest V3へ移行を進めています。このMV3への移行が、特に広告ブロッカーに大きな影響を与えるとされています。
主な変更点と広告ブロックへの影響:
webRequest
APIの制限(特にブロッキング機能の削除):- Manifest V2: 広告ブロッカーは、
webRequest
APIの「ブロッキング」機能を使用して、ネットワークリクエストがブラウザに到達する前にリアルタイムで傍受し、広告関連のリクエストをブロックしたり変更したりすることができました。これにより、非常に効率的で柔軟な広告ブロックが可能でした。 - Manifest V3: MV3では、この
webRequest
APIの「ブロッキング」機能が廃止され、代わりにdeclarativeNetRequest
APIが導入されました。declarativeNetRequest
APIは、拡張機能が事前に定義されたルールセットに基づいてネットワークリクエストをブロックまたは変更することを許可します。- しかし、このAPIにはいくつかの制限があります。
- ルール数の制限: ブロックできるルールの数に上限があります。大規模な広告ブロックリスト(例えば、uBlock Originが使用するような膨大なフィルターリスト)をすべてこのAPIで処理することは困難になります。
- 動的なブロックの制限: 拡張機能がリアルタイムで新しい広告パターンを識別してブロックする柔軟性が低下します。これは、広告の表示方法が日々進化する中で、新しい広告を迅速にブロックすることが難しくなることを意味します。
- プライバシーの懸念: Googleは、
webRequest
APIのブロッキング機能が、一部の悪意のある拡張機能によってユーザーの閲覧履歴を監視するために悪用される可能性があると主張しています。しかし、広告ブロッカーのコミュニティやプライバシー擁護団体からは、Googleが広告収入に依存しているため、広告ブロック機能を意図的に弱体化させようとしているという批判があります。
- Manifest V2: 広告ブロッカーは、
- リモートでホストされるコードの禁止:
- MV3では、拡張機能がリモートサーバーからコードをダウンロードして実行することが禁止されます。これはセキュリティ上のメリットがある一方で、広告ブロッカーがフィルタールールを動的に更新したり、新しい広告パターンに素早く対応したりする能力を制限する可能性があります。拡張機能の更新にはChromeウェブストアの審査が必要になるため、迅速な対応が難しくなります。
発見された回避策とその修正
ご質問の「回避策が見つかった方法、ただし今は修正済み」という点についてですが、これは主にManifest V3の厳格なポリシーやAPIの制限を迂回しようとする様々な試みと、それに対するGoogle側の修正を指していると思われます。具体的な技術的詳細が一般に公開されていないケースも多いですが、いくつか考えられるシナリオがあります。
- Content Security Policy (CSP)の迂回: MV3では、拡張機能が注入するスクリプトにも厳格なCSPが適用されます。しかし、初期のMV3では、特定の条件下でこのCSPを迂回して、より広範なスクリプトインジェクションが可能であったり、リモートコードの実行につながる脆弱性があったりするケースが報告されていました。広告ブロッカーはページコンテンツを変更したり、スクリプトを注入したりすることもあるため、このような抜け穴が一時的に利用された可能性があります。Googleはセキュリティ上の理由から、これらの抜け穴を随時修正しています。
- APIの解釈や実装の差異: 新しいAPI(
declarativeNetRequest
など)の初期実装において、開発者が意図しない動作や、より強力なブロックを可能にする「抜け穴」が見つかることがあります。広告ブロッカーの開発者は、これらのAPIの限界を押し広げようと試み、一時的にGoogleの意図した制限を回避する方法を見つけることがあります。Googleはこれらを「バグ」と見なし、パッチを適用して修正していきます。 - タイミングの問題: 例えば、特定のスクリプトがWebページのDOMが完全にロードされる前に実行されることで、広告が表示される前にブロックする、といったタイミング的な脆弱性が一時的に利用された可能性も考えられます。
これらの回避策は、GoogleがMV3の目標(セキュリティ、プライバシー、パフォーマンスの向上)を達成するために、意図せず生じてしまった「抜け穴」であると判断され、最終的には修正される運命にありました。Googleは、Chromeのアップデートやウェブストアの審査プロセスを通じて、これらの抜け穴を塞いできました。
現在の状況と今後の展望
現在、Manifest V3への移行は段階的に進められており、最終的にはManifest V2の拡張機能はサポートされなくなります(2025年6月以降とされていますが、これは変動する可能性があります)。これにより、主要な広告ブロッカーはMV3の制限に従う必要があり、その結果、一部の機能が低下したり、広告ブロックの精度が落ちたりする可能性が指摘されています。
多くの広告ブロッカー開発者は、MV3の制限内で最大限のパフォーマンスを発揮できるよう、既存の拡張機能をMV3に準拠させるための作業を行っています。しかし、その一方で、Firefoxなどの他のブラウザは、より柔軟なAPI(特にwebRequest
APIのブロッキング機能)のサポートを継続する方針を示しており、ユーザーにとってはブラウザの選択がより重要になるかもしれません。
この一連の動きは、ウェブエコシステムにおける広告とプライバシー、そしてユーザーエクスペリエンスのバランスについて、継続的な議論を巻き起こしています。