2025年版 ベストなウェブスクレイピングツール＆ソフトウェア | Thunderbit

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

今回の監査では、Thunderbit を含む 10 個のスクレイピング／ブラウザ自動化拡張機能を読みました。Thunderbit は私たち自身の拡張です。見えてきた差はかなり大きいです。あるものは常時のサイトアクセスを一切宣言していません。別のものは clipboardRead を含む 13 個の権限を宣言しています。このセットの中で debugger を宣言しているのは Thunderbit だけで、これはページアクセス、OAuth、ユーザー提供スクリプトとは異なるリスク形状を持つ、かなり広い CDP 接続機能です。

ただし、これは批判ではありません。広い権限は、ある機能を作るうえで唯一まっとうな選択であることもありますし、狭い権限は単にできることが少ない製品だというだけかもしれません。大事なのは、その差が非常に大きく、しかも公開されているのに、比較表にはまず載らないということです。

どうやって調べたか

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

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

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

• 宣言された静的挙動: ホストパターンと content_scripts エントリ。matches、run_at、all_frames を含みます。
• ランタイムコードが利用可能な機能: 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 はこれらすべてを、拡張機能ごとの「ファイル URL へのアクセスを許可」トグルの背後に置いており、これは既定ではオフです。したがって、宣言は許可ではなく要求です。5/10 という数え方が正直な数字であり、その 5 つのうち 2 つは file:// を manifest 内のどこにも書いていません。Axiom.ai と私たち自身のものです。

この数え方には、コンテンツスクリプトやホスト権限だけでなく web_accessible_resources も含まれます。Table Capture はそこでも file://*/* を書いています。ここを除外すると、実際にはスキーム名を書いている拡張を、書いていないものとして誤って分類してしまいます。

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

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

userScripts は要求されるまで現れず、権限数を見ているだけの人には見えません。

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

どちらも隠れているわけではありません。どちらも manifest にあります。optional ブロックを無視した表は、2 つの製品を過小評価します。

スコープだけでなく、注入タイミングも重要

コンテンツスクリプトがいつ注入されるかは見落とされがちですが、見え方を大きく変えます。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 の静的コンテンツスクリプトは document_end です。ランタイム API は別の機能クラスであり、この表からは推測できません。

権限数は、指標としてはかなり粗いです。 Table Capture は 4 つの権限しか宣言していませんが、この一覧では大半より少ないにもかかわらず、<all_urls> の全フレームに document_start で注入し、さらに要求時には userScripts を使えます。

誰が拡張機能にメッセージを送れるか

externally_connectable は、どの Web ページや他の拡張機能が、拡張機能の background script に直接メッセージを送れるかを制御します。デフォルトはちょっと直感に反します。

キーを省略するのが、許可が広い設定です。 externally_connectable が存在しない場合の Chrome の既定は、どの拡張機能でも接続できるが、Web ページは接続できない というものです。これを明示するのは、むしろ制限をかけるためです。

この前提で見ると、表は反転します。

Chrome のルールには 2 段階 あります。manifest の参照によれば:

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

Axiom.ai はキーを宣言していますが、matches だけです。 したがって ids は未設定であり、どの拡張機能もそこへメッセージできません。つまり拡張機能チャネルは開いていないのです。開いているのは 7 つの Web オリジンで、そのうち Axiom のドメインは 1 つだけです。残りは、由来を特定できない第三者の 2 つ（*://*.tgwc.space/*、*://*.bitmachine.co.uk/*）と、localhost、0.0.0.0、Google APIs のホスト、そして運営していない大手ソーシャルプラットフォーム 1 つです。

Hexomatic は拡張機能チャネルを 8 つの指定 ID に開放しています。 キーが存在する時点でベースラインは 0 拡張機能です。そこに 8 つを指定すると、8 まで広がります。6 つの matches はもう一方のチャネルを、何もない状態から広げています。そのうち 2 つは http://localhost:8000/* と http://localhost:3000/* で、しかも平文 HTTP です。ユーザーのマシン上でそのポートに応答するものはすべて、この allowlist の内側にあります。

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

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

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

manifest には oauth2 ブロックを含めることができ、その中のスコープは他社サービス上のあなたのアカウントへのアクセスです。これは上記のどれとも別種類の到達範囲であり、権限数では表せません。

公式参考: 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> のページアクセスを組み合わせています。

