※以下はAIを用いて作成しました。個人的な勉強用です。

I. declarativeNetRequest API入門

目的とビジョン

chrome.declarativeNetRequest APIは、Manifest V3仕様の中核をなすコンポーネントであり、従来のwebRequest APIが持っていたブロッキング機能を置き換えるために設計されました 。

このAPIの主な目的は、ネットワークトラフィックの操作方法を根本的に変更することにより、ユーザーのプライバシー、セキュリティ、そしてブラウザのパフォーマンスを向上させることにあります 。  

コアとなる提案

このAPIの中心的な前提は、拡張機能がネットワークリクエストの内容を傍受したり閲覧したりすることなく、リクエストを変更できるようにすることです 。開発者は、リクエストごとに任意のJavaScriptコードを実行する代わりに、あらかじめ一連の宣言的なルールを登録します。ブラウザ自体がこれらのルールをネイティブに評価し、強制的に適用します 。  

Manifest V3における文脈

このAPIは独立した変更ではなく、永続的なバックグラウンドページから一時的なサービスワーカーへの移行を含む、より広範なプラットフォームの転換の一部です 。  

declarativeNetRequestの設計は、この「レイジー（遅延）」なプロセスモデルと基本的に互換性があります。これは、長期間実行されるプロセスを必要としたブロッキングwebRequest APIとは対照的です 。  

このAPIの設計は、拡張機能プラットフォームのアーキテクチャにおける哲学的な転換を反映しています。

Manifest V2のwebRequest APIは、信頼の原則に基づいていました。拡張機能にはネットワークトラフィックへの強力で直接的なアクセス権が与えられ、それを効率的かつ安全に処理することが信頼されていました 。しかし、このモデルには重大な問題がありました。リクエストごとの同期的なJavaScript実行によるパフォーマンスの低下、そして拡張機能が通信中の機密データにアクセスできることによる深刻なプライバシーおよびセキュリティリスクです 。

Googleの報告によれば、2018年1月以降の悪意のある拡張機能の42%がwebRequest APIを使用していました 。  

declarativeNetRequestはこのモデルを逆転させます。主要な信頼される主体は拡張機能ではなく、プラットフォームそのものです。拡張機能はルールを通じてその「意図」を宣言し、ブラウザはリクエストデータを拡張機能に公開することなくその意図を実行します 。これは、拡張機能に広範な権限を与える「能力ベース」のセキュリティモデルから、拡張機能に限定的で事前に承認された一連のアクションを与える「宣言的意図」モデルへの移行を意味します。この変更は、開発者の自由度とプラットフォームによる制御との間のバランスに、深遠な影響を及ぼします。  

ブラウザの互換性

このAPIは、Chrome (84以降)、Firefox (113以降)、Safari (15以降)、Edge (84以降) といった主要なブラウザで利用可能であり、新しいウェブ拡張機能の標準としての重要性が確立されています 。

II. コアアーキテクチャと概念

このセクションでは、APIのコンポーネントを詳細に分解し、レポートの残りの部分の技術的基盤を構築します。

宣言的モデル：パラダイムシフト

命令的 (webRequest) vs. 宣言的 (declarativeNetRequest)
旧来のモデルと新しいモデルは根本的に異なります。webRequestモデルは命令的です。「すべてのリクエストに対してこの関数を実行し、何をすべきかを指示する」というアプローチでした。

一方、declarativeNetRequestモデルは宣言的です。「ここにルールのリストがある。ルールに一致するリクエストがあれば、指定されたアクションを実行せよ」というアプローチです 。  

ブラウザネイティブでの実行
パフォーマンス向上の鍵は、拡張機能のJavaScriptエンジンを呼び出し、リクエストごとにプロセス境界を越えるのではなく、ブラウザの高度に最適化されたネイティブコードがこれらのルールを評価することにあります 。  

ルールの解剖学

すべてのルールオブジェクトは、4つの基本的なプロパティで構成されています：id、priority、action、そしてconditionです 。  

• id: ルールセット内でルールを一意に識別するための必須の整数（1以上）です 。  

• priority: 同じ拡張機能内の複数のルールが単一のリクエストに一致した場合の競合を解決するために使用されるオプションの整数（1以上、デフォルトは1）です。最も高い優先度の値を持つルールが優先されます 。  

• action: ルールの条件が満たされたときに何を実行するかを定義するオブジェクトです 。  

