サイトアクセスゼロか、全URLか：10件のスクレイパー拡張機能で見る権限の広がり

すべての Chrome 拡張機能には manifest.json が含まれており、そこにはブラウザレベルでどこまでできるかの上限がかなり細かく書かれています。たとえば、要求する API、ホストのパターン、静的なコンテンツスクリプト、オプション権限、そして許可された外部接続です。このファイルは、インストールしたパッケージの中で公開されています。とはいえ、宣言された能力のうち、実行時コードがどれを実際に使うのか、何が端末の外に送られるのか、あるいは別の Web ログインを通じてどのアカウントにアクセスするのかまでは証明しません。

今回、監査対象として選んだ 10 個のスクレイピング／ブラウザ自動化拡張機能を読みました。その中には、私たち自身の Thunderbit も含まれます。結果はかなり幅があります。ある拡張は常時のサイトアクセスを一切持ちません。別の拡張は clipboardRead を含む 13 個の権限を宣言しています。Thunderbit は、このセットで唯一 debugger を宣言している拡張です。これはページアクセス、OAuth、ユーザー提供スクリプトとは違うリスク特性を持つ、広い CDP 接続能力です。

ここでの意図は、誰かを責めることではありません。広い権限は、ある機能を実装するために唯一まともな方法であることがよくありますし、狭い権限は単に機能が少ないだけという場合もあります。大事なのは、その差がかなり大きいこと、しかもそれは公開されていること、そして比較表にはまず出てこないことです。

どうやって調べたか

各拡張機能は、Google の更新エンドポイントから .crx としてダウンロードしました。Chrome 自身が使うのと同じ URL です。その後、展開して解析しました。拡張機能は一つもインストールしておらず、コードも実行していません。 これは JSON ファイルを読んでいるだけです。

ダウンロードは、だいたい 2 秒に 1 回のペースで進めました。すべての .crx、その SHA-256、そして抽出した manifest.json は成果物として保存しています。Thunderbit も他の 9 個と同じスクリプトで処理しており、別経路ではありません。なので、Thunderbit の行も他とまったく同じやり方で算出されています。

分析では、証拠を 2 つのクラスに分けて、混同しないようにしています。

• 宣言された静的挙動: matches、run_at、all_frames を含むホストパターンと content_scripts の記述。
• 実行時コードが利用可能な能力: permissions または optional_permissions に書かれた API。これらは、コードが要求したり呼び出したりできるものを示すだけで、実際にそうしていることまでは示しません。

「最も強力」といった順位づけはしていません。debugger、userScripts、広範なホストアクセス、OAuth スコープ、クリップボードアクセス、外部メッセージングは、それぞれ別のデータを露出し、必要条件も違います。これらを比べるには、manifest だけを読む今回の監査では足りない脅威モデルが必要です。

以下のサイズは、ZIP エントリを合計した展開後の総量で、単位は MiB（2²⁰ バイト）です。

基準日: 2026-07-29。 拡張機能は更新されるので、引用する前に必ず再確認してください。

10 個の manifest が何を宣言しているか

公式参照: Chrome の権限宣言ガイド。

もう 2 つ候補に挙がっていましたが、ここには載せていません。理由は別で触れる価値があります。

この差はサイズではなく設計の選択

Agenty はホスト権限を宣言せず、コンテンツスクリプトも一切同梱していません。 宣言している 4 つの権限は activeTab、scripting、identity、identity.email です。ここで重要なのは activeTab のような狭い権限です。これは、拡張機能をクリックした後にだけ現在のタブへのアクセスを与え、しかも別ページへ移動するまでに限られます。自分で起動しない限り、ページ上では何も動きません。サイズは 2.2 MiB です。

Axiom.ai は http://*/* と https://*/* を宣言し、<all_urls> に一致するコンテンツスクリプトを注入し、232 ファイルにまたがって 37.1 MiB になります。 これは Agenty の 17 倍のサイズで、見ているすべてのページに常時アクセスできます。

Hexomatic は Agenty 側の設計です。権限は 2 つ（storage、tabs）だけで、ホスト権限はなく、コンテンツスクリプトも自社ドメイン 2 つに限定されています。

