ブラウザストレージフィンガープリントとは — localStorageによる追跡

ブラウザストレージフィンガープリンティングは、ブラウザ自身のストレージ — localStorage、sessionStorage、IndexedDB、クッキー — に永続的な識別子を 埋め込み、再訪問のたびにそれを読み取るトラッキング技術です。 ハードウェアレベルのフィンガープリンティングとは異なり、ストレージ フィンガープリンティングは複数のストレージレイヤーに同時に分散することで クッキーの削除を生き残ります。ブラウザが現在何を公開しているか、 whatsmy.fyi で確認できます。

TL;DR

ブラウザストレージフィンガープリンティングは、localStorage、sessionStorage、 IndexedDB、クッキーに同時に一意の識別子を書き込むことで機能します。 一つを削除しても、トラッカーは他のものから再構築します。Evercookieのような 技術はこれを16以上のストレージベクターに拡張し、専用ツールなしでは 識別子をほぼ消去不可能にします。モダンブラウザはストレージパーティショニングで これに対抗しており、トップレベルドメインごとに各ストレージバケットを分離して クロスサイトトラッキングを構造的に不可能にします。

ブラウザストレージフィンガープリンティングとは？

ブラウザストレージフィンガープリンティングは、GPUレンダリングやオーディオ 処理のようなハードウェアシグナルではなく、ブラウザの組み込みストレージAPIを 悪用する ブラウザフィンガープリンティング のカテゴリです。目標は同じ — セッションとウェブサイトにまたがってデバイスを 一意に識別すること — ですが、メカニズムは異なります：トラッカーはブラウザ自身の ストレージにデータを書き込み、以降の訪問でそれを読み取ります。

ストレージフィンガープリンティングを単純なトラッキングクッキーと 区別するのは冗長性です。従来のクッキーは単一のストレージスロットです。 ストレージフィンガープリンティングは、同じ識別子を12の異なるストレージ メカニズムに同時に書き込みます。クッキーをクリアすると、識別子は localStorage に生き残ります。localStorageをクリアすると、IndexedDBに生き残ります。 IndexedDBをクリアすると、トラッカーはデータを保持している任意のベクターを 読み取り、他のすべてに書き直します。 電子フロンティア財団（EFF）のCover Your Tracks ツールは、ストレージベースの再生を一般ユーザーが無力化するのが最も困難な トラッキング技術の一つとして特定しています。

ブラウザストレージフィンガープリンティングはどのように機能するのか？

ストレージフィンガープリンティングは、それぞれ異なる永続性特性を持つ 4つの主要なブラウザストレージメカニズムにまたがる読み書きループに従います。

ステップ1 — 識別子の生成

最初の訪問時に、JavaScriptスクリプトが一意の識別子を生成します — 通常はランダムなUUID、または同時に収集されたハードウェアシグナルのハッシュです。 この識別子は、利用可能なすべてのストレージベクターに同時に書き込まれます。

ステップ2 — 複数のストレージレイヤーへの書き込み

同じIDがlocalStorage（永続的、オリジンスコープ）、sessionStorage （タブスコープ、タブを閉じるとクリア）、IndexedDB（構造化データベース、 大きなクォータ）、HTTPクッキー（すべてのリクエストで送信され、サーバー側から アクセス可能）に保存されます。高度な実装では、ETag、HSTSエントリー、 ブラウザキャッシュ、window.name（同じタブ内のページナビゲーション 全体で永続）にも書き込みます。

// Simplified multi-vector storage write
const trackingId = crypto.randomUUID();

// Persistent — survives browser restarts, cookie deletion
localStorage.setItem('_tid', trackingId);

// Tab-scoped — survives navigation within the tab
sessionStorage.setItem('_tid', trackingId);

// IndexedDB — structured, larger storage quota
const db = await openDB('tracker', 1, {
  upgrade(db) { db.createObjectStore('ids'); }
});
await db.put('ids', trackingId, 'primary');