ただし、この表で証明できることには制限があります。スコープは要求されているだけで、付与されたとは限りません。Google は同意画面を出し、ユーザーは拒否できますし、拡張機能が API を一度も呼ばない可能性もあります。さらに manifest が見ているのは、Chrome の identity フロー経由の OAuth だけです。別の Web サインインページへ飛ばす拡張機能なら、ここには何も出ません。7 個のゼロは「このファイルでは要求していない」という意味であって、「Google アカウントへのアクセスがない」という意味ではありません。 私たち自身のものも含めてそうであり、そのためこの軸は狭さの主張ではなく、別軸として報告しています。

私たち自身の拡張を同じ尺度で見ると

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

宣言された静的挙動: <all_urls> がホスト権限とコンテンツスクリプトの一致条件の両方に現れます。静的スクリプトは all_frames で document_end に実行されます。<all_urls> には file: が含まれるため、ユーザーが Chrome のファイルアクセス切り替えを有効にすれば、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 の具体的なサイト名を挙げています。 ソーシャルネットワーク、開発者向けプラットフォーム、配信プラットフォーム、チャット製品、ビジネスデータ提供元、自社ドメインなどです。コンテンツスクリプトもまったく同じ 14 を対象にしています。

この manifest を読めば、拡張機能がどこで有効なのかを正確に知ることができます。しかもこれは製品の開示でもあり、どこを狙うツールなのかを、マーケティングよりもはっきり教えてくれます。

トレードオフは確かにあります。指定リストにないサイトはスクレイピングできず、新しい対象を増やすたびにリリースが必要です。しかし、「14 の指定ドメイン」と「存在するすべての URL」はまったく別の提案であり、読み解けるのは片方だけです。

リストに書かれていたものではなかった 2 製品

Captain Data の拡張機能は公開配布されていません。 Google の更新エンドポイントは、この拡張 ID に対して HTTP 204、本文なし を返しました。ストアが匿名ユーザーには配布しないものに対する応答です。一方で、その listing ページ自体は匿名で配信され、HTTP 200、509,829 バイトでした。取得した内容からは、バージョン文字列、最終更新日、インストール数を見つけられませんでした。スクリプトのメモにも、そこが null であることは弱い証拠だと書いてあり、ログイン壁は確認できませんでした。ID は実在し、ファーストパーティであるため、リンク限定配布か非公開配布がもっとも妥当な解釈ですが、非公開化と区別できなかったので、推測はしません。

Dataflow Kit には Chrome 拡張機能がそもそもありません。 サイトには、ポイント＆クリックの選択機能を備えたホスト型 Web アプリと REST API が説明されています。それでも Chrome 拡張機能の候補一覧に入っていました。こうしたリストはたいてい、そのように作られてしまうものです。

古さと到達範囲。どちらも無料で確認できるので

ストアのメタデータは、権限だけでは分からない製品選定の文脈を与えてくれます。同じ項目を 2026-07-30 にすべての拡張機能で取得しました。

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

この表が意味しないことが 2 つあります。インストール数は 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> は、その拡張機能が すべてのページを読み取れるかもしれない という意味です。実際にそうしているか、あるいは何かが機械の外へ出ているかまでは示しません。実際に何が起きているかを確かめるには、ランタイムのネットワーク通信を観察する必要があります。今回は別作業であり、実施していません。以上の内容は不正利用の証拠として読むべきではありません。

関連レビュー: Chrome 拡張機能のテスト可能性に関する実験。

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

• Chrome が多くの部分を制御しています。 ファイルアクセスは既定でオフです。activeTab は意図的に狭いです。任意の権限はランタイムのプロンプトが必要です。ユーザーはインストール時に権限一覧を見ます。
• 広い権限が必要なことはよくあります。 「今見ているどのページからでも表を抽出する」ツールは、指定ドメインの allowlist では動きません。狭い範囲は、設計の厳しさであることもあれば、単に製品が小さいだけのこともあります。
• 1 バージョン、1 日。 すべての数値は 2026-07-29 に配信されたパッケージのものです。

分析上の重要な補正

公開された数値は、ざっくりとした manifest パーサーを書くと簡単に間違える 3 つのルールに従っています。まず、<all_urls> には file: スキームが含まれますが、実際のファイルアクセスは Chrome がユーザー制御のトグルの背後に置いています。次に、web_accessible_resources.matches は、コンテンツスクリプトとホスト権限と一緒に確認しなければなりません。Table Capture が file://*/* を明示しているのはここです。第三に、externally_connectable は、キー全体がない場合と、キーはあるがサブフィールドが空の場合で既定値が異なります。上の表はこれらのルールを一貫して適用しています。

