この 1 年間、Google は MV3 拡張機能プラットフォームを改善する方法について、複数のコンテンツ ブロック拡張機能を提供しているベンダーと積極的に協議してきました。こうした議論に基づいて、その多くは WebExtensions Community Group（WECG）で他のブラウザと連携して行われ、大幅な改善が実現しました。
その他の静的なルールセット
通常、フィルタルールのセットはリストにグループ化されます。たとえば、より一般的なリストにはすべてのユーザーに適用されるルールを含め、より限定的なリストには、一部のユーザーのみがブロックしたい地域固有のコンテンツを非表示にすることができます。最近まで、各拡張機能ではユーザーが 50 のリスト（「静的ルールセット」）から選択できるようになり、そのうちの 10 個は同時に有効化できました。コミュニティとの議論の中で、拡張機能の開発者は、これが特定のユースケースに対して低すぎることを示す説得力のある証拠を示しました。上記を念頭に置いて Chrome における API のパフォーマンスを確認した結果、現在最大 50 個の API を同時に有効にできるようにしました。（注目すべきは、これは 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 のアクションを含むフィルタルールなど、一部のフィルタルールは安全性が高く、不正使用される可能性が低いと判断されました。また、広告ブロックのフィルタルールの大部分を占めています。これに基づいて、ウェブ拡張機能コミュニティ グループで提案書の下書きを作成し、リスクが低いことを考慮し、最大 30,000 まで許可するルールを定義しました。パフォーマンスの低下を避けるため、上限は維持されます。
この提案は、Web Extensions コミュニティ グループのサポートを受けて導入されました。Chrome 121 以降、安全な DNR ルールに 30,000 ルールの上限が適用されます。これは、block、allow、allowAllRequests、upgradeScheme のアクションを持つルールとして定義しています。
AdGuard が共有するデータによると、ルールの 98 ～ 99% で上限の引き上げによるメリットが得られることが見込まれます。残りのルールは引き続きサポートされ、既存の制限内に追加できます。
Chrome では MAX_NUMBER_OF_DYNAMIC_RULES 定数として利用できます。その他の動的ネット リクエスト ルールに対するルールの上限は、すべて 5,000 のままです。
ルールセットのサイズを縮小
Chrome 118 では、コミュニティからのフィードバックに基づいて、isUrlFilterCaseSensitive フィールドのデフォルト値を false に変更しました。このフィールドは、URL でフィルタリングするルールで大文字と小文字が区別されるかどうかを制御します。ほとんどのデベロッパーには拡張機能のデフォルト設定が異なっていることがわかりました。そのため、値を何度も設定する必要がありました。この変更により、開発者はルールセットのサイズを大幅に削減できます。
次のステップ
Google は、できるだけ多くのユースケースをサポートできるように、declarativeNetRequest API への投資を継続し、引き続きコミュニティと協力していきたいと考えています。特に、この作業の原動力となった多くのデータを共有してくれた AdGuard をはじめ、WECG のエンゲージメントに尽力してくれた WECG のメンバーに感謝します。また、この API の設計に大きく貢献してくれたすべてのブラウザ ベンダーにも感謝します。
Google は、現在設定されている上限を引き続き見直し、必要に応じて調整を加えていきます。これを支援するため、この取り組みの一環として収集したデータの一部を近いうちに公開する予定です。さらに、PDF ビューア拡張機能でよく見られるリクエストであるレスポンス ヘッダーと照合する機能など、さらなる機能の追加にも取り組んでいます。どのようなケースでも、Google は引き続き取り組みをお伝えします。また、アイデアについて話し合ったり、次の内容について認識のすり合わせを行う場として、Web Extensions コミュニティ グループを定期的に開催します。