私たちが発見したのは、あなたのすべてのプライベートな Tor アカウントを相互に結びつける安定した Firefox の識別子です。

日本語訳:

元のサマリーは優れている—it は簡潔で明瞭であり、主要ポイントリストからのすべての主要ポイントを余計な冗談抜きに捉えている。

サマリー:

Firefox ベースのブラウザには、プライバシー上重大な欠陥があり、ウェブサイトがプライベートモードであってもユーザーを一意に追跡できるようになっています。この問題は、

IndexedDB

（ブラウザの保存システム）がデータをどのように順序付けるかという仕組みから生じており、これは永続的な「指紋」を作り出します。この順序付けはブラウザを完全に再起動するまで安定するため、異なるウェブサイトにおいて同様のパターンを観測し、従来のクッキーを使用せずにユーザーのウェブサイトの活動同士をつなげることを可能とします。この脆弱性は、セッションデータを閉じた後で消えるかリセットすると期待して匿名性を維持するためにユーザーが依存している Tor の「新しいアイデンティティ」機能のようなプライバシー保護措置を効果的に回避します。

この欠陥がすべての Firefox 派生版で共有される

Gecko

エンジンに存在することに気づいた Mozilla は、最近のバージョン向けの緊急修正をリリースしました。解決策はデータベースリストの表示方法を標準化し、追跡を可能とした内部の保存パターンを取り除きます。その結果、ユーザーはこれらの指紋を完全にクリアするためにブラウザを再起動する必要があります。それまでの間、プライベートブラウジングモードの信頼性が損なわれ、無関係なウェブサイトがユーザーの一貫したクロスサイト行動を識別できないという根本的な信頼が破られます。

近日、Firefox 系ブラウザに広く影響するプライバシー関連の脆弱性を発見しました。本問題により、IndexedDB から返されるエントリの順序から、ユーザがより強い分離を期待する文脈であっても、プロセスライフサイクル固有の一意で決定論的かつ安定した識別子を導出可能となっています。

すなわち、ウェブサイトは IndexedDB データベースの集合を作成し、返却される順序を確認することで、実行中のブラウザプロセスに対する指紋（フィンガープリント）としてその順序を利用できます。本振る舞いは origin（オリジン）スコープではなくプロセススコープであるため、関連のないウェブサイトが互いに独立して同一識別子を観測し、同じブラウザランタイムにおいてクロスオリジンの活動を追跡・連結することが可能です。Firefox Private Browsing モードでは、プライベートウィンドウがすべて閉じられたとしても Firefox プロセスが実行状態にある限り、識別子は保持され続けます。Tor Browser についても、「New Identity」機能（クッキーや閲覧履歴をクリアし、新しい Tor サーキットを使用する完全リセットと位置づけられています）を行っても安定した識別子が持続することから、ユーザが目指す「前の活動との無関係性を保証する」という設計意図を事実上無効化します。この脆弱性は、ユーザが依存している unlinkability（関連付けの不可能性）に関する分離保証を根本的に損なうものです。

我々は、Mozilla および Tor Project に対して責任ある公開を行い対応しました。Mozilla は迅速に対応し、Firefox 150 と ESR 140.10.0 でパッチを展開しており、詳細は Mozilla Bug 2024220 で追跡されています。根本原因は Gecko の IndexedDB 実装に由来するものであり、そのため Tor Browser も同様に影響を受け、すべての Firefox 系ブラウザに共通する問題となります。

対応策の原理面ではシンプルです：ブラウザは、プロセススコープの状態を反映する内部ストレージの順序を公開すべきではありません。結果を返す前に正規化（例：辞書式ソート）またはソートを行うことでエントロピーを取り除き、当該 API が安定した識別子として機能することを防止できます。

なぜこれが重要なのか

プライベートブラウジングモードやプライバシー重視のブラウザは、ウェブサイトによるユーザの特定を異なる文脈を超えて行う能力を減じることを目的としています。ユーザ一般には以下の二点について期待されています：

共有ストレージまたは明示的なアイデンティティ機構が関与しない限り、関連のないウェブサイト同士は、同一のブラウザインスタンスとやり取りしているかどうかを判別できないはずです。
プライベートセッションが終了した際、当該セッションに関連する状態は消滅する必要があります。