// HTTP cookie — server-readable, cross-request
document.cookie = `_tid=${trackingId}; max-age=31536000; SameSite=Lax`;

ステップ3 — 再訪問時の読み取り

次の訪問時に、スクリプトは4つのストレージレイヤーすべてを読み取ります。 そのうち1つにでもIDが残っていれば、ユーザーが認識されます。 一部のベクターがクリアされていた場合、それらは残存する値からすぐに 書き直されます — この技術はクッキー復元と呼ばれます。 トラッカーの観点からは、少なくとも1つのストレージレイヤーが 生き残っている限り、ユーザーの身元は回収されます。

ステップ4 — IndexedDB順序付けサイドチャネル

単純な読み書きトラッキングを超えた微妙な脆弱性が2025年に発見され、 Fingerprint.comの研究者 によって文書化されました。FirefoxのIndexedDB.databases() APIは、 内部ハッシュテーブルによって決定された非ランダムな順序でデータベース名を 返していました — プロセススコープのサイドチャネルです。関連のないウェブサイトが このAPIを独立して呼び出し、同じ順序を観察することで、実際のストレージデータを 読み書きすることなくユーザーを異なるオリジン間でリンクできました。 この脆弱性（CVE-2026-6770）は、Firefox 150およびTor Browser 15.0.10で 結果をアルファベット順に正規化することでパッチが当てられました。

Evercookie：極端なケース

Evercookieは、セキュリティ研究者のSamy Kamkarが作成した概念実証ライブラリで、 ストレージベースの復元の全範囲を示しています。HTTPクッキー、localStorage、 sessionStorage、IndexedDB、Web SQLデータベース、Flash Local Shared Objects、 Silverlight Isolated Storage、CSSヒストリー、ETag、ブラウザキャッシュ、 HSTSヘッダー、window.name、PNGピクセルエンコーディング、 Javaアプレットストレージなど16以上のベクターに識別子を同時に保存します。 これらのサブセットが削除されると、ライブラリは残存したベクターから 完全な識別子を再構築します。2014年に、IndexedDBベースのEvercookie技術が weibo.comで本番環境で検出され、このアプローチの最初の商業的に確認された 使用例となりました。

ストレージフィンガープリンティングの統計

デスクトップとモバイルの精度の差は、モバイルデバイスの同質性が はるかに高いために生じます — 何百万人ものユーザーが同一のハードウェアと OSバージョンを共有しています。多様なGPUドライバー、インストールされた アプリケーション、フォントライブラリを持つデスクトップマシンは、 はるかに特徴的なストレージおよびハードウェアプロファイルを生成します。

実世界でのブラウザストレージフィンガープリンティングの利用者

広告・リターゲティングネットワーク

アドテク企業は、ストレージベースの識別子を使用して、Firefoxと Safariではデフォルトでブロックされ、Chromeでは非推奨となったサードパーティ クッキーに依存せずに、ユーザーのブラウジングアクティビティを異なる ウェブサイト間でリンクします。サードパーティiframe内の共有localStorageキーや IndexedDBレコードは、ブラウザがストレージパーティショニングを適用しない 限り、サードパーティクッキーと同じクロスサイト識別を達成します。

不正検出とアカウントセキュリティ

不正防止プラットフォームはマルチベクターストレージを使用して、 再訪問顧客を認識しデバイス変更をフラグするための安定したデバイス フィンガープリントを作成します。あるアカウントのログインが、そのアカウントの 以前のセッションとストレージフィンガープリントが一致しないデバイスから 来た場合、追加認証のフラグが立てられます。このユースケースは通常、 明示的な同意を必要とせず、GDPRの正当な利益を根拠として許容されます。

ペイウォールと従量制コンテンツの実施