• condition: アクションをトリガーするためにネットワークリクエストが満たすべき基準を定義するオブジェクトです 。  

開発者が管理する必須のidフィールドは、開発者の利便性よりもパフォーマンスを優先するという意図的な設計判断を反映しています。ある開発者は、APIがIDを自動生成しないため、動的ルールに一意のIDを手動で追跡・割り当てなければならない「厄介さ」を指摘しています 。この設計は、開発者が新しいルールを追加する前に既存のルールを取得して未使用のIDを見つけるという複雑さを伴います 。  

この設計が採用された理由は、declarativeNetRequestの核となる目標がパフォーマンスであるためです 。

開発者に一意のIDの提供を強制することで、ブラウザの内部C++実装は、このIDをハッシュマップのような高性能なデータ構造の直接的なキーとして使用し、ルールの検索、更新、削除を高速化できます。

IDを自動生成する場合、ブラウザがそれを作成し、JavaScriptコンテキストに非同期で返し、その後拡張機能がそのIDを将来の変更に使用する必要が生じます。現在の設計は、ブラウザの内部ロジックを簡素化し、プロセス間通信を削減することで、APIのパフォーマンス第一の哲学と一致しています。これは、APIがブラウザのネイティブなリクエスト処理パイプラインの効率を最大化するために、管理の複雑さを開発者に転嫁するという、マクロレベルのトレードオフのミクロレベルでの一例です。  

ルールの条件：ネットワークリクエストの精密なターゲティング

conditionオブジェクトのプロパティを詳述し、ネットワークトラフィックを正確にターゲットする方法を説明します。

URLマッチング

• urlFilter: シンプルかつ強力なパターンマッチング構文です。特殊文字の意味は次の通りです：*（ワイルドカード）、|（アンカー）、||（ドメインアンカー）、^（セパレータ）。  

• regexFilter: RE2構文を使用した、より複雑なマッチング用です。urlFilterとは相互に排他的であり、ルールセットタイプごとに1,000ルールという厳格な制限があります 。 

リソースとリクエストのコンテキスト

• resourceTypes & excludedResourceTypes: main_frame、script、imageなどの文字列の配列で、特定のコンテンツタイプをターゲットにします 。  

• requestMethods & excludedRequestMethods: get、postなどのHTTPメソッドをターゲットにするための配列です 。  

• initiatorDomains & excludedInitiatorDomains: リクエストを開始したドキュメントのドメインに基づいてリクエストをターゲットにします。これは、「social-media.comを閲覧しているときに限り、evil-tracker.comからのスクリプトをブロックする」といったルールに不可欠です 。  

• requestDomains & excludedRequestDomains: リクエストURL自体のドメインに基づいてリクエストをターゲットにします 。  

• domainType: firstParty（ファーストパーティ）とthirdParty（サードパーティ）のリクエストを区別します 。  

タブ固有の条件（セッションルールのみ）

• tabIds & excludedTabIds: ルールを特定のタブにスコープすることを可能にし、一時的またはコンテキストに応じた変更に強力な機能を提供します 。

ルールのアクション：トラフィックの傍受と変更

actionオブジェクトを詳述し、5つの主要な操作を説明します。

• type: 'block': 最もシンプルなアクションで、リクエストをキャンセルします。ブロックされた画像やiframeはDOM内で自動的に折りたたまれます 。  

• type: 'redirect': リクエストを別の宛先にルーティングします。以下のオプションを持つredirectオブジェクトが必要です：

  • url: リダイレクト先の静的なURL。

  • extensionPath: 拡張機能内にパッケージ化されたリソースへのリダイレクト。

  • transform: URLの構成要素（スキーム、ホスト、ポート、パス、クエリ）を変更するためのURLTransformオブジェクト 。  

  • regexSubstitution: regexFilter条件からのキャプチャグループを使用して新しいURLを構築します 。  

• type: 'upgradeScheme': httpまたはftpリクエストを透過的にhttpsにアップグレードする特殊なリダイレクトです 。  

• type: 'modifyHeaders': リクエストまたはレスポンスヘッダーの追加、設定、削除を可能にします。これにはModifyHeaderInfoオブジェクトのrequestHeadersまたはresponseHeaders配列が必要です 。  

• type: 'allow' & type: 'allowAllRequests': 例外ルールです。これらのアクションは一致するblockルールを上書きし、ホワイトリスト機能を提供します。allowAllRequestsはより強力で、ドキュメント内のすべてのサブリソースの読み込みに適用されます 。  

