Google は過去 1 年間、MV3 拡張機能プラットフォームの改善をめぐって、複数のコンテンツ ブロック拡張機能の開発に関わったベンダーとの議論に積極的に関与してきました。その多くは、WebExtensions Community Group（WECG）と他のブラウザとの連携のもとで行われました。その結果、大幅な改善を行うことができました。
その他の静的ルールセット
通常、フィルタルールのセットはリストにグループ化されます。たとえば、汎用的なリストにはすべてのユーザーに適用されるルールを含め、より具体的なリストには、一部のユーザーのみがブロックを希望する地域固有のコンテンツを非表示にできます。最近までは、各拡張機能で 50 個のリスト（「静的ルールセット」）の選択肢をユーザーに提供でき、そのうち 10 個は同時に有効にできました。拡張機能の開発者はコミュニティとの議論の中で、特定のユースケースには低すぎることを示す説得力のある証拠を提出しました。以上の点を念頭に置いて Chrome での API のパフォーマンスを検討した結果、最大 50 を同時に有効にできるようになりました。（特に、これは WECG で要求されている上限の 20 個よりも大幅に高い値です）。また、合計で 100 個のルールセットも許可されています。これは Chrome 120 でリリースされ、上限の引き上げは Firefox と Safari の両方でサポートされています。両社は、どちらもこの提案に初期の意見を提供しています。
その他のダイナミック ルール
ほとんどのルールは「静的」であり、拡張機能が更新されるたびにリリースされます。ただし、より頻繁な更新とユーザー定義のルールに対応するために、拡張機能でルールを動的に追加することもできます。デベロッパーが新しいバージョンの拡張機能を Chrome ウェブストアにアップロードする必要はありません。
Chrome ウェブストアの審査時に確認されていない方法で拡張機能がリクエストを動的に変更できる場合、ユーザーはフィッシングやデータ盗難のリスクにさらされます。たとえば、リダイレクト ルールが悪用され、同意なしにアフィリエイト リンクが挿入される可能性があります。
そのため、拡張機能で追加できるルールは 5,000 個までに制限しました。この機能を控えめに使用し、不正行為を簡単に検出できるようにしました。
ただし、AdGuard や Adblock Plus などの拡張機能のデベロッパーは、独自の分析とデータ共有を行いました。そのため、上限を引き上げると、より最新のルールを利用できるようになり、多くのカスタムリストを使用しているユーザーは Manifest V3 に移行できます。実際、AdGuard の報告によると、人気のあるリストに毎週 2,600 件以上の変更が加えられており、カスタム フィルタリストを使用する 5% のユーザーのうち 4 人に 1 人は、合計で 5,000 を超えるダイナミック ルールを設定しています（出典）。AdGuard は、拡張機能を Manifest V3 に移行する際の大きな課題として指摘しており、他のコンテンツ ブロッカーからも同様のフィードバックが寄せられています。
一部のフィルタルール（アクションが block または allow のルールなど）は安全性が高く、悪用される可能性が低いと判断されました。また、広告ブロックのフィルタルールの大部分を占めています。これに基づいて、私は Web Extensions コミュニティ グループで、低リスクと見なし、最大 30,000 件のルールを定義するための提案を下書きして共有しました。パフォーマンスの低下を避けるために、上限は引き続き設定されます。
この提案は Web Extensions コミュニティ グループでサポートされたため、導入しました。Chrome 121 以降では、ルールの上限である 30,000 ルールが安全な DNR ルールに適用されます。これは、block、allow、allowAllRequests、upgradeScheme のアクションを含むルールとして定義しています。
AdGuard が共有するデータによると、ルールの 98 ～ 99% がこの制限の引き上げによるメリットがあると考えられます。残りのルールは引き続きサポートされ、既存の上限内で追加できます。
これは Chrome では MAX_NUMBER_OF_DYNAMIC_RULES 定数として利用できます。他のすべての動的ネット リクエスト ルールのルールの上限は 5,000 のままです。
ルールセットのサイズを縮小
Chrome 118 では、コミュニティからのフィードバックに基づいて、isUrlFilterCaseSensitive フィールドのデフォルト値を false に変更しました。このフィールドでは、URL でフィルタするルールで大文字と小文字が区別されるかどうかが決まります。Google はほとんどのデベロッパー様において、拡張機能のデフォルトとは異なるデフォルト値を設定していることがわかっています。そのため、値を何度も設定しなければなりませんでした。この変更により、デベロッパーはルールセットのサイズを大幅に削減できます。
次のステップ
Google は、今後も declarativeNetRequest API に投資を続けることで、できるだけ多くのユースケースをサポートできるようにしたいと考えています。今後もコミュニティと協力して作業を続けていく予定です。特に、この取り組みの原動力となった大量のデータを共有してくれた AdGuard や、この API の設計に大きく貢献したすべてのブラウザ ベンダーを含め、WECG の活動に関わってくださった WECG のメンバーに感謝の意を表します。
Google は、必要に応じて設定を調整し、上限を引き続き見直してまいります。これをサポートするために、近い将来、この取り組みの一環として収集したデータの一部を共有する予定です。さらに、PDF ビューア拡張機能でよく見られるレスポンス ヘッダーとの照合機能などの追加機能にも取り組んでいます。どのような場合でも、Google は今後も自分たちの取り組みをお伝えするとともに、アイデアについて話し合い、今後目指したいことについて調整する場として、Web Extensions コミュニティ グループを定期的に利用していきます。