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