無料記事数制限を提供するニュースパブリッシャーは、ストレージ フィンガープリンティングを使用して、クッキーをクリアしてメーターを リセットしようとするユーザーを防ぎます。記事数識別子はlocalStorageと IndexedDBに同時に書き込まれるため、クッキーだけをクリアしてもカウンターは リセットされません。ブラウザの開発者ツールからすべてのサイトデータをクリアして 初めてメーターがリセットされますが、次の訪問で識別子が再書き込みされるまでの 話です。

アナリティクスとセッション再構成

一部のアナリティクスプラットフォームはlocalStorageベースのセッション トークンを使用して、ユーザーがナビゲートして数分後に戻ってきた場合でも、 複数のページロードにわたるユーザージャーニーを繋ぎ合わせます。 これはsessionStorage（タブを閉じるとクリアされる）よりも永続的で、 ブラウザがクロスサイトコンテキストで送信しない場合があるクッキーよりも 信頼性が高いです。

ブラウザストレージフィンガープリンティングは合法なのか？

EUのGDPRの下では、localStorageやIndexedDBに保存されたデバイス識別子を 含む、個人を識別するために使用できるデータは個人データを構成します。 2025年1月の英国情報コミッショナーオフィス（ICO）のドラフトガイダンスでは、 localStorage、sessionStorage、IndexedDBがクッキーと同じPECRルールの対象であり、 インフォームドコンセントまたは限定的な正当利益の正当化が必要と明示されました。 フランスのデータ保護当局（CNIL）も同様の結論に達し、ブラウザストレージを 事前同意要件の対象となるトラッキングベクターとして名指ししました。 米国のCCPAおよびCPRAの下では、ストレージベースのデバイス識別子は オプトアウト権を持つ個人情報として扱われます。

日本では、個人情報保護法（APPI）が適用されます。 ストレージデータが個人を識別できる場合、その収集と利用目的を 本人に通知・公表し、目的外での利用は禁止されています。2022年の改正では、 Cookie等の識別子を使ったターゲット広告への対応が強化されており、 個人関連情報として第三者提供時に本人同意が必要なケースも生じています。 グローバルでは執行が一貫していませんが、規制の方向は明確です： 開示なしのストレージトラッキングは、バナーのないクッキートラッキングと 法的に同等です。

W3C フィンガープリンティングガイダンス はlocalStorageスタイルの永続性を「クッキーライクフィンガープリンティング」 — トラッキングの最も直接的なカテゴリ — に分類し、仕様の作成者が スクリプトで利用可能なフィンガープリンティングサーフェスを減らすために ストレージAPIをどのようにパーティショニングまたは制限できるかを 考慮することを推奨しています。

ブラウザストレージフィンガープリンティングから自身を保護する方法

ハードウェアフィンガープリンティングとは異なり、ストレージフィンガープリンティングは 構造的に無力化できます — ただし、単に履歴をクリアするのではなく、 ブラウザレベルのコントロールが必要です。