ルールセットの理解：静的、動的、セッションスコープ

ルールは個別に管理されるのではなく、ルールセットにグループ化されます。

静的ルールセット

• 定義: 拡張機能にバンドルされたJSONファイル（例: rules.json）で定義されます 。  

• マニフェスト設定: manifest.jsonのdeclarative_net_request.rule_resourcesキーで宣言されます。各エントリはid、path、初期のenabled状態を指定します 。  

• ライフサイクル: 拡張機能のインストール/更新時に読み込まれます。有効化されたルールセットのセットはブラウザセッションをまたいで永続しますが、拡張機能の更新をまたいでは永続しません 。  

• 管理: ルールセット全体はupdateEnabledRulesets()でプログラム的に有効/無効にできます 。静的セット内の個々のルールもupdateStaticRules()で切り替え可能です 。  

動的ルールセット

• 定義: JavaScriptを介してプログラム的に管理される、単一の永続的なルールセットです 。  

• ライフサイクル: ルールはブラウザセッションと拡張機能の更新をまたいで永続します 。  

• 管理: updateDynamicRules()を使用してルールが追加・削除されます 。  

セッションルールセット

• 定義: プログラム的に管理される、単一の一時的なルールセットです 。  

• ライフサイクル: ルールは一時的なもので、ブラウザセッションが終了するとクリアされます 。  

• 管理: updateSessionRules()を使用してルールが追加・削除されます 。現在のブラウジングセッションに基づくルール（タブ固有の変更など）に最適です。

III. declarativeNetRequest API vs. webRequest API: 比較分析

このセクションでは、技術的な説明から批判的な分析へと移行し、Manifest V3への移行を取り巻く中心的な議論に焦点を当てます。

パフォーマンスへの影響

• declarativeNetRequestを支持する議論: ルールの評価がブラウザのネイティブコードで行われるため、サービスワーカーの起動、リクエストデータのシリアライズ、そしてすべてのネットワークリクエストに対するプロセス間通信のオーバーヘッドを回避できるため、よりパフォーマンスが高いとされています 。これは、永続的なバックグラウンドプロセスを必要としないため、リソースの節約に特に有益です 。  

• 反論: 批評家や拡張機能開発者は、最適化された広告ブロッカーにおけるwebRequestのパフォーマンスへの影響は、広告やトラッカーをブロックすることで節約される数秒の時間と比較して、無視できるレベル（多くの場合ミリ秒単位）であったと主張しています 。彼らは、パフォーマンスに関する議論が誇張されていると示唆しています。  

プライバシーとセキュリティの向上

• declarativeNetRequestを支持する議論: 拡張機能がルールを事前に宣言し、個々のネットワークリクエストの詳細（ヘッダー、ボディなど）を読み取ることがないため、本質的によりプライベートであるとされています 。これにより、悪意のある、あるいは侵害された拡張機能が、ネットワークトラフィックからメールや認証情報などの機密性の高いユーザーデータを収集するのを防ぎます 。  

• 反論: 批評家は、webRequest APIの観測用（非ブロッキング）部分は非推奨になっていないと指摘しています 。拡張機能は依然としてすべてのネットワークトラフィックを観測する権限を要求でき、これによりプライバシー上の利点が相殺される可能性があります。悪意のある拡張機能は、ブロッキング用にdeclarativeNetRequest、観測用にwebRequestの両方を要求し、ユーザーはそれらの権限を許可してしまうだろう、というのが彼らの主張です 。  

柔軟性と制限

• webRequestの力: その主な強みは柔軟性でした。拡張機能は、単純なURLパターンだけでなく、リクエストのコンテキスト、以前のリクエスト、または外部データソースなどの要因に基づいてリクエストをブロックするかどうかを決定するための、複雑で動的なロジックを実行できました 。  

• declarativeNetRequestの制約: 宣言的モデルは本質的に柔軟性に欠けます。拡張機能はリアルタイムでの決定を下すことができず、すべてのロジックは有限のルールセットに事前にコンパイルされなければなりません 。これは特に、静的ルールとして表現できないヒューリスティックまたはAIベースの検出方法を使用する高度なコンテンツブロッカーに影響を与えます 。  