Clay for Chrome はまた別の形です。ホスト権限として *://*/* を宣言していますが、コンテンツスクリプトの注入先は自社ドメインだけです。常時の能力は広い一方で、実際の挙動は狭いのです。権限表だけではこの違いは見えにくいです。

10 個のうち 5 個はローカルファイルに届く

file:/// は Web サイトではありません。ブラウザのタブ内で表示されるローカルファイルシステムです。たとえば、開いた PDF、HTML エクスポート、ダウンロードした請求書などです。

公式参照: Chrome の match-pattern ドキュメント。

3 つの拡張はそれを明示的に書いています。残り 2 つは明示せずに到達します。<all_urls> には file: スキームが含まれるからです。

http://*/* と https://*/* は file:// をカバーしません。<all_urls> と *://*/* の違いも、ここでは重要です。ここにある 5 つは、どちらかの経路でそのスキームに到達できる宣言をしているものです。ワイルドカードの形がどうであれ、到達するかどうかは別問題です。

Chrome はこれらすべてを拡張機能ごとの「file URL へのアクセスを許可」トグルの裏に置いており、これは既定でオフです。つまり、宣言は付与ではなく要求です。5/10 という数が正直な数であり、その 5 つのうち 2 つは manifest に file:// を一切書いていません。Axiom.ai と私たち自身です。

この数え方には、content scripts とホスト権限だけでなく web_accessible_resources も含めています。Table Capture はそこに file://*/* を明記しています。もしそのブロックを無視すると、manifest にスキーム名を書かずにファイルに届く拡張機能の側に誤って分類してしまいます。

要求されるまで見えない権限

optional_permissions は事前に宣言されますが、実際の要求は実行時です。そのため、インストール時のプロンプトには表示されません。これを使っている拡張は 2 つあり、そのうち 1 つが重要です。

userScripts は、要求されるまでは存在しないものとして扱われ、権限数を読む人には見えません。

また、この監査で扱った他の権限とは別にゲートもあります。ここを抜かすと過大評価になります。userScripts を宣言しただけでは使えません。Chrome が明示的なユーザー操作を先に要求します。 Chrome 138 より前は、chrome://extensions 全体で有効にする Developer Mode でした。Chrome 138 以降は、各拡張機能の詳細ページにある個別の Allow User Scripts トグルで、既定はオフです。したがって、通常のインストールではその能力は宣言されていても実質的には無効です。正確に言うなら、ユーザーが Chrome のゲートを有効にした後で、Table Capture は userScripts API を利用可能にできます。この監査では、実際にどれくらいのユーザーがその設定ページを開くか、あるいはトグルを有効化するかは測っていません。

どちらも隠されてはいません。両方とも manifest にあります。optional ブロックを無視した表は、2 製品を過小評価します。

範囲だけでなく、注入タイミングも重要

content script がどのタイミングで注入されるかは見落とされがちですが、見え方を変えます。document_start は Chrome が提供する最も早いフックで、all_frames は第三者埋め込みにも届きます。

このセットで、静的に全フレームへ注入するものを、宣言タイミング順に並べると以下の通りです。

Table Capture と Listly は、広い一致パターンに対して最も早いフックで実行されます。Axiom.ai と Clay for Chrome も同じタイミングですが、自社ドメインだけに限定されています。つまり、同じ攻め方でも対象が狭いということです。

静的な宣言の観点では、<all_urls> と all_frames の組み合わせが一致範囲の上限であり、Table Capture と Thunderbit はその上限にいます。ただし、宣言タイミングは異なります。Table Capture は document_start、Thunderbit の静的 content script は document_end です。実行時 API は別の能力クラスであり、この表からは推測できません。

権限数は、良い要約統計ではありません。 Table Capture は権限数が 4 で、ここでは多くの製品より少ない方ですが、document_start で <all_urls> の全フレームに注入し、さらに要求時には userScripts も使えます。

どのページが拡張機能にメッセージできるのか

externally_connectable は、どの Web ページまたは他の拡張機能が、拡張機能のバックグラウンドスクリプトに直接メッセージを送れるかを制御します。デフォルトは直感に反します。