• Total Cookie Protection を有効にする（Firefox）：FirefoxのEnhanced Tracking ProtectionのStrict modeは状態パーティショニングを 有効にします — 各ウェブサイトが独自の分離されたストレージバケットを 持ちます。foo.com内で設定されたトラッカーのlocalStorageエントリーは、 同じトラッカーがbar.com内でロードされても読み取れません。これはクロスサイト ストレージトラッキングに対する最も効果的な保護であり、標準モードでは 既知のトラッカーに対してFirefoxでデフォルトで有効になっています。
• Safariを使用する（ITMを持つ任意のバージョン）：SafariのIntelligent Tracking Prevention（ITP）は、localStorage、IndexedDB、 Cache API、BlobURLストレージをトップレベルサイトでパーティショニングし、 7日間ユーザーインタラクションがないオリジンのストレージデータを積極的に 削除します。ストレージベースのクロスサイトトラッキングはデフォルトで 構造的にブロックされます。
• Braveブラウザを使用する： Braveはデフォルトで フィンガープリンティングをブロックし、ストレージパーティショニングを 適用し、サイトごとのカスタマイズを可能にします。Shieldsパネルで 許可するトラッキングベクターを詳細に制御できます。
• クッキーだけでなく、すべてのサイトデータをクリアする：ブラウザ履歴の削除は通常クッキーをクリアしますが、localStorageと IndexedDBはそのまま残ります。ChromeとFirefoxでは、開発者ツール （アプリケーションタブ → ストレージ → サイトデータのクリア）または 「閲覧データの削除」メニューで「キャッシュされた画像、クッキー、 その他のサイトデータ」オプションを使用してすべてのストレージを 同時にクリアします。
• コンテナ拡張機能を使用する（Firefox マルチアカウントコンテナ）： Firefoxコンテナーは各コンテナーのストレージを他のすべてのコンテナーから 分離します。一つのコンテナーでソーシャルメディアを実行し、別のコンテナーで 一般ブラウジングを行うと、ソーシャルトラッカーが一般ブラウジング中に 設定されたlocalStorage値を読み取ることを防ぎます。
• Torブラウザ（最強の保護）： Torブラウザは「新しいアイデンティティ」 アクションのたびにすべてのストレージをクリアし、ストレージパーティショニングを 適用し、すべてのTorユーザーが共有する均一なブラウザプロファイルを使用します。 上記のIndexedDB順序脆弱性（CVE-2026-6770）はバージョン15.0.10以前の Torブラウザに影響を与えたことに注意してください；Torを使用している場合は 現行バージョンに更新してください。
• サードパーティiframe / JavaScriptを選択的に無効にする：ほとんどのクロスサイトストレージトラッキングはiframe内でロードされた サードパーティスクリプトを通じて機能します。中程度モードのuBlock Originは、 サードパーティスクリプトの読み込みを完全に防ぐことで、これらのベクターの ほとんどをブロックします。これは最も攻撃的なアプローチで、一部の 埋め込みコンテンツが壊れます。

よくある質問

クッキーのクリアはストレージフィンガープリンティングを防ぐのに十分ですか？

いいえ。クッキーのクリアは最小限のステップであり、完全な解決策ではありません。 ストレージフィンガープリンティングは意図的に識別子をlocalStorage、 sessionStorage、IndexedDB、クッキーに同時に分散させます。クッキーだけを クリアすると、他の3つのベクターに識別子が残ります。次の訪問時に、 トラッカーは残存するコピーを読み取りクッキーを再書き込みします。 ストレージベースの識別子を削除するにはすべてのサイトデータ — クッキーだけでなく — をクリアする必要があり、それでも次にサイトを訪問するとトラッカーは 識別子を再作成します。

シークレット/プライベートモードはストレージフィンガープリンティングから保護しますか？

部分的に。プライベートモードは、プライベートウィンドウが閉じられると 完全に消去される新鮮で分離されたストレージコンテキストを作成します。 プライベートセッション中に書き込まれたlocalStorage、IndexedDB、クッキーは メインプロファイルに残りません。ただし、単一のプライベートセッション内では、 ストレージフィンガープリンティングは通常通り機能します。トラッカーは 同じプライベートウィンドウ内の複数のタブにまたがってあなたを識別できます。 クロスセッション保護については、プライベートモードは効果的ですが、 GPUやフォント、キャンバス出力がプライベートモードと通常モードで同一であるため、 ハードウェアレベルのフィンガープリンティングから保護するものではありません。 ハードウェアシグナルがより無力化しにくい理由については キャンバスフィンガープリンティングガイド をご覧ください。

localStorageとsessionStorageの違いは何ですか？

両APIは同じインターフェース（setItem、getItem、removeItem）を公開していますが、永続性が異なります。 localStorageは明示的にクリアされるまで永続し、ブラウザの再起動を超えて 残り、同じオリジンのすべてのタブで共有されます。sessionStorageは 現在のタブに分離されており、タブを閉じると自動的に削除されます。 トラッキングの観点から、localStorageは複数のセッションにまたがって 残存するためより高価値なベクターです。sessionStorageは主に長期識別ではなく、 単一のユーザージャーニー内のページビューをリンクするために使用されます。

