1 ポイント 投稿者 GN⁺ 2026-02-06 | 1件のコメント | WhatsAppで共有
  • LinkedIn のウェブサイトは、ページを読み込むたびに 2,953個の Chrome 拡張機能の存在を検出している
  • このリポジトリでは、LinkedIn が確認している すべての拡張機能 ID、名前、Chrome Web Store のリンクを文書化している
  • 全拡張機能のうち 約78%は Chrome Web Store で約22%は Extpose を通じて確認された
  • 提供されている スクリプト(fetch_extension_names.js) は拡張機能名を自動収集し、削除された拡張機能は Extpose で代替参照する
  • このデータは、ウェブサイトがユーザーのブラウザー拡張機能を識別する行為の規模を示す資料である

LinkedIn Chrome Extension Fingerprinting

  • LinkedIn は各ページ読み込み時に 2,953個の Chrome 拡張機能を密かに確認している
    • この処理は、ユーザーのブラウザーにインストールされた拡張機能を識別するための fingerprinting の一形態として行われる
  • このリポジトリには、LinkedIn が確認する すべての拡張機能リストと関連ツールが含まれている
    • chrome_extensions_with_names_all.csv ファイルには、拡張機能 ID、名前、Chrome Web Store または Extpose のリンクが整理されている

データ構成

  • データファイルには Extension IDNameURL の3つの列が含まれる
    • Extension ID は32文字の識別子で、URL は Chrome Web Store または Extpose のリンクにつながる
  • 全リストは chrome_extensions_with_names_all.csv ファイルで確認できる

スクリプト

  • fetch_extension_names.js は Chrome Web Store から拡張機能名を取得し、削除済みまたはアクセス不能な場合は Extpose を通じて代替参照する
    • コマンド例: node fetch_extension_names.js, node fetch_extension_names.js --offset 0 --limit 500
  • test_fetch.js は最初の3件の拡張機能を処理し、詳細出力(verbose) モードでテストできる

統計

  • LinkedIn の fingerprint リストには 合計2,953個の拡張機能が含まれる
  • このうち 約78%は Chrome Web Store で約22%は Extpose を通じて確認された

ソースファイル

  • chrome_extension_ids.txt : LinkedIn の fingerprint.js から抽出した 生の拡張機能 ID リスト
  • fingerprint.js : LinkedIn ページに含まれる 拡張機能検出用スクリプト(短縮版)
  • fetch_extension_names.js : 拡張機能名を自動収集する 補助スクリプト

要約

  • LinkedIn がブラウザー拡張機能の情報を大規模に調査しており、
    このリポジトリはその 完全な一覧と収集方法を透明性高く公開している