本問題はこの二つの期待をすべて崩壊させます。ウェブサイトにはクッキー、localStorage、あるいは明示的なクロスサイト通信チャンネルを必要とせず、ブラウザ自身の内部ストレージの振る舞いに依存して、API で返却されるデータベース名の順序から大容量の識別子を導出すれば十分です。

開発者の方へ：プライバシーに関するバグが常に直接の特定データへのアクセスから生じるわけではないことを示す有用な教訓となります。ときに、内部実装詳細の決定論的な暴露から生じます。
セキュリティおよび製品利害関係者の方へ：核心は単純です：一見無害な API でも、安定したプロセスレベルの状態を漏らすと、クロスサイトトラッキングのベクトルとして機能し得ます。

IndexedDB と

indexedDB.databases()

は何ですか？

IndexedDB はクライアント側で構造化データを保存するためのブラウザ API です。Web アプリケーションはオフライン対応、キャッシュ、セッション状態、およびその他のローカルストレージ要件のためにこれを活用します。各オリジンは一つ以上の名前付きデータベースを作成でき、オブジェクトストアや大量のデータを保持できます。

indexedDB.databases()

API は、現在の実装において可見なデータベースに関するメタデータを受信者（origin）に返します。実際の運用では、開発者が既存のデータベースを点検、ストレージ使用量をデバッグ、またはアプリケーション状態を管理するためにこれを多用します。

通常のプライバシー期待に従うと、当該 API で返される結果の順序そのものが特定情報を運ぶべきではありません。データベースメタデータの中性な、正規化された、あるいは他の非機密性の表現を反映すべきです。今回発見された問題は、すべての Firefox 系ブラウザにおいて返却される順序が全くもって中立的ではないことに起因しています。

indexedDB.databases()

がなぜ安定した識別子となったか

すべての Firefox Private Browsing モードで、

indexedDB.databases()

はデータベースメタデータを、データベース作成の順序からではなく、内部ストレージ構造から派生した順序で返します。関連する実装は

dom/indexedDB/ActorsParent.cpp

にあります。

Private Browsing モードでは、データベース名が直接ディスク上の識別子として使用されません。代わりに、グローバルなハッシュテーブルを介して UUID ベースのファイル名ベースにマッピングされます：

using StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>;
StaticAutoPtr<StorageDatabaseNameHashtable> gStorageDatabaseNameHashtable;

マッピング処理は、

OpenDatabaseOp::DoDatabaseWork()

内で呼ばれられる

GetDatabaseFilenameBase()

内で実行されます。

aIsPrivate

が真である場合、ウェブサイトが提供するデータベース名は生成された UUID に置き換えられ、グローバルな

StorageDatabaseNameHashtable

に格納されます。このマッピングは以下の特性を持ちます：

キーのみでデータベース名の文字列によってインデックス化される
IndexedDB QuotaClient のライフサイクル全体に持続する
すべてのオリジン間で共有される
Firefox が完全に再起動された場合にのみクリアされる

その後、

indexedDB.databases()

が呼ばれると、Firefox は

GetDatabasesOp::DoDatabaseWork()

で呼び出される

QuotaClient::GetDatabaseFilenames(...)

によってデータベースファイル名を収集し、それらを

nsTHashSet

に挿入します。反復前にソートは実行されません。最終的な結果順序は、ハッシュセットの内部バケットレイアウトを反復することで決定されます。

UUID マッピングは Firefox プロセスのライフサイクル全体に安定しており、かつハッシュテーブル構造および反復順序が内部レイアウトに対して決定論的であるため、返却される順序は生成された UUID 値、ハッシュ関数の動作、ハッシュテーブル容量、挿入履歴という要素の決定論的な関数となります。この順序はタブ間、プライベートウィンドウ間でも維持され、Firefox の完全な再起動のみでリセットされます。重要なのは、UUID マッピングとハッシュセット反復がオリジンスコープではなくプロセススコープであることです。

問題の再現

簡潔な概念検証例だけでも振る舞いを示せます。異なる二つのオリジンが同一スクリプトをホストし、それぞれ：

固定されたセットの名前付きデータベースを作成する
```
indexedDB.databases()
```
を呼び出す
返却された順序を抽出して出力する