IndexedDBがトラッキングにとってlocalStorageよりも危険なのはなぜですか？

IndexedDBは構造化データとより大きなストレージクォータ（localStorageの 数メガバイトに対して通常は利用可能なディスクスペースの80%）をサポートします。 さらに重要なことに、2025年のIndexedDB順序脆弱性は、IndexedDBがトラッキング データを読み書きすることなくサイドチャネルとして悪用できることを示しました — データベース名の内部順序付け自体が、関連のないオリジンが観察できる 安定した識別子でした。localStorageには同等の構造的に導出されたサイドチャネルが ありません。この脆弱性はFirefox 150とTor Browser 15.0.10でパッチが 当てられました。

VPNはブラウザストレージフィンガープリンティングを防ぎますか？

いいえ。VPNはトラフィックを暗号化されたトンネルを通じてルーティングし、 可視IPアドレスを変更しますが、ブラウザのストレージにはアクセスできません。 ブラウザで実行されるJavaScriptはlocalStorageとIndexedDBを完全にローカルで 読み書きします — 読み取りステップにはネットワークトラフィックは関与しません。 VPNはIPベースのジオロケーショントラッキングに対しては効果的ですが、 ストレージベースまたはハードウェアベースのフィンガープリンティングに対しては まったく保護を提供しません。VPNが正常に機能しているか whatsmy.fyi で確認してください。

ストレージフィンガープリンティングはキャンバスやWebGLフィンガープリンティングとどう関係していますか？

ストレージフィンガープリンティングと キャンバスフィンガープリンティング はトラッキングスペクトルの両端を表しています。ストレージフィンガープリンティングは 「クッキーライク」です — デバイスに何かを書き込んで読み取ります。 キャンバスと WebGLフィンガープリンティング は「ステートレス」です — 何も保存せずにハードウェア特性からあなたの 身元を再構築します。商業トラッキングプラットフォームは両方のアプローチを 重ね合わせます：ストレージは高速で安定したIDを提供し、ハードウェア フィンガープリンティングは完全なストレージワイプ後でもあなたを 再識別できます。この組み合わせは、いずれかの技術単独よりもはるかに 耐性があります。

GDPRの下でlocalStorageフィンガープリンティングは合法ですか？

GDPRとPECR（英国）の下では、localStorage、sessionStorage、IndexedDBを 通じたものを含む、ユーザーのデバイスへのアクセスまたは情報の保存には、 インフォームドコンセントまたは限定的な正当利益の正当化が必要です。 英国ICOの2025年1月のドラフトガイダンスはこれらのAPIがクッキーと 同じルールの対象であることを明示的に名指ししました。実際には、多くの 小規模パブリッシャーがクッキーバナーが満たす法的要件をこれらのメカニズムが 回避できると想定して、開示なしにlocalStorageベースのトラッカーを展開します。 その前提は次第に誤りとなっており、執行措置はすべてのストレージベースの トラッキングをクッキートラッキングと一貫して扱い始めています。

関連記事

• ブラウザフィンガープリンティングとは？クッキーなしでサイトがあなたを追跡する方法 — ストレージとハードウェアベクターの両方を含む、すべてのフィンガープリンティング シグナルと組み合わせ方についての完全ガイド
• キャンバスフィンガープリンティングとは？クッキーなしでウェブサイトがあなたを追跡する方法 — HTML5 Canvas APIがGPUとフォントレンダラーからデバイス固有のピクセルハッシュを 生成する方法
• WebGLフィンガープリンティングとは？GPUがどのようにブラウザを識別するか — 3DグラフィックスAPIがGPUベンダー名、モデル、ドライバーバージョンを 公開する方法
• オーディオフィンガープリンティングとは？AudioContextがブラウザを追跡する方法 — デバイスのオーディオ処理スタックがハードウェアレベルの識別子を生成する方法