MV3制約の影響でカスタムフィルタと臨時修正フィルタがなくなりました
「AdGuardブラウザ拡張機能のカスタムフィルタと臨時修正フィルタはどこに？」
Chromeの厳しいリモート実行ポリシー（Manifest V3の下）に準拠するため、私たちAdGuardブラウザ拡張機能側は辛い決断を迫られました。カスタムフィルタは一時的に利用不可能になり、臨時修正フィルタは恒久的に削除されました。
その理由は、Chromeのポリシーではスクリプトやリモートホストコードの挿入が禁止されているからです。このポリシーのもともとの意図は良いものですが、その文言があまりにも広範であるため、広告ブロックルールでさえもこれらの制限の対象となってしまうことがありあるのです。残念ながら、カスタムフィルタと臨時修正フィルタの両方も該当していると判断されました。
なぜこれが問題なのか
まず第一に、「臨時修正フィルタ」が実装されたこと自体も、もともとMV3（Manifest V3）の制限があったからです。
MV3対応のブラウザ拡張機能では、AdGuardのフィルタはすべて拡張機能自体にあらかじめ組み込まれており、つまりフィルタの更新もストアでの審査を経て拡張機能自体のまるごとアップデートを通じてしか配信できないということです。
となると、フィルタ更新内容がユーザーに届くまでには数日かかる可能性があります。人気のあるウェブサイトが壊れた場合、ユーザーは解決策を待たなければならず、ユーザーにとってもAdGuardにとってもストレスが溜まるシチュエーションになります。
MV2（Manifest V2）では、差分アップデート という方法でこの問題を解決し、拡張機能全体をアップデートすることなく、新しいフィルタを迅速に配信できるようになりました。
しかし、MV3ではそのような仕組みの導入が許されていないため、「臨時修正フィルタ」が、フィルタのリアルタイム更新を実現するためのAdGuardの次善策となりました。
臨時修正フィルタをMV3に準拠させるために最善を尽くしましたが（このフィルタを巡る苦悩に満ちた経緯については下記の「この問題の進展タイムライン」を参照）、最終的にはChromeのポリシーにより、同フィルタを完全に削除せざるを得なくなりました。これは大きな損失のひとつです。
もうひとつの損失は「カスタムフィルタ」で、同じリモート実行ポリシーにヤられてしまいましたした。
カスタムフィルタは、URL経由でサードパーティのフィルタを追加することを可能にします。何千ものボランティアがこれらのフィルタを管理しており、広告ブロックエコシステムの成長に不可欠なものです。AdGuardは組み込みフィルタに実在するあらゆるフィルタを全部盛り込むことはでき泣いた、カスタムフィルタが、他の多種フィルタのテストおよび配布を可能にしてくれていました。
カスタムフィルタの喪失で悪影響を受けるのはユーザーだけではありません。拡張機能がユーザーに対して有効であり続けるよう私たちAdGuardが最善を尽くしておりますが、以前にもMV3関連の記事の1つで述べたように、「MV3への移行における真の犠牲者はフィルタ開発者である」のです。
そして、ついにその時がやってきました。カスタムフィルタが失われることは、広告ブロックの世界を動かしているコミュニティにとって打撃となります。
この問題をどう解決するか
ブラウザ拡張機能の機能と利便性を維持しながら、AdGuardがフィルタリングルールを処理する方法を全面的に見直し、Chromeのポリシーに準拠させます。
以下が私たちAdGuardの対策です。
- カスタムフィルタを復活させるために、私たちは
userScriptsAPI を使用するようにします。この API を使用することで、MV3（Manifest MV3）ポリシーに準拠したスクリプトを登録することができます。
ただし、注意点があります。ユーザーはそれらを使用するために開発者モードを有効にする必要があり、余分なステップが増えます。技術に詳しくないユーザーにとっては、これが障壁となる可能性があることは承知しています。そのため、カスタムフィルタ付きのバージョンをリリースした際には、有効化とフィルタの追加方法について、わかりやすい手順を提供するようにいたします。
- 「臨時修正フィルタ」は、もはや元の形式では存在できないため、Chromeの審査免除プロセスを利用します。これにより、拡張機能の審査を待つことなく、フィルタをより頻繁に更新できるようになります。ただし、この方法は、DNRルールセットとセーフリストの変更のみに適用されるという制限があります。
間もなく、AdGuardブラウザ拡張機能のアップデートに2つのタイプを提供開始予定です。高速アップデートは数時間ごとに自動的に行われ、フルアップデートに対してはChromeウェブストアの審査が行われます。
この、あまり理想的だとは言えない解決策にたどり着くまでは、長い道のりでした。
以下の「この問題を進展タイムライン」は、広告を効果的にブロックし、ユーザーがフィルタリングを自分好みにカスタマイズできるようにしながら、拡張機能をChromeのポリシーに準拠させるために試したことのすべてを時系列で示したものです:
この問題の進展タイムライン
- 1回目の申請却下：リモートスクリプト実行
AdGuardブラウザ拡張機能のChromeウェブストア審査への申請は、ルールを適用するために <script> タグを使用しているという理由で拒否されました。 確かに、拡張機能がルールからスクリプトを抽出し、それを <script> タグ経由でページに適用する仕組みを使用していました。 MV3 拡張機能では、コンテンツ・セキュリティ・ポリシーの要件が MV2 よりも厳しく、スクリプトルールを挿入するだけでは不十分です。そのため、ページコンテンツを修正する際に開発者が使用できるツールが大幅に制限されてしまいます。そのため、場合によっては、<script>タグのインジェクションを強化する必要があり、それが問題となりました。
AdGuardがとった対策：
Firefoxで使用していたソリューションを採用しました。スクリプトルールを拡張機能内に保存されたローカルJavaScript関数に変換するものです。これにより、<script>タグを使用せずにネイティブのルールを適用できるようになりました。また、スクリプトを適用する前に、それが組み込みのルールの一部であることを確認するチェックも追加しました。
しかし、ユーザールール、カスタムフィルタ、臨時修正フィルタについては例外とし、これらのルールには引き続き <script> タグを使用して挿入することにしました。
これらの変更を加えたバージョンは承認されました。しかし、そうではありませんでした。
- 2度目の却下：臨時修正フィルタのダウンロード
今回は、リモートソースから臨時修正フィルタをダウンロードする仕組みが、リモート実行ポリシーの違反としてクロームにフラグ付けされました。
AdGuardの対応：
臨時修正フィルタの目的を説明する詳細なコメントを追加し、ポリシーに違反することなく MV3 の制限に対処するために設計された仕組みを明確にしました。
しかし、クロームの審査担当者はこれでも納得せず、次のような対応を行いました。
- 3回目と4回目の却下：臨時修正フィルタ
Chrome の要件を満たすため、Quick Fixes フィルターを完全に削除し、拡張機能を再提出しました。 再び却下されたため、サポートに連絡し、臨時修正フィルタのコードとメタデータのダウンロードを完全に無効にしたバージョンを提出しました。 このバージョンは当初は承認されましたが…。
- 5回目の却下：スクリプトレット（Scriptlets）とパラメータ
Chrome は、組み込みの JavaScript 関数であるスクリプトレットの使用が、パラメータとともに実行される可能性があるため、リモート実行ポリシーに違反していると指摘しました。
AdGuardの対応：
すべてのスクリプトレットを拡張機能に直接ハードコードしました。拡張機能エンジンは現在、ルールが事前設定のフィルターカテゴリー（広告ブロックやセキュリティなど）に一致するかどうかを検証します。一致する場合はルールが適用され、一致しない場合は破棄されます。
また、臨時修正フィルタを限定した形で再導入しましたが、<script>ベースの実行は行われません。
これらの変更にもかかわらず、AdGuardブラウザ拡張機能は依然として却下されました。
より大きく見た全体像
もちろん、私たちAdGuardはこの状況を乗り越える方法を見つけます。それが私たちの仕事だからです。
しかし、これはAdGuardだけの問題ではありません。Chromeのポリシーはすべての広告ブロッカーや拡張機能に影響を与えます。
開発者には、Chrome ウェブストアからのより明確なガイドラインと透明性が必要なのです。
今回の状況がセキュリティと機能性のバランスについてより幅広い議論を喚起することを期待しています。このような話題は、開発者とユーザーの両方に利益をもたらします。