影響を受ける Firefox Private Browsing および Tor Browser ビルドでは、同じブラウザプロセスのライフサイクル全体にわたり両方のオリジンが同一の置換（permutation）を観測します。ブラウザを再起動すると置換は変化します。

概念的には出力はこのようになります：

作成時:

a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p

リストされた順序:

g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k

重要な点は、正確な順序そのものではなく、以下の事実です：

順序は元の作成順序と一致しない
関連のないオリジン間でも同一の順序が観測される
プライベートウィンドウがすべて閉じられた後でも、リロードや新しいプライベートウィンドウを開いた後も維持される
新しい順序を得るにはブラウザ全体を再起動する必要がある

これはプライバシー観点から望ましくない挙動です。

プライバシーへの影響

本問題により、単一のブラウザランタイム内でクロスオリジン追跡と同ソース追跡が両方可能になります。

クロスオリジンの影響

関連のないウェブサイトは互いに独立して同一識別子を導出でき、「同じ Firefox または Tor Browser プロセスとやり取りしている」と推測できます。これによりクッキーや他の共有ストレージを介さずにドメイン間での活動を連結することが可能になります。

同ソースの影響

Firefox Private Browsing モードでは、Firefox プロセス自体が実行状態にある限り、プライベートウィンドウがすべて閉じられた後も識別子は維持されます。つまり、サイトはあたかも新鮮なプライベートセッションであるように見える後続の訪問を認識できます。Tor Browser では、安定した識別子がブラウザプロセス内の「New Identity」による分離を事実上無効にし、本来互いに完全に隔離されるべきセッションをウェブサイトが連結することを可能にします。

なぜ Tor Browser で特に深刻なのか

Tor Browser は、クロスサイトリンク可能性を減らしブラウザインスタンスレベルのアイデンティティを最小化することを意図的に設計されています。安定したプロセスライフサイクル固有の識別子は、この設計目標に直ちに反します。たとえそれがプロセス再起動までしか持続しなくても、アクティブな使用時に unlinkability を弱めるのに十分です。

エントロピーとフィンガープリント能力

シグナルは単に安定しているだけでなく、高い容量を持ちます。サイトが N のデータベース名を制御する場合、観測可能な置換の数は N! であり、理論的エントロピーは log₂(N!) です。16 つの制御名の場合、理論空間は約 44 ビットです。これは実践的に存在する同時実行のブラウザインスタンス数を区別するのに十分以上の情報量です。

内部ハッシュテーブルの動作により到達可能な置換数が若干低下することはありますが、セキュリティストーリーに本質的な変更はありません。暴露された順序には、強力な識別子として機能するには十分に多くのエントロピーが提供されています。

対応策

適切な対応策は、内部ストレージレイアウトから派生するエントロピーを公開し続けることをやめることです。最もきれいな緩和策は、辞書式ソートなど正規化された順序で結果を返すことです。これは API の開発者利便性を維持しつつ、フィンガープリントシグナルを除去します。各呼び出しごとに出力をランダム化する手法でも安定した順序を隠せますが、ソートの方が単純で予測可能であり、開発者が論じやすい方法です。

セキュリティエンジニアリングの観点から、理想的な対応策は：

概念的に複雑さが低い
互換性リスクが最小限
プライバシーリークを直接的に排除する

というものでしょう。

責任ある公開

我々は、Mozilla および Tor Project に対して責任ある公開を行いました。Mozilla は Firefox 150 と ESR 140.10.0 で対応パッチを展開しており、詳細は Mozilla Bug 2024220 で追跡されています。この振る舞いは Gecko の IndexedDB 実装に由来するため、Tor Browser を含めた下流の Gecko ベースブラウザも独自の緩和策を適用しない限り影響を受けます。

プライバシーのための構築

この脆弱性は、小さな実装詳細が有意なプライバシー問題を生み出すことを示しています。影響は重大です。関連のないウェブサイトは同じブラウザランタイム内でクロスオリジンの活動を連結でき、識別子がユーザが予想するより長く残るためプライベートセッションの境界も弱体化します。

良いニュースは、対応策がシンプルで有効であることです。結果を返す前に正規化することで、ブラウザはこのエントロピー源を除去し、期待されるプライバシー境界を回復できます。これはまさに注目すべき問題の類型です：微妙であり見落としやすく、かつプライバシー敏感なブラウザ機能の開発にとって極めて示唆に富んでいます。