Chrome 拡張機能のコンテンツ フィルタリングとネットワーク フィルタリングを実装する方法はいくつかあります。このガイドでは、拡張機能で利用できるコンテンツ フィルタリング機能と、Chrome 拡張機能で使用できるさまざまなフィルタリングのアプローチ、手法、API について概説します。
ネットワーク リクエストをフィルタする
Chrome 拡張機能でネットワーク リクエストをフィルタする主な方法は、chrome.declarativeNetRequest API を使用することです。宣言型ネット リクエストを使用すると、デベロッパーは宣言型ルールを指定することで、ネットワーク リクエストをブロックまたは変更できます。宣言型ネット リクエスト ルールの形式は、ほとんどの広告ブロッカーで使用されているフィルタリストの構文の機能に基づいています。
これらのルールで実現できることは次のとおりです。
- ネットワーク リクエストをブロックする。
- URL スキームを安全なスキーム（http から https、または ws から wss）にアップグレードします。
- ネットワーク リクエストをリダイレクトします。
- リクエスト ヘッダーまたはレスポンス ヘッダーを変更する。
Chrome では、拡張機能にバンドルされたルールをサポートしています。また、リモート設定やユーザー入力に応じて動的に更新されるルールもサポートしています。
フィルタルールを拡張機能とバンドルする
拡張機能パッケージに含まれるルールは「静的ルール」と呼ばれます。これらのルールは、拡張機能がインストールまたはアップグレードされるとインストールおよび更新されます。Chrome では、拡張機能で宣言できる静的ルールの数が制限されています。
静的な宣言型ネット リクエスト ルールの場合、Chrome には 300,000 個のルールのグローバル共有プールがあり、インストールされた拡張機能のセットで同時に使用できます。さらに、すべての拡張で 30, 000 の静的ルールの許容が保証されます。たとえば、ユーザーがコンテンツ フィルタリング拡張機能を 1 つだけインストールしている場合、この拡張機能は最大 330,000 の静的な宣言型ネット リクエスト ルールを使用できます。ルールの数を把握するには、約 35,000 のネットワーク ルールで構成される、ほとんどの広告ブロッカーで使用されている一般的な EasyList フィルタリストを使用します。
静的宣言型ネット リクエスト ルールは、さまざまなルールセットに編成できます。拡張機能では最大 100 個の静的ルールセットを指定できます。これらのルールセットは一度に 50 個まで有効にできます。
実行時にフィルタルールを動的に追加する
一部のルールは拡張機能をバンドルできません。代わりに、拡張機能は実行時に追加する必要があります。このようなルールは「ダイナミック ルール」と呼ばれます。
動的な宣言型ネット リクエスト ルールの場合、Chrome では拡張機能ごとに最大 30,000 個の安全なダイナミック ルールが許可されます。block、allow、allowAllRequests、upgradeScheme のほとんどのルールは、安全なルールとみなされます。ルールが安全とみなされていない場合（redirect など）でも動的に追加できますが、動的ルールの上限数は 5,000 となり、ダイナミック ルールの上限数 30,000 件にもカウントされます。大まかに言うと、簡単リストのフィルタリストにあるルールの 98 ～ 99% は安全なルールです。
コンテンツ フィルタリング拡張機能では、静的ルールと動的ルールをそれぞれ使用して、既知のフィルタリング ルールを拡張機能にバンドルしたり、必要に応じてサーバーから新しいコンテンツ フィルタリング ルールを適用したりできます。
観測されたリクエストに基づいてルールを調整する
広告エコシステムは常に進化しているため、コンテンツ フィルタはそれに応じて更新する必要があります。chrome.webRequest と動的な宣言型ネット リクエスト ルールを組み合わせることで、プライバシー侵害の可能性についてネットワーク リクエストを分析し、将来的にブロックできます。
基本的なアプローチは次のとおりです。
chrome.webRequestAPI を使用してウェブ リクエストを分析し、プライバシー要件を満たしていないリクエストを自動的に識別します（機械学習などを使用します）。- ステップ 2 で特定したリクエストごとに動的な宣言型ネット リクエスト ルールを作成し、同様のリクエストが今後ブロックされるようにします。
- （省略可）特定した宣言型ネット リクエスト ルールをサーバーに送り返して、次回の拡張機能の更新時に静的な宣言型ネット リクエスト ルールとして追加できるようにします。
この方法のメリットは、分析が非同期的に行われ、ウェブサイトのパフォーマンスに悪影響を及ぼさないことです。
ユーザーが独自のフィルタリング ルールを定義できるようにする
拡張機能でフィルタ構成 UI を提供することで、ユーザーが独自のコンテンツ フィルタリング ルールを定義できるようにすることができます。これらのユーザー定義ルールを宣言型ネット リクエスト ルールに変換し、ダイナミック ルールとして追加します。このルールは、ブラウザ セッションや拡張機能のアップグレード後も保持されるため、ユーザーには引き続きご利用いただけます。この方法を使用すると、ユーザーは最大 30,000 個のカスタムルールを追加できます。
ウェブページの要素をフィルタする
ネットワーク リクエストのフィルタリングは、コンテンツ フィルタリングの重要な一部にすぎません。もう 1 つの大きなポイントは、ウェブページから不要なコンテンツを直接削除することです。たとえば、簡単リストのフィルタリストのルールでは、ページ要素を非表示にする方法が 40% 以上定義されています。
そのためには、コンテンツ スクリプトを使用します。コンテンツ スクリプトはウェブページのコンテキストで実行され、DOM を使って変更を加えることができます。
Chrome 拡張機能では、リモートでホストされるコードを実行できません。ただし、どの要素を非表示にするかに関するサーバーからのデータは構成データとみなされるため、影響を受けません。したがって、要素のルールはランタイムに必要に応じて更新できます。
ポリシーがインストールされている拡張機能でネットワーク リクエストをフィルタする
企業や教育機関のユースケースでは、多くの場合、コンテンツに基づくリクエストのフィルタリングなど、コンテンツとネットワークのフィルタリングに関する非常に厳しい要件があります。こうしたユースケースに対応するために、ポリシーがインストールされている拡張機能には、ネットワーク リクエストをフィルタしてブロックする追加の方法が用意されています。webRequest API のイベントで「ブロック」オプションを使用すると、リクエストごとにカスタム ロジックを実行してリクエストをブロックするかどうかを決定するプログラマティック コンテンツ フィルタを実装できます。信頼性が高いため、ポリシーによってインストールされた拡張機能に限定されます。
ナビゲーション リクエストをインターセプトする
ナビゲーション リクエストは、宣言型ネット リクエスト ルールを使用してフィルタリングできます。たとえば、ユーザーを目的のページにリダイレクトするトラッキング URL をバイパスしたい場合などです。これに対処する 1 つの方法は、ナビゲーション リクエスト https://tracker.com?redirect=https%3A%2F%2Fexample.com を拡張機能ページ（ウェブアクセス可能なリソースとして構成する必要があります）にリダイレクトすることです。拡張機能ページでスクリプトが実行され、リダイレクト ターゲットが抽出され、リンク トラッカーを回避する window.location.replace("https://example.com") を使用してリンク先にリダイレクトされます。