キーを省略するのが、実は許容的な設定です。 externally_connectable が存在しない場合の Chrome の既定は、どの拡張機能も接続できるが、Web ページは接続できないというものです。これを宣言するのは、接続先を制限するためです。

この前提で表を見ると、意味が反転します。

Chrome のルールには2 段階あります。manifest リファレンスから引用すると次の通りです。

許容的な既定は、キー全体が存在しない場合にだけ適用されます。キーが存在した瞬間に、両方のサブフィールドは閉じた状態から始まり、値を入れることで各チャネルが広がります。

Axiom.ai はキーを宣言し、matches だけを持ちます。 そのため ids は未設定で、どの拡張機能もメッセージを送れません。 拡張機能チャネルは開いていないのです。開いているのは 7 つの Web origin で、そのうち Axiom のドメインは 1 つだけです。残りは、帰属しにくい第三者 2 つ（*://*.tgwc.space/*、*://*.bitmachine.co.uk/*）、localhost、0.0.0.0、Google APIs のホスト、そして Axiom が運営していない大規模ソーシャルプラットフォーム 1 つです。

Hexomatic は、8 つの指定 ID に対して拡張機能チャネルを開いています。 キーが存在する以上、既定は 0 個の拡張機能です。そこに 8 個の ID を書くことで 8 個に広がります。6 つの matches は別のチャネルを none から広げ、そのうち 2 つは http://localhost:8000/* と http://localhost:3000/* というプレーン HTTP のローカルアドレスです。ユーザーのマシン上でそのポートに応答するものは、allowlist の内側に入ります。

10 個のうち 7 個はキーを完全に省略しており、私たち自身もその中に含まれます。 その 7 つは、拡張機能間メッセージングにおける許容的な既定に置かれています。2 つの拡張機能はそのチャネルを閉じています。Magical は ids: [] で明示的に閉じ、Axiom.ai はキーを宣言しつつ ids を一切書いていません。両方のチャネルを閉じているのは Magical だけです。

最後の一文こそ、権限数ではなく manifest を読むべき理由です。同じ拡張機能でも、ある軸では広く、別の軸ではこのセットで最も厳格、ということが起こります。

誰も数えない軸: OAuth スコープ

manifest には oauth2 ブロックを含められます。そこにあるスコープは、他社サービス上のあなたのアカウントへのアクセスです。これは上で挙げたどの権限とも違う reach であり、権限数ではまったく表せません。

公式参照: Google OAuth 2.0 のスコープ一覧。

https://www.googleapis.com/auth/drive は広い方です。Google にはもっと狭い drive.file スコープがあり、これはアプリ自身が作成したファイル、またはユーザーが明示的に選んだファイルだけにアクセスを与えます。auth/drive は、ユーザーの Drive 全体に対して閲覧・編集・作成・削除が可能です。auth/spreadsheets も同じ構造で、そのアカウントが触れるすべてのスプレッドシートに及びます。Axiom.ai と Table Capture は、Google アカウントのスコープと <all_urls> のページアクセスを組み合わせています。

この表が証明することには 2 つの限界があります。まず、スコープは要求であって付与ではありません。Google は同意画面を出し、ユーザーは拒否できますし、拡張機能が API を呼ばない可能性もあります。次に、manifest が見ているのは Chrome の identity フローを通る OAuth だけです。もし拡張機能が Web のサインインページへ飛ばす方式なら、ここには何も書かれません。7 つの 0 は「このファイルでは要求していない」という意味であり、「Google アカウントにアクセスしない」という意味ではありません。 これは私たち自身にも当てはまるため、この軸は「狭さ」の証明ではなく、報告対象として挙げています。

同じ尺度に乗せた自社拡張

Thunderbit 4.6.4 も、他の 9 つと同じ manifest パーサーを通しました。パッケージは展開後 15.9 MiB、78 ファイルです。