1件のコメント

 
GN⁺ 2026-02-06
Hacker Newsのコメント
  • Firefoxは今回の問題に耐性があるようだ
    Chromeは拡張機能のWebアクセス可能リソースを chrome-extension://[PACKAGE ID]/[PATH] の形で公開するが、
    Firefoxは moz-extension://<extension-UUID>/myfile.png の形でアクセスする。
    この <extension-UUID> はブラウザごとにランダム生成されるため、サイトがインストール済み拡張機能を通じてブラウザをフィンガープリンティングするのを防げる
    関連ドキュメント: Chromeドキュメント, Firefoxドキュメント

    • シェア5%未満のブラウザを使うと最新のWeb技術に乗り遅れると言われるのに、逆にこういうセキュリティ上の利点があるとは皮肉だ
    • たまに自分のPCのファンが狂ったように回ることがあるが、たいていはLinkedInのタブを開いたFirefoxが原因だ。これが暗号資産のマイニングでもしているのか、単に非効率なだけなのか気になる
    • 拡張機能IDをブラウザごとに変えたら、ブラウザではなくユーザー本人が識別されることにならないのか疑問だ。
      「このブラウザにはX、Y、Zの拡張が入っている」から「これはJim Bobのブラウザだ」に変わるだけでは?
  • 拡張機能の一覧を見ると、ほとんどがLinkedInデータのスクレイピングや自動化に関する拡張だ
    LinkedInで働いていたときもこうした乱用は深刻で、内部の検知・防止システムをかなり精巧に作っていたが、終わりのない戦いだった

    • LinkedInが拡張機能のフィンガープリント用データソースを作るには、誰か(おそらくLinkedIn?)がChrome Web Storeをスクレイピングした可能性が高い。
      これはChrome Web StoreのTOS違反かもしれない
    • リストを見る限り、それほど精巧ではない。名前に「email」が入った拡張だけをフィルタした程度で、ほとんどはlinkedin.comへのアクセス権すらない
    • LinkedInにとっては問題なのかもしれないが、本当の問題はデータブローカリングを行っているLinkedInのような企業だ
    • コード上ではマッチしても何かを実行しているわけではなく、単に結果をCSVに保存してフィンガープリント用データとして使っているようだ
    • 以前クライアント案件でLinkedInをスクレイピングしたことがあるが、かなり面白い経験だった
  • Chromeはもう新しいIE6のようだ
    Googleは自らを次のMicrosoftにしてしまい、広告寄りの方向へ進んでいる。
    セキュリティ向上というより、広告ブロッカーの無力化マルウェア許容に貢献してきた印象だ

    • Chromeがスパイウェアだという点には同意するが、それでもSite Isolationsandboxingのようなセキュリティ機能を最初に導入したのは事実だ。
      パッチ速度やセキュリティテストも悪くない
    • 今のChromeはIE6よりずっとひどい存在だ。Microsoftは少なくともユーザー追跡や広告販売はしていなかった
    • 広告を支配する者がインターネットを支配する
    • Googleはすでに独占企業になっており、独占はどれも結局こうなる
    • 2026年になってもまだChromeを使っている人がいるなら、本当に勇敢な開発者だろう
  • LinkedInを開いてF12を押すと、エラーカウントが増え続ける
    スクリーンショットはこちらで確認できる

    • Xリンクがブロックされている場合は、xcancelリンクでも見られる
  • 最近、LinkedInの拡張機能検出手法と副作用の少ない別の方法についてブログにまとめた
    Castleブログ記事

    • Firefoxにパッチを当てて navigator.webdriver が常にfalseになるようにすればリモート操作は可能だ。
      検出は難しいが、入力速度のパターンではまだ検知できる
    • 記事の内容がまさにこの話題と一致していて、興味深く読んだ
  • 数か月前に関連する記事を書いた。
    なぜこうしたことが可能なのか、そして防ぐ方法まで説明した
    記事リンク

    • その記事でLinkedInがなぜこんなことをしているのかまで扱っているのか、それとも単に技術的に可能だという説明にとどまっているのか気になる
  • LinkedInは最近奇妙なダークパターンを多用している

    • Firefoxでスクロール速度を強制的に変える
    • モバイルWebでプロフィールを見て戻ると、常にホームページへリダイレクトされる
    • 分析用URLがランダムなパスで生成され、ブロック回避を試みている
      こうした挙動の理由を知っている人がいれば聞きたい
    • LinkedInは連絡先データベース業界と全面戦争をしていて、そのためにこうした戦術を使っているようだ。
      Webクローリングから人手による手作業に至るまで、多様な防御戦略を講じている最中だ
  • こうした手法はすでに2019年から知られていた
    Nymeriaブログ記事

  • LinkedInがスキャンしている拡張機能の一覧は明確だが、むしろスキャンしていない拡張機能のほうが興味深い
    たとえば「Contact Out」はスキャン可能なのに、LinkedInは無視しているような態度を見せている。
    裏取引があったのではないかと疑ってしまう
    Contact Out拡張リンク

    • その拡張はmanifestでcontent-accessibleリソースを宣言していないため、フィンガープリントできない
    • 興味深いことに、LinkedInはClaude拡張Dassi AIのようなものもブロックしていない。なぜなのか気になる
  • 「このリポジトリはLinkedInが検査するすべての拡張機能を文書化し、それらを識別できるツールを提供する」とあるが、
    LinkedInが実際にこれらのIDを検査しているとどう確認したのか気になる。
    また、これが非Chromeユーザーにも関係するのかも知りたい

    • 数週間前、あるベンダーがLinkedInの手法を技術的に分析した記事を出していて、
      自分たちのアプローチのほうが「より静かで、目立たず、大規模実行しやすい」と自慢していた
      Castleブログ記事