• ルール制限: これが最も重大な制限です。静的、動的、および正規表現ルールには厳格な上限が設けられています 。広告ブロッキングコミュニティは、declarativeNetRequestで当初提案された制限をはるかに超える数十万のルールを持つフィルターリストを維持しています。これらの制限は引き上げられましたが、複雑なブロッカーの開発者にとっては依然として大きな懸念事項です 。  

Manifest V3を巡る論争：バランスの取れた要約

• Googleの立場: declarativeNetRequestへの移行は、すべてのユーザーにとってより安全で、パフォーマンスが高く、よりプライベートな拡張機能エコシステムを構築するための必要なステップであると主張しています 。 

• 批評家の立場（EFF、Ghosteryなど）: ルール制限や柔軟性の喪失といった変更は、革新的で強力なプライバシーツールを機能不全にし、最も効果的な広告ブロッカーを無力化する一方で、真に悪意のある拡張機能を阻止するにはほとんど役立たないと主張しています 。一部では、これはGoogleが自社の中核である広告ビジネスを守るために広告ブロッキングを弱体化させる動きだと見なされています 。  

webRequestとdeclarativeNetRequestを巡る議論は、単なる技術的な論争ではなく、オープンなウェブの未来とユーザーの主体性に関する哲学の衝突でもあります。

webRequest APIは、ユーザーが選択した拡張機能を通じて、リスクを伴うとしてもブラウジング体験を究極的に変更する力を持つという哲学を体現しています。それはユーザーの主体性のためのツールです。

一方、declarativeNetRequest APIは、プラットフォーム中心の哲学を表しています。ブラウザベンダー（Google）が、平均的なユーザーのために安全性とパフォーマンスのベースラインを確保するために拡張機能の能力をキュレーションし、たとえそれが上級ユーザーの力を制限することになったとしても、それを優先します。

EFF や広告ブロッカー開発者 からの議論は、単にルール制限に関するものではなく、ブラウザプラットフォームがどのコンテンツが「ブロック不可能」であるかを決定できる未来への潜在的な可能性に関するものです 。この移行は、ユーザーの専門知識を必要とするオープンで強力なプラットフォームと、安全性とシンプルさを優先する閉鎖的でキュレーションされたエコシステムとの間の、テクノロジー業界におけるより大きな緊張関係の縮図です。

IV. 実践的な実装とユースケース

このセクションでは、開発者をガイドするための、完全で注釈付きのコード例を提供します。

マニフェストの設定 (manifest.json)

declarativeNetRequestを使用するManifest V3拡張機能の完全なmanifest.jsonテンプレートを提供します。

• 権限 (Permissions): declarativeNetRequest（インストール時に警告が表示され、ホスト権限なしでブロッキングが可能）とdeclarativeNetRequestWithHostAccess（インストール時の警告はなく、リダイレクト/ヘッダー変更にはhost_permissionsが必要）の違いを説明します 。また、デバッグ用のdeclarativeNetRequestFeedback権限についても説明します 。  

• ホスト権限 (Host Permissions): ブロッキングにはホスト権限は不要ですが、redirectやmodifyHeadersのようなアクションには必要であり、これらはhost_permissionsキーで宣言する必要があります 。  

• ルールセットの宣言: declarative_net_request.rule_resources配列と、静的なJSONルールファイルへのリンク方法を示します 。  

manifest.json

// manifest.json の例
{
  "manifest_version": 3,
  "name": "DNR API Demo",
  "version": "1.0",
  "description": "declarativeNetRequest APIのデモンストレーションです。",
  "permissions":,
  "host_permissions": [
    "*://*.example.com/*" // example.comでのリダイレクトやヘッダー変更に必要
  ],
  "background": {
    "service_worker": "background.js"
  },
  "declarative_net_request": {
    "rule_resources": [
      {
        "id": "ruleset_1",
        "enabled": true,
        "path": "rules.json"
      }
    ]
  }
}

ユースケース1：コンテンツブロッキング戦略

静的ブロッキング
トラッカー、広告、特定のリソースタイプをブロックする例を含むrules.jsonファイルを提供します。

rules.json

// ブロッキング用のrules.jsonの例

    }
  },
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "/advertisement.",
      "resourceTypes": ["image", "sub_frame"]
    }
  }
]

動的ブロッキング
ユーザーがカスタムブロックリストにドメインを追加するなどの応答として、プログラムでブロックルールを追加する方法を示すbackground.jsのスニペットを提供します。

// 動的ブロッキング用のbackground.jsの例
chrome.runtime.onInstalled.addListener(() => {
  console.log("拡張機能がインストールされました。");
});