宣言された静的挙動: <all_urls> がホスト権限と content-script の一致条件の両方に出てきます。静的スクリプトは document_end で all_frames に注入されます。<all_urls> には file: が含まれるため、Chrome の file-access トグルをユーザーが有効にすれば、manifest はローカルファイルにも届きます。Thunderbit は externally_connectable も省略しているため、Chrome の既定ではどの拡張機能からもメッセージを受けられますが、Web ページからは受けられません。

実行時能力の上限: permissions 配列には 9 つの文字列があります。activeTab、commands、debugger、offscreen、scripting、sidePanel、storage、tabGroups、tabs です。Chrome が権限として認識するのはこのうち 8 個で、commands はトップレベルの manifest キーであり、この配列の要素としては効果がありません。Thunderbit はこのセットで唯一 debugger を宣言しており、これはタブに CDP をアタッチできます。また、manifest は scripting を実行時登録のために利用可能にしています。これらの API は、静的な document_end 行を超える能力を作りますが、manifest を読むだけでは、Thunderbit が特定の CDP メソッドを呼ぶのか、あるいはもっと早い時点でスクリプトを登録するのかまでは分かりません。

この違いがあるため、いくつかの魅力的ですが誤った比較はできません。より狭い cookies 権限がないことは、debugger を持つコードが何にアクセスしうるかの上限を意味しません。clipboardRead がないことは、クリップボードに届かないという証拠ではありません。逆に、debugger があることは、それらの経路が実際に使われている証拠でもありません。それを確かめるには、ソースコードの調査か実行時トレースが必要で、今回はどちらもしていません。

この基準では、Thunderbit は静的なサイトアクセスが広く、このセットで debugger を宣言している唯一の拡張であり、拡張機能間メッセージングについては Chrome の既定にあります。CDP、OAuth、userScripts、クリップボード、ホストアクセスをまたぐ共通の脅威モデルが監査にない以上、「最強」の単一順位づけはありません。

マーケティングされない、慎重な設計

TexAu は 0.3 MiB で、ここでは最小です。しかもワイルドカードではなく 14 の特定サイト名を挙げています。 それらは、ソーシャルネットワーク、開発者向けプラットフォーム、出版系プラットフォーム、チャット製品、ビジネスデータ提供者、そして自社ドメインです。content scripts もまったく同じ 14 に一致します。

この manifest を読むだけで、その拡張機能がどこで動くのかをかなり正確に把握できます。しかもこれは製品の開示でもあります。対象リストは、マーケティング文よりもはっきりと、そのツールが何のためのものかを示します。

トレードオフも明快です。指定リスト方式では、そこにないサイトはスクレイプできませんし、新しい対象を追加するたびにリリースが必要です。しかし、「14 の指定ドメイン」と「存在するすべての URL」はまったく別の話で、読めるのはそのうち一方だけです。

リストどおりではなかった 2 つの製品

Captain Data の拡張機能は公開配布されていません。 Google の更新エンドポイントは、その拡張 ID に対して HTTP 204、空の本文 を返します。これはストアが匿名には配信しない対象への応答です。一方、その一覧ページは匿名で配信されており、HTTP 200、509,829 バイトでした。取得できた情報にはバージョン文字列、最終更新日、インストール数がありませんでした。スクリプトのメモにも、ここで null が出るのは弱い証拠だと書かれており、サインイン壁も見当たりませんでした。ID は実在し、ファーストパーティなので、リンク限定配布か未掲載配布がいちばんありそうですが、非掲載化と区別はできなかったため、推測はしていません。

Dataflow Kit には Chrome 拡張機能がありません。 そのサイトは、クリック選択型のホスト型 Web アプリと REST API を説明しています。それでも Chrome 拡張機能のショートリストには載っていました。こういうリストは、だいたいそういう作られ方をします。

古さと reach は、どちらも無料で確認できる

ストアのメタデータは、権限だけでは見えない製品選定の文脈を補います。同じフィールドを、2026-07-30 にすべての拡張機能で取得しました。

3 製品は 1 年以上更新されておらず、Hexomatic はもうすぐ 2 年です。拡張機能では、ライブラリよりもこの点が重要です。Chrome はおよそ 4 週間ごとに安定版を出し、拡張機能プラットフォーム自体もその下で変化し続けます。userScripts のユーザーゲートは Chrome 138 で移動しました。2024 年に最後に出た拡張機能は、今ブラウザが強制しているルールとは違うルールの上で作られたものです。