Thunderbit の権限総数では、単なる文字列の数と Chrome が認識する権限を区別しています。配列には 9 項目ありますが、commands はトップレベルに置くべきキーなので、ここでは認識済みの 8 権限に未認識文字列 1 つを加えた形で扱っています。最後に、静的な content_scripts 宣言は、そのコードが scripting.registerContentScripts や CDP メソッドを呼ぶ証拠ではありません。それらの可能性はランタイム機能の範囲にのみ現れ、観測された挙動ではありません。生の manifest、CRX のハッシュ、パーサー出力はこうした正規化の監査証跡として残してあるので、読者は文章をそのまま信じる必要がありません。

実際の導入判断では、少なくとも 4 つの観点を分けて比較してください。デフォルトでどのページが対象か、どの明示的なユーザー操作で到達範囲が広がるか、どのブラウザ／アカウント API が使えるようになるか、そしてどの外部呼び出し元が拡張機能にメッセージを送れるかです。Agenty の activeTab モデル、Table Capture のゲート付き userScripts、Axiom.ai の Drive スコープ、Thunderbit の debugger 宣言は、1 本の直線上の点ではありません。異なる脅威の問いに対する、異なる答えです。

その比較を、意図的に異なる 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 は「場合によってはホスト権限やファイルアクセスなど、他の典型的な制限を迂回することがある」と説明されています。したがって、サイトアクセスを「クリック時のみ」にしても、到達範囲の上限にはなりません。さらに、この制御は 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 には、コンテンツスクリプトでは書かれていないスキームが書かれていることがあります。Thunderbit の最後のフィールドには、index.html と 2 つのバンドル済みスクリプトをすべてのオリジンに公開する <all_urls> エントリが 2 つあり、use_dynamic_url: false により、ページがそれらの固定された拡張 URL を解決できるかどうかをテストできます。
3. リスティングの最終更新日を現在の Chrome バージョンと照らし合わせます。

開示と資料: この記事は Thunderbit が公開しており、同じ表とパーサーに自社拡張が含まれています。非拡張ツールについては、オープンソーススクレイパーのピラー記事 を参照してください。

Web データ抽出に Thunderbit を試す

要点だけ言うと

スクレイピングと自動化の拡張機能 10 個を、私たち自身のものも含めて、それぞれ自分の manifest から読み解きました。

Agenty はサイトアクセスもコンテンツスクリプトも宣言せず、クリックしたときに見ているタブ上だけで動作します。2.2 MiB です。 Axiom.ai は HTTP と HTTPS のすべての URL を宣言しています。37.1 MiB です。 Magical は clipboardRead を含む 13 個の権限を宣言しています。しかも、ここで唯一、受信メッセージングを完全に閉じている拡張機能でもあります。 Table Capture はわずか 4 つの権限しか宣言していませんが、<all_urls> の全フレームに document_start で注入し、さらに要求時には userScripts を使えます。 TexAu は最小で、しかも最も多くの対象を名前で挙げています。13 の異なるプロパティにまたがる 14 のパターンです。唯一の命名型ではありません。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:// にも届きます。

宣言は上限であって挙動ではなく、このどれも不正利用を示すものではありません。ただし、これは公開されており、無料で確認でき、両端の差は製品ページ上のどの差よりも大きいのです。

Web データ抽出に Thunderbit を試す 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 つ、ホスト権限なし、コンテンツスクリプトなし。activeTab に依存しており、これは拡張機能をクリックした後に、その時見ているタブにだけアクセスでき、しかも移動するまでの間だけです。次に少ないのは Hexomatic で、権限は 2 つ、自社ドメインに限定したコンテンツスクリプトです。

file:// を書かずにローカルファイルへ届くのはなぜですか？ <all_urls> には file: スキームが含まれるからです。Listly、Magical、Table Capture は file:// パターンを明示的に書いています。Magical はコンテンツスクリプトで、Table Capture は web_accessible_resources で書いています。Axiom.ai と Thunderbit は、どこにも書かずにワイルドカード経由で到達します。http://*/* と https://*/* は file:// を含みません。Chrome は拡張機能ごとのトグルの背後でファイルアクセスを既定オフにしているので、宣言は許可ではなく要求です。

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

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