// 次に利用可能なルールIDを取得するヘルパー関数（開発者による実装が必要）
async function getNextAvailableRuleId() {
  const rules = await chrome.declarativeNetRequest.getDynamicRules();
  const maxId = rules.reduce((max, rule) => Math.max(max, rule.id), 0);
  return maxId + 1;
}

// ユーザー定義のブロックルールを追加する関数例
async function addBlockRule(domainToBlock) {
  const newRule = {
    id: await getNextAvailableRuleId(),
    action: { type: 'block' },
    condition: {
      requestDomains:,
      resourceTypes: ['main_frame', 'sub_frame', 'script', 'image', 'xmlhttprequest']
    }
  };

  await chrome.declarativeNetRequest.updateDynamicRules({
    addRules:
  });
  console.log(`${domainToBlock}をブロックするルールが追加されました。`);
}

ユースケース2：高度なURLリダイレクトと変換

シンプルなリダイレクト
あるURLを別のURLにリダイレクトするルールを示します（例：twitter.comをfacebook.comへ）。  

URLの変換
アフィリエイトリンクやトラッキング保護の一般的なユースケースとして、transformオブジェクトを使用してURLにクエリパラメータを追加する方法を示します 。

// クエリパラメータを追加するルールの例
{
  "id": 3,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": {
      "transform": {
        "queryTransform": {
          "addOrReplaceParams": [{ "key": "ref", "value": "my_extension" }]
        }
      }
    }
  },
  "condition": {
    "requestDomains": ["product-site.com"],
    "resourceTypes": ["main_frame"]
  }
}

正規表現ベースのリダイレクト
regexFilterとregexSubstitutionを使用して、トラッキングパラメータを削除するなど、複雑なURLを書き換える例を提供します 。  

ユースケース3：リクエストおよびレスポンスヘッダーの変更

カスタムリクエストヘッダーの設定
RefererヘッダーやカスタムのX-ヘッダーを設定するルールを示します 。

// リクエストヘッダーを設定するルールの例
{
  "id": 4,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders":
  },
  "condition": {
    "urlFilter": "||api.service.com",
    "resourceTypes": ["xmlhttprequest"]
  }
}

レスポンスヘッダーの削除
コンテンツスクリプトによる変更を許可するためにContent-Security-Policyヘッダーを削除するデモを行います（一般的ですが潜在的にリスクのあるユースケースです）。

ヘッダー変更の優先順位の説明
複数のヘッダー変更がどのように適用されるかについての厳格なルール、特にsetおよびremove操作に対する「先勝ち」ロジックを詳述します。

V. 高度なルール管理とデバッグ

サービスワーカーによるプログラム的なルール管理

状態管理
一時的なサービスワーカーでルールの状態を管理するという課題について議論します。グローバル変数は永続的ではないため 、開発者はchrome.storageを使用して、どの動的ルールが追加されたかを追跡する必要があります。

ベストプラクティス：状態の同期
状態ID（例：UUID）をchrome.storageと特別な「ダミー」DNRルールの両方に保存するという高度なテクニックを紹介します。サービスワーカーの起動時に、拡張機能はこれらのIDを比較して非同期を検出し、必要に応じてルールセットを再構築できます 。  

ルールIDの管理
指摘された問題点に対処するため、現在のすべての動的ルールを取得し、衝突を避けるために次に利用可能なIDを計算するヘルパー関数の堅牢なコード例を提供します。

ルール制限と優先順位のナビゲーション

ルール制限の詳細
既知のルール制限の明確な表を提示します：GUARANTEED_MINIMUM_STATIC_RULES (30,000)、MAX_NUMBER_OF_ENABLED_STATIC_RULESETS (50)、MAX_NUMBER_OF_DYNAMIC_RULES (30,000、「安全でない」ルールは5,000まで)、MAX_NUMBER_OF_SESSION_RULES (5,000)、MAX_NUMBER_OF_REGEX_RULES (1,000) 。

また、乱用を防ぐために検討された、インストールされているすべての拡張機能にまたがる潜在的なグローバルルール制限の概念についても議論します。これは開発者にとってさらなる複雑さを加えるものです 。  

ルールの優先順位ロジック

• 拡張機能内: 2段階のシステムを説明します。まず、最も高いpriority値を持つルールが選択されます。同点の場合は、アクションタイプが勝者を決定します（優先順位：allow > allowAllRequests > block > upgradeScheme > redirect）。 modifyHeadersルールは、ブロック/リダイレクトの決定が下された後に別途適用されます。