この表について、言えることとそうでないことがあります。インストール数は Google によってバケット化されており、1,000 / 3,000 / 7,000 / 10,000 / 100,000 / 200,000 です。そのため比較できるのは桁くらいで、それ以上の細かさはありません。しかも、いくつかの製品は自社マーケティングでより大きな数字を掲げています。新しい日付は、出荷の事実であって、保守品質や権限リスクの判定ではありません。

一つ便利な副産物もあります。分析した 10 個のパッケージでは、ストア版と manifest 版がすべて一致していました。 この監査で解析した CRX は、ストアが今配信しているものであって、古いコピーではありません。

新しさは、選択肢にどれだけ追加検証が必要かを変えます。manifest の意味そのものは変えません。名前付きドメインの拡張が 1 年前に更新されたものでも、昨日出たワイルドカード拡張よりページ面の露出が少ないことはあり得ます。逆に、新しいパッケージの方が Chrome の変更に素早く追従するなら、運用上はそちらの方がいいこともあります。ショートリストを作るなら、ストアの日付で再テスト対象を決め、manifest でより深い能力レビューが必要かを判断してください。2 列を 1 つのスコアにしないでください。

manifest からは分からないこと

宣言された権限は上限であって、挙動ではありません。 <all_urls> は、拡張機能がすべてのページを読み取れる可能性があることを意味します。実際に読むか、何かが端末の外に出るかは意味しません。実際に何が起きているかを確かめるには、実行時のネットワーク通信を見る必要があります。これは別作業で、今回は行っていません。以上を misuse の証拠として読むべきではありません。

関連レビュー: Chrome 拡張機能のテスタビリティ実験。

さらに 3 つの境界があります。

• Chrome が多くを制御しています。 ファイルアクセスは既定でオフ、activeTab は意図的に狭い、optional 権限は実行時プロンプトが必要、インストール時にはユーザーに権限一覧が表示されます。
• 広い権限が必要な場面は多いです。 「今見ているどのページからでも表を抽出する」ツールは、名前付きドメインの allowlist では動きません。狭い範囲は、慎重さの表れである場合もあれば、単に機能が少ないだけの場合もあります。
• 1 バージョン、1 日の話です。 すべての数値は 2026-07-29 に配信されたパッケージからのものです。

分析における重要な修正点

公開されている数値は、簡易な manifest パーサーを書くと誤りやすい 3 つのルールに基づいています。第一に、<all_urls> には file: スキームが含まれますが、Chrome は実際のファイルアクセスをユーザー制御のトグルの裏に置いています。第二に、web_accessible_resources.matches は content scripts とホスト権限と一緒に確認する必要があります。Table Capture が file://*/* を明示しているのはそこです。第三に、externally_connectable は、そのキー全体がない場合と、キーはあるがサブフィールドが空の場合とで既定が違います。上の表は、これらのルールを一貫して適用しています。

Thunderbit の権限合計も、生の文字列と Chrome が認識する権限を区別しています。配列には 9 つの要素がありますが、commands はトップレベルのキーなので、ここでは有効な権限 8 個と未認識の文字列 1 個として数えています。最後に、静的な content_scripts の記述は、コードが scripting.registerContentScripts や CDP メソッドを呼ぶ証拠ではありません。それらの可能性は、実行時能力の欄にしか現れず、観測された挙動ではありません。生の manifest、CRX ハッシュ、パーサー出力は、読者がこうした正規化を本文を信じることなく監査できるよう、公開時に付録へリンクすべきです。

実際にインストールを決めるなら、少なくとも 4 つの次元を別々に比べてください。既定でどのページが対象か、どの明示的なユーザー操作で reach が広がるか、どのブラウザ／アカウント API が使えるようになるか、そしてどの外部呼び出し元が拡張機能にメッセージできるかです。Agenty の activeTab モデル、Table Capture のゲート付き userScripts、Axiom.ai の Drive スコープ、Thunderbit の debugger 宣言は、一本の線上に並ぶ点ではありません。異なる脅威の問いに対する、それぞれ別の答えです。

