Chromeの新ルールで広告ブロッカーが苦戦

分析来年、広告ブロッカーやその他のプライバシーツールなどの Chrome ブラウザ拡張機能は、Manifest v2 (MV2) と呼ばれる API に依存している場合は動作しなくなります。

これまでのところ、これらの拡張機能が Chrome の新しい Manifest v3 (MV3) API で動作するように書き直されると、結局はうまく動作しない不完全なソフトウェアになってしまう傾向があります。

MV2 の締め切りは 2023 年 1 月ですが、企業ポリシーにより 6 月まで使用できます。

Googleは2018年、Chromiumブラウザ拡張機能向けの改訂版API、すなわちMV3の開発に着手しました。これは、MV2拡張機能アーキテクチャがセキュリティ、プライバシー、パフォーマンスに及ぼす影響に対処するためです。Googleは、MV2アーキテクチャ下では、広告ブロッカーなどの拡張機能がブラウザで開いているページへのアクセスと制御を過度に強化していると考えています。これらのアドオンのいずれかが不正に機能した場合、ユーザーがページにアクセスした際に、ユーザーに関するあらゆる種類の機密データを収集する可能性があります。

後継の仕様である MV3 では、ページのリクエストを傍受して書き換える機能など、強力だが潜在的に悪用される可能性のある機能が削除されました。これは、トラッカー、マルウェア、広告などの望ましくないリクエストをブロックすることでプライバシーとセキュリティを保護しようとする拡張機能にとって便利な武器です。

プライバシーやコンテンツブロッキングの拡張機能を保守または作成している開発者は、新しいルールとAPIの下でコードがどのように動作するか、そもそも動作しないのかを再考する必要があることに気づきました。MV3は依然として流動的な目標ですが、具体化し始めて以来、プライバシーを重視する開発者や擁護団体は、Googleの表向きのプライバシー促進の取り組み（データアクセスの制限や権限の強制など）が、最終的にはプライバシーを促進する拡張機能に悪影響を及ぼすだろうと警告しています。

現在、人気のコンテンツ ブロッキング拡張機能のメーカーによる最近の 2 つの実験により、ブラウザー拡張機能の機能に関して、MV3 は進歩ではなく退化を表していることが確認されました。

最も評価の高いプライバシー拡張機能の一つであるuBlock Originの開発者であるレイモンド・ヒル氏は火曜日、MV3をベースにした実験版のソースコードを公開した。ヒル氏はこのバージョンを「uBO Minus」と呼んでおり、これは彼の期待の表れと言えるだろう。

uBO Minusは、declarativeNetRequestコンテンツをブロックするためにMV3のAPIを利用しています。この機能はwebRequest、JavaScriptイベントハンドラによるネットワークリクエストの変更を可能にし、不要なネットワークコンテンツの傍受の主なメカニズムとなっていたMV2のAPIに代わるものです。

Hill氏がコミットテキストで説明しているように、彼の拡張機能はdeclarativeNetRequestGoogleがMV3で掲げた目標である「データの読み取り／変更」権限を必要としないという目標に準拠しています。このアプローチにより、インストールされたコードが「すべてのウェブサイト上のすべてのデータの読み取りと変更」を実行できるというインストール警告が拡張機能のユーザーに表示されなくなります。これは恐ろしいように聞こえるかもしれませんが、アクセスしたすべてのウェブページをクリーンアップするアドオンを使用する場合、一般的には望ましいことです。

しかし、この「許可なし」のアプローチは、カスタム JavaScript インジェクションやリダイレクト、CSP (コンテンツ セキュリティ ポリシー) ディレクティブ、URL パラメータ、およびページの装飾要素のフィルタリングなど、uBlock Origin でサポートされている操作を拡張機能が実行できないことを意味します。

ヒル氏の結論は、広告大手のビジョンに固執すると、コンテンツブロッキング拡張機能の水準が下がるというものだ。彼は次のように記している。「現時点では、パーミッションレスであることが制限要因だと考えています。広範な「データの読み取り／変更」パーミッションを使用する場合、MV2ではなくMV3バージョンを使用する意味はあまりありません。広範な「データの読み取り／変更」パーミッションなしでは実装できない機能をすべて活用したいのであれば、MV2バージョンを使用すれば十分です。」

このアドバイスは、Manifest v2ベースの拡張機能がChromeで動作しなくなる1月以降は適用できなくなります。MV3を推奨しているMicrosoft Edgeも同様の対応を取る可能性が高いでしょう。Apple Safariはバージョン15.4でMV3のサポートを開始しましたが、MV2のサポートを中止するかどうかは明言していません。しかし、ブロッキング機能を持つWebRequest APIは数年前に削除しています。BraveやMozillaといった異端児は、MV2のサポートを継続する予定であると発表していますが、そのためにはある程度のリソースが必要になるでしょう。例えばBraveは、Chromeウェブストアが利用できなくなるため、独自の拡張機能ストアを立ち上げる必要があるでしょう。

AdGuard の Dmitriy Seregin 氏は、AdGuard AdBlocker MV3 Experimental を作成するという同社の取り組みについて、やや楽観的な見解を示しました。

MV3 では拡張機能の作成者が動的なルール (オンザフライで生成される) ではなく宣言的なルール (事前に設定) に頼らざるを得なかったが、それでも Seregin は AdGuard が対応できると示唆している。

「実験的な拡張機能は以前のものほど効果的ではありませんが、ほとんどのユーザーは違いを感じないでしょう」と、セレギン氏は約1週間前のブログ投稿で述べています。「唯一気になるのは、装飾ルールの適用に遅延が生じるため、広告がちらつくことです。」

ウェブブラウザにおけるコンテンツブロッキングの将来は、EFFのアレクセイ・ミアグコフ氏とベネット・サイファーズ氏が昨年12月に述べたものとよく似ています。彼らは次のように述べています。「Manifest V2では、拡張機能は独自の永続的な実行環境を持つファーストクラスアプリケーションのように扱われます。しかし、V3では、拡張機能はアクセサリのように扱われ、限定的な権限しか与えられず、リアクティブにしか実行できません。」®