過去 1 年間、Google は MV3 拡張機能プラットフォームの改善方法について、複数のコンテンツ ブロック拡張機能のベンダーと積極的に話し合いを行ってきました。これらの議論（その多くは、他のブラウザと協力して WebExtensions コミュニティ グループ（WECG）で行われました）に基づいて、Google は大幅な改善をリリースすることができました。
その他の静的ルールセット
通常、フィルタルールのセットはリストにグループ化されます。たとえば、より一般的なリストにはすべてのユーザーに適用されるルールを含めることができますが、より具体的なリストには、一部のユーザーのみがブロックしたい地域固有のコンテンツを非表示にできます。最近まで、各拡張機能でユーザーに 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 ルールの上限が適用されます。安全な DNR ルールとは、アクションが block、allow、allowAllRequests、upgradeScheme のルールです。
AdGuard から提供されたデータに基づくと、この上限引き上げはルールの 98 ～ 99% にメリットをもたらすはずです。残りのルールは引き続きサポートされ、既存の上限内で追加できます。
これは、Chrome では MAX_NUMBER_OF_DYNAMIC_RULES 定数として使用できます。その他の動的ネットリクエスト ルールのルールの上限は 5,000 件のままです。
ルールセットのサイズを削減
Chrome 118 では、コミュニティからのフィードバックに基づいて、isUrlFilterCaseSensitive フィールドのデフォルト値を false に変更しました。このフィールドは、URL でフィルタするルールの大文字と小文字を区別するかどうかを制御します。ほとんどのデベロッパーは、拡張機能のデフォルトを変更していることがわかりました。そのため、値を何度も設定する必要がありました。この変更により、デベロッパーはルールセットのサイズを大幅に削減できます。
次のステップ
Google は、可能な限り多くのユースケースをサポートできるよう、declarativeNetRequest API への投資を継続し、コミュニティとの連携を継続してまいります。特に、この作業を推進するうえで大量のデータを共有してくれた AdGuard 様をはじめ、この API の設計に大きく貢献したすべてのブラウザ ベンダー様、WECG のメンバーの皆様に感謝いたします。
YouTube は、設定されている上限について引き続き見直しを行い、必要に応じて調整を行っていきます。これをサポートするため、この取り組みの一環として収集したデータの一部を近日中に公開する予定です。また、PDF ビューア拡張機能からの一般的なリクエストである、レスポンス ヘッダーとの照合機能などの追加機能の追加にも取り組んでいます。いずれの場合も、Google は引き続き取り組みについてお知らせし、ウェブ拡張機能コミュニティ グループを定期的に使用してアイデアを議論し、次に検討する内容を調整していきます。