ここでは、意図的に異なる 4 つの設計にその比較を当てはめています。

この表でも、勝者は出ません。Agenty の狭い常時ページアクセスは、バックエンドが送信データをどう扱うかを何も語りません。Axiom.ai のアカウントスコープは、現在ページを読む拡張機能と同列には置けません。Table Capture の userScripts 宣言は、ユーザーが別ゲートを有効にするまで無効です。Thunderbit の debugger 権限は広いブラウザ制御面を露出しますが、manifest はコードがどの CDP ドメインやメソッドを呼ぶかを明かしません。各行が教えてくれるのは、次に何を調べるべきかです。実行時のネットワーク通信か、ソースコードか、同意フローか、ブラウザ API のトレースか。

同じ分離は、Chrome のインストール時プロンプトを読むときにも重要です。生の権限数だけでは、タイミング、フレーム到達範囲、OAuth スコープ、web_accessible_resources、省略された externally_connectable キーは分かりません。逆に、広い宣言があるからといって、収集や持ち出しの証拠になるわけでもありません。manifest 監査の有用な成果物は、優先順位付きの実行時テスト計画です。データ面を特定し、ユーザーゲートを確認し、その宣言された経路が実際に使われるか観察してください。

自分の拡張を読むには

関連レビュー: ブラウザ自動化ガイド。

1. chrome://extensions → 詳細 で付与済みのサイトアクセスを確認できます。また、常時アクセスが不要なものは クリック時のみ に切り替えられます。これで、上で見たサイトアクセスの半分は狭められます。ただし、受信メッセージングには触れません （externally_connectable は service worker に関係なく届きます）、またブラウザレベルの権限にも触れません。 Thunderbit の debugger 宣言がここで重要になります。Chromium の拡張機能セキュリティ文書には、debugger API が 「場合によっては host permissions や file access のような通常の制限を迂回できる」とあります。したがって、サイトアクセスを「クリック時のみ」にしても、到達範囲の上限にはなりません。さらにこのコントロールは tabs、webNavigation、clipboardRead、downloads、optional_permissions 内のものにも及びません。
2. 生ファイルは Chrome の Extensions/<id>/<version>/ ディレクトリにあります。読むべきフィールドは 6 つです。permissions、optional_permissions、host_permissions、content_scripts（その中の matches、run_at、all_frames）、externally_connectable——ここではキーがないこと自体が拡張機能からの接続に対して許容的だという点に注意——そして web_accessible_resources です。後者の matches には、content scripts では出てこないスキームを名前付きで含められます。Thunderbit の最後のフィールドには、index.html と 2 つのバンドル済みスクリプトをすべての origin に公開する 2 つの <all_urls> エントリがあり、use_dynamic_url: false なので、ページはそれらの固定された拡張 URL が解決されるかどうかをテストできます。
3. リスティングの最終更新日を、現在の Chrome バージョンと照合してください。

開示とリソース: この記事は Thunderbit が公開しており、その拡張機能も同じ表とパーサーに含まれています。私たちの オープンソース・スクレイパー・ピラー では、拡張機能以外のツールを扱っています。

Thunderbit で Web データ抽出を試す

要点だけ言うと

10 個のスクレイピング／自動化拡張機能を、私たち自身を含めて、manifest から読みました。

Agenty はサイトアクセスも content scripts もなく、クリックしたときに見ているそのタブ上だけで動作し、サイズは 2.2 MiB です。 Axiom.ai は HTTP と HTTPS のすべての URL を宣言し、サイズは 37.1 MiB です。 Magical は clipboardRead を含む 13 の権限を宣言し、しかもここで唯一、受信メッセージングを完全に閉じています。 Table Capture は権限が 4 つだけですが、document_start で <all_urls> の全フレームに注入し、さらに要求時には userScripts も使えます。 TexAu は最小サイズで、最も多くの対象を名指ししています。14 のパターンを 13 の別プロパティにまたがって持っています。しかも named しているのは TexAu だけではありません。Clip to Clay は 2 つ（clay.com と第三者サイト 1 つ）を宣言し、Hexomatic と Clay for Chrome は自社ドメインを名指ししています。TexAu は、その名簿の大半が他社サイトである唯一のものです。 10 個のうち 5 個はローカルファイルに届き、そのうち 2 つ——Axiom.ai と私たち自身——は file:// を一度も書かずに到達します。