• 複数の拡張機能間: 複数の拡張機能がリクエストに一致する場合、まずアクションタイプが優先されます（block > redirect/upgradeScheme > allow）。それでも同点の場合は、最も最近インストールされた拡張機能が優先されます 。  

ルール制限と優先順位決定システムは、拡張機能にとって競争的で潜在的に脆弱なエコシステムを生み出します。ハードなルール制限、特に議論されたグローバル制限の存在は、拡張機能が有限のリソースを奪い合っていることを意味します。多くのルールを登録して「土地を先取り」する拡張機能は、他の拡張機能をリソース不足に陥らせる可能性があります 。「最後にインストールされた拡張機能が勝つ」というタイブレークルールは恣意的であり、ユーザーにとって予測不可能な動作につながる可能性があります。信頼していたセキュリティ拡張機能が、後からインストールされた「テーマ」拡張機能によって上書きされるかもしれません。これにより、開発者は防御的な思考を強いられます。

自分のルールが尊重されるように高いpriority値を使い、ルール数を慎重に管理しなければなりません。このシステム設計は「後出しが有利」な状況とリソースの競合を生み出し、複数の拡張機能がアクティブな場合にリクエスト処理の最終結果をユーザーや開発者が推論することを困難にします。

ルールセットの効果的なデバッグとテスト

パッケージ化されていない拡張機能の読み込み
静的ルールファイルの検証エラーは、開発者モードでパッケージ化されていない拡張機能を読み込んだ場合にのみ表示されることを強調します 。無効なルールを持つパッケージ化された拡張機能は、静かに失敗します 。  

onRuleMatchedDebugの使用
declarativeNetRequestFeedback権限を使用してonRuleMatchedDebugイベントをリッスンする方法を説明します。これは、どのルールがどのリクエストにリアルタイムで一致しているかを確認するための主要なツールです 。一致したルールをサービスワーカーのコンソールに記録するためのコードスニペットを提供します。  

testMatchOutcomeによるテスト
実際にリクエストを行うことなく、どのルールが仮想的なリクエストに一致するかをチェックできるこの強力な関数を紹介します。これは、ルールロジックの単体テストに非常に価値があります 。  

よくある落とし穴

• resourceTypesの指定忘れ: resourceTypes配列を省略したためにルールが一致しない、という非常に一般的なエラーです。条件は具体的である必要があります 。  

• ルールのキャッシュ/更新の問題: 開発中にルールの更新がすぐに適用されないことがあり、完全な拡張機能の再インストールやブラウザデータの消去が必要になる場合があることに注意してください 。  

• 長時間の使用でルールが機能しなくなる: ブラウザの長時間稼働後にルールが機能しなくなる問題を参照し、開発者はAPI（getDynamicRules）を介して登録済みルールをチェックし、予期せずクリアされていないことを確認すべきだと提案します 。

VI. 結論：ベストプラクティスと将来展望

堅牢な実装のためのベストプラクティスの要約

• 適切なルールセットを選択する: コアロジックには静的ルール、ユーザー設定には動的ルール、一時的な状態にはセッションルールを使用します。

• 条件を具体的にする: 意図しない一致を避け、パフォーマンスを向上させるために、常にresourceTypesを含めます。

• 状態を永続的に管理する: chrome.storageを使用して動的ルールを追跡し、同期チェックメカニズムを実装します。

• 防御的に優先順位を付ける: priorityフィールドを使用して、拡張機能の重要なルールが簡単に上書きされないようにします。

• 徹底的にデバッグする: 開発中はonRuleMatchedDebugとtestMatchOutcomeを広範囲に活用します。

ウェブリクエスト傍受の進化する風景

ChromeがManifest V3で先陣を切っている一方で、Firefoxのような他のブラウザは、より大きな柔軟性のためにブロッキングwebRequest APIを維持するなど、修正を加えて実装していることに簡単に言及します 。これは、議論がまだ続いていることを示しています。  

結論として、declarativeNetRequestは、大多数の拡張機能にとってリクエスト変更の未来を代表する、強力で、パフォーマンスが高く、プライバシー中心のAPIです。しかし、その宣言的な性質と固有の制限により、開発者は新しい設計パターンを採用し、特定のユースケースに対するアーキテクチャ上のトレードオフを慎重に検討する必要があります。