私たちの Thunderbit は広い側に位置します。 ホストアクセスと静的注入の両方で <all_urls> を使い、このセットで他の誰も宣言していない debugger も持っています。さらに、どの拡張機能からのメッセージも許す Chrome の既定にあり、Chrome のユーザーゲートが有効になれば file:// にも届きます。

宣言は上限であって挙動ではありませんし、ここに misuse の証拠はありません。ただし、これは公開されていて、誰でも確認でき、両端の差は製品ページ上の何よりも大きいです。

Thunderbit で Web データ抽出を試す Get Started Free

FAQ

広い権限を持つ拡張機能は何か悪いことをしている、という意味ですか？ また、なぜ権限数だけでは足りないのですか？ いいえ。しかも、数え上げでは 2 つ見落とすからです。<all_urls> は、拡張機能が訪れたすべてのページを読む可能性があることを意味しますが、何をするか、何かが端末外に出るかは示しません。任意のページからデータを抽出するツールは、名指しドメインの一覧だけでは本当に動きません。今回分かったのは、その幅の差であって不正ではありません。実際の挙動を確かめるには、実行時の通信解析が必要ですが、この監査では行っていません。数の話については、注入設定は権限ではありません。Table Capture は権限 4 つでも、document_start、all_frames、<all_urls> に注入します。しかも optional_permissions はインストール時プロンプトには出ません。Table Capture は実行時に userScripts を要求でき、これはページ文脈で任意のユーザースクリプトを実行できます。Magical は webRequest を要求できます。

この中で最も要求が少ないのはどれですか？ Agenty です。権限 4 つ、ホスト権限なし、content scripts なし。activeTab に依存しており、これは拡張機能をクリックした後にだけ現在のタブへのアクセスを与え、しかも移動するまでです。次点は Hexomatic で、権限 2 つ、content scripts は自社ドメインのみに限定されています。

file:// を宣言せずに、自分のローカルファイルに到達できるのはなぜですか？ <all_urls> に file: スキームが含まれるからです。Listly、Magical、Table Capture は file:// パターンを明示しています。Magical は content scripts で、Table Capture は web_accessible_resources で書いています。Axiom.ai と Thunderbit は、どこにも書かずにワイルドカード経由で到達します。http://*/* と https://*/* は file:// をカバーしません。Chrome は file access を拡張機能ごとのトグルの後ろにあるオフ既定にしているので、これは付与ではなく要求です。

externally_connectable とは何で、なぜ省略が許容的なのですか？ これは、拡張機能のバックグラウンドスクリプトにメッセージを送れる Web origin または拡張機能 ID を指定します。キーが存在しない場合の Chrome の既定では、どの拡張機能も接続でき、どのWeb ページも接続できません。10 個のうち 7 つがこれを省略しており、Thunderbit もその中に含まれます。キーがある場合、Hexomatic は 8 つの指定 ID に拡張機能チャネルを開き、Axiom.ai は 7 つの Web origin を開きつつ拡張機能チャネルを閉じたままにし、Magical は両方を空リストで宣言して閉じています。

Thunderbit の manifest は何を宣言していますか？ ホストアクセスと静的 content-script 注入としての <all_urls>、all_frames で document_end、15.9 MiB／78 ファイル、そして権限配列に 9 つの文字列です。8 つは Chrome が認識する権限で、activeTab、debugger、offscreen、scripting、sidePanel、storage、tabGroups、tabs です。commands はトップレベルの manifest キーであり、この配列では効果がありません。このセットで debugger を宣言しているのは Thunderbit だけです。Thunderbit は Chrome の file-access ゲートが有効になれば <all_urls> 経由で file:// にも届き、externally_connectable は省略しています。実行時の挙動は実行していないため、監査ではどの CDP や scripting メソッドを実際に呼ぶかまでは主張していません。