フィンガープリントフラグ

アイデンティティは Chromium のコマンドラインスイッチで制御します。SDK は名前付きオプションからこれらのスイッチを設定します。オープンビルドでは、自前のランチャーに args として渡すこともできます。

ほとんどのスイッチはどちらのビルドにもあります。一部はライセンスビルド（「GitHub で無料」または Pro）専用で、下のスイッチ一覧では、そうしたスイッチに、追加されたエンジンリビジョンを併記しています。ライセンスキーがなければ SDK はオープンビルドで動作し、そこではこれらのオプションは効果を持ちません。

シードモデル

すべての起点は --fingerprint=<seed> です。シード（整数または任意の文字列）からペルソナが決定論的に導出され、さらに後述のファーブリングの対象に挙げた 2 つのレンダリングサーフェスにノイズが加わります。

ライセンス版 Chromium 156 ビルド（r51）以降、この導出は Clearcote のペルソナサービスで行われます。ランチャーは起動のたびにライセンスの実行トークンを添えて問い合わせ、署名付きペルソナをブラウザに渡します。ペルソナがなければブラウザは起動を拒否します。同じシードなら r50 と同じアイデンティティになります。オフラインライセンスは、オフライン用ペルソナパックが用意されるまで r50 のままです。

• 同じシード ⇒ 同じアイデンティティ。同じマシン、同じブラウザバージョンであれば何度起動しても変わらないので、再訪問者として見えます。ページが読み取れるものはすべて同じ値が返ります。GPU、画面、ハードウェア、フォント、音声、そして canvas、WebGL、オーディオの結果です。唯一の例外は接続速度の推定値（navigator.connection のラウンドトリップ時間と帯域幅）で、これは Chrome と同じく実際のネットワークに従います。
• 新しいシード ⇒ 新しい、もっともらしいアイデンティティ。
• canvas と WebGL のノイズはサイトごとに導出されます。Brave の farbling（ファーブリング）に着想を得た方式で、これらのハッシュはドメインごとに異なります。一方、ペルソナ自体（GPU、画面、ハードウェア、フォント）は、実在する 1 台のマシンと同じく、どのサイトでも同じです。

別のマシンで同じシードを使う場合

ペルソナが名乗るグラフィックスカードは、マシンが実際に描画に使っているカードと同じメーカー（NVIDIA、Intel、AMD）のものです。そのため、ページが計測するピクセルやグラフィックスの上限値は、ページに伝えられるのと同じ種類のカードのものになります。グラフィックスカードのないマシンでは、ペルソナは内蔵グラフィックスを名乗ります。154 r37 以降は Intel または AMD のもの、r36 では Intel のものだけです。つまり、カードのメーカーが異なるマシンでは、同じシードでも報告されるグラフィックスカードが異なります。これは意図した動作です。

154 r36 以降のライセンスビルドでは、マシンのグラフィックスのメーカーによって、ハードウェアのほかの部分も変わることがあります。エントリーレベルのコンピューターには専用のグラフィックスカードは付いていないため、NVIDIA のカードを搭載したマシンでは、エントリーレベルのハードウェア（プロセッサーのスレッド数 4〜6、メモリ 4〜8 GB、小さな画面）を名乗るはずのシードが、代わりにミドルレンジ以上のハードウェアを名乗り、タッチスクリーンを名乗ることもありません。そのため全シードのおよそ半数は、NVIDIA のマシンと、Intel や AMD のマシン、またはグラフィックスカードのないマシンとで、報告するプロセッサーのスレッド数とメモリが異なり、一部は画面サイズも異なります。グラフィックスのメーカーが同じマシン同士であれば、シードのアイデンティティは同じです。

154 r37 以降、各メーカーのマシンがグラフィックスカードを選ぶ候補の範囲は、実際のブラウザトラフィックをもとにしています。各モデルは実環境で見かけるのと同じ確率で選ばれるため、ペルソナの一群は実在するマシンの一群のように見えます。そのため、ほとんどのシードは r37 では r36 とは異なるカードを名乗ります。ハードウェアのほかの部分は、r36 と同じように導出されます。

2026-10-26 以降（r52。ペルソナサービスがアイデンティティを導出するため r51 での起動も同様）、デフォルトはペルソナスキーマ 7 です。グラフィックスカードがマシンの種類を決めます。ノートかデスクトップか、プロセッサーの世代、スレッド数、メモリ、画面で、画面にはノートパソコンで実際に使われている表示スケールも含まれます。シードからは、その日付より前とは異なるマシンが導出されます。

マシンが変わっても 1 つのシードで同じアイデンティティを保つには：

• グラフィックスのメーカーが同じマシンで実行します。たとえば本番環境では 1 種類のサーバーに揃えます。
• グラフィックスのメーカーを固定します。ランチャーの args に --fingerprint-gpu-host-vendor=nvidia（または intel、amd）を渡すと、ペルソナはどこで実行しても、そのメーカーのカードを搭載したマシン上と同じようにアイデンティティを導出します。固定するのは、そのペルソナを主に実行するマシンのメーカーにしてください。カードのメーカーが異なるマシンでは、名乗るカードと実際に描画するカードが一致しなくなります。
• r45〜r51 で作成したアイデンティティを維持します（2026-10-26 より前）。persona_schema=5 / personaSchema: 5（--fingerprint-schema=5）を指定します。154 r37〜155 r44 で作成したものは persona_schema=4 / personaSchema: 4 です。どちらのスキーマも凍結されているため、これらではシードが今後もずっと同じアイデンティティを導出します。
• 154 r36 で作成したアイデンティティを維持します。persona_schema=3 / personaSchema: 3（--fingerprint-schema=3）を指定すると、どのシードも r36 とまったく同じ値を、グラフィックスカードも含めてフィールド単位で導出します。
• r36 より前に作成したアイデンティティを維持します。persona_schema=2 / personaSchema: 2（--fingerprint-schema=2）を指定すると、どのシードも 153 r29〜154 r35 とまったく同じ値を、フィールド単位で導出します。グラフィックスカードは引き続きマシンのメーカーに従いますが、ほかのハードウェアは従いません。

シードがなければ、ペルソナごとのアイデンティティはありません。同じ種類のマシンでは、どの起動も同じように見えます。アイデンティティごとに別々のシードを割り当ててください。

シードから合成したアイデンティティより、実在するマシンのアイデンティティを使いたい場合は、コレクターでドナーとなる Chrome の値を取得し、シードの代わりに --fingerprint-profile=<gzip+base64 JSON> でインポートします（SDK の fingerprint_profile / fingerprintProfile オプションを使えば、gzip+base64 への変換は SDK が行います）。プロファイルに含まれるフィールドはブラウザが本来報告する値より優先され、含まれないフィールドはブラウザのデフォルト値にフォールバックします。プロファイルと一緒に --fingerprint シードを渡さないでください。シードは canvas にノイズを加え、実機の値と並んだそのノイズは厳格なスコアリングで改ざんと判定されます。アイデンティティはプロファイルがすでに提供しています（プロファイルと永続化を参照）。インポートしたプロファイルはどちらのビルドでも読み込めます。ライセンスビルドでは 151 r19 以降、全面的に適用されます。取得したプロファイルを SDK からインポートする方法は Playwright ガイドを参照してください。

ファーブリングする対象と、あえてしない対象

サーフェスにノイズを加えると、紐付けされにくくなる代わりに整合性が損なわれます。このトレードオフは、どこでも割に合うわけではありません。Clearcote がファーブリングするのは、ノイズが通常のハードウェア由来のばらつきに最も近くなる 2 つのサーフェスだけで、それ以外にはノイズを加えません。それらのサーフェスでは、ノイズを加えた値のほうが、プロファイル間で共有される値よりも目立つシグナルになるからです。ただし、ノイズを加えないことは、何も手を加えないことと同じではありません。いくつかの値は、ペルソナの値に丸ごと置き換えられます。詳しくは下の表とその下の注記で説明します。チェッカーの中には、ノイズそのものを検知できるものもあります。それが問題になる場合は、fingerprintNoise: false でノイズをオフにし、アイデンティティはそのまま維持できます（検知の仕組みを参照）。

マルチアカウント運用で実際に意味するのは次の点です。canvas と WebGL はアイデンティティを分離しますが、レンダリングされたオーディオとクライアント矩形は分離しません。これらは土台にあるマシンの性質です。同じホストは、どのシードを読み込んでも同じオーディオパイプラインで描画し、同じフォントと同じピクセル比でテキストをレイアウトします。同一のハードウェアを使う別々の 2 人の場合とまったく同じです。対象サイトがまさにこれらの値で紐付けを行うなら、解決策は別のスイッチではなく、マシンを分けることです。

知っておきたい例外が 1 つあります。AudioContext の 3 つのスカラー値はペルソナに従います。sampleRate、baseLatency、outputLatency は、ペルソナが有効なとき（--fingerprint シードまたはインポートしたプロファイルがあるとき）は常にペルソナから返されます。そのため、ホストのオーディオバックエンドをさらすことなく、アイデンティティごとに異なる値になります。どちらも設定していなければ、3 つとも実機の値がそのまま返ります。ページが明示的に要求したサンプルレートは引き続き尊重され、outputLatency も従来どおり Chrome 自身の権限依存の量子化を経由します。153 r26 以降は、baseLatency がページの要求するレンダーサイズにも追従し、まだレンダリングを始めていないコンテキストは通常の Chrome と同じレイテンシを報告します。

ノイズが加わる場所（r57）

ライセンス版ビルドでは r57 から、canvas と WebGL の読み出しノイズは、上下左右 4 つの隣接ピクセルのどれも同じ色でない場合にだけピクセルを変更します。単色の図形、塗りつぶしたブロック、クリアした背景といった平坦な領域は、実機と同じく描いたとおりに読み出されます。文字の輪郭、曲線、グラデーションには引き続きシードのノイズが加わるため、プロファイルごとの canvas ハッシュは異なったままです。r57 より前は読み出し内の平坦な領域にもノイズが加わっていたため、単色の図形を描いてハッシュを取るチェッカー（PixelScan の「Masking detected」）は、ピクセルが変更されたことを証明できました。

WebGL の部分的な readPixels（canvas より小さい矩形）は、そのすぐ外側のピクセルを参照できません。そのため既定では、エンジンが矩形とその周囲 1 ピクセルのマージンを 1 回の GPU 読み出しでまとめて読み、端のピクセルにも canvas 全体を読んだときとまったく同じノイズが加わるようにします。読み出しにかかる時間は Chrome と同じです。

どちらの設定も、ページがピクセルを読むすべての方法（getImageData, toDataURL, toBlob, readPixels）に適用されるため、同じ canvas の読み出しは常に一致します。r57 より前のエンジンは常に flatAreaNoise: true と同じ動作をし、SDK と Profile Manager はそこでは両方の設定を送りません。Docker では CC_FLAT_AREA_NOISE と CC_WEBGL_READ_MARGIN を設定します。これらの設定は SDK 0.68.8 と Profile Manager 0.40.0 から使えます。

整合性のある二次サーフェス

ノイズを加えるシグナルとは別に、エンジンはペルソナの二次的なサーフェスを、そのペルソナのプラットフォームで動く実際の Chrome と一致させます。SDK はプラットフォームのデフォルトをホストの OS にします。以下の Windows 固有の値は Windows ペルソナに適用されます。

• WebGL の制限値（WebGL1 + WebGL2）は、このマシンで裏付けられる範囲でペルソナの GPU に従います。実際のドライバが課す上限より高い値を報告することはないため、ソフトウェアレンダラーでは一部の値が、名乗っている GPU の値より低くなります。
• UNMASKED_RENDERER / UNMASKED_VENDOR はセッション中一定です。オリジンごとに変わって手がかりになるのではなく、ペルソナに従った 1 つの GPU をすべてのサイトで報告します。
• navigator.getBattery() は AC 電源につながったデスクトップ（充電中、level 1.0、放電なし）を、navigator.connection は家庭用回線のプロファイル（effectiveType 4g、丸めた rtt/downlink、saveData オフ）を報告します。
• navigator.keyboard.getLayoutMap() は US-QWERTY のマップを返し、Windows ペルソナでは AudioContext が Windows のオーディオスタックのサンプルレートとレイテンシを報告します。
• ライトかダークか：154 r32 以降、ペルソナはどちらか一方のカラースキームを好みます（およそ 3 つに 1 つがダーク。--fingerprint-color-scheme=light|dark で選べます）。prefers-color-scheme、matchMedia、Sec-CH-Prefers-Color-Scheme ヘッダー、CSS のシステムカラーは、すべてこれと一致します。そのようなビルドでは SDK（0.41.0+）が Playwright のカラースキームのエミュレーションをオフのままにするため、これと矛盾するものはありません。
• フォント：Windows ペルソナでは、テキストの行の高さと一般的なフォントの文字幅が Windows マシンと同じになり、ページが名前で要求したフォントも Windows と同じように振る舞います（154 r32）。マシンにインストールされた本物のフォントは、そのフォント自身として使われます。Linux では、fontDirs で独自のフォントを指定してください。
• window.getScreenDetails() は整合性のある単一のモニターを報告し、@media (pointer: fine) / (hover: hover) はマウスを使うデスクトップと一致します。
• URL：Windows ペルソナでは new URL("C:/").protocol が file: を返します。153 r26 以降は、ページが URL を組み立てるどの方法でも同じ結果になります。navigator.share / canShare は Windows の UA に合わせて公開されます。
• WebGPU：navigator.gpu のアダプタ情報と limits/features は、WebGL と同じ GPU に従います（ライセンスビルドでは、ホストが実際に提供できる範囲に絞り込まれます）。
• ロケール：Accept-Language、navigator.language、navigator.languages のリスト全体、Intl（メインスレッドとワーカー）は、すべて 1 つのリスト（acceptLanguage または geoip）から決まります。SDK は --accept-lang と --lang を自動で設定します。スイッチを直接指定する場合は両方を渡してください。
• 音声合成：speechSynthesis はペルソナの音声セットを返します。これには、そのバージョンの Chrome が列挙する Google のネットワーク音声も含まれます（153 r27）。fingerprintVoices: false を指定すると、代わりにマシン自身の音声を使います（152 r22）。
• ハードウェア：プロセッサ速度の値（navigator.cpuPerformance）は実際のプロセッサではなくペルソナに従い（152 r20）、スクリプトのメモリ上限（performance.memory.jsHeapSizeLimit）はペルソナが名乗るメモリ量に従います（153 r26）。
• コーデックとデバイス：MediaCapabilities.decodingInfo() はペルソナのコーデック対応表を、enumerateDevices() はペルソナのメディアデバイス一式（シードごとに固定の ID、権限付与前は空のラベル）を報告します。
• UA-CH の高エントロピー値：bitness=64 / wow64=false / model。Linux ペルソナでは、本物の Chrome が Linux で返すのと同じく platformVersion は空です（153 r26）。storageQuota を設定すると、navigator.storage.estimate() は現実的なディスク容量のクォータを報告します。

実験的機能：実 GPU による Canvas ブリッジ

オプションで、canvas / WebGL の操作をリモートの実 GPU ホストに転送できます。これにより、読み出し結果（getImageData / toDataURL / readPixels / measureText）が、提示している GPU と整合します。ローカルではその GPU の描画を再現できないハードウェアでも同じです。転送するのは操作そのもの（事前に記録した画像ではありません）なので、既知のプローブに限らず、ほとんどの canvas に対応できます。有効にするには --canvas-bridge-url=ws://host:port（と --no-sandbox）を指定します。未設定なら、これまでどおり完全にローカルで動作します。レンダーサーバーは実 GPU ホスト上のブラウザ（CDP 経由の通常の Chrome、またはヘッドレスの Clearcote）を操作します。セットアップの全手順は Canvas ブリッジのガイドを参照してください。

ネイティブのメタデータ上書きと light_stealth

シードから導出するペルソナとは別に、ネイティブの個別値上書きを使うと、navigator/screen の個々の値を直接偽装できます。対象は hardwareConcurrency、deviceMemory、colorDepth、devicePixelRatio、maxTouchPoints、そして（オプトインで）screen/avail* の各寸法です。どの値も各 getter が直接読み取り、優先順位はフラグ > --fingerprint ペルソナ > 実ホストです。そのため、ハードコードした値はどのシードよりも優先され、上書きは --fingerprint シードの有無にかかわらず機能します。ペルソナの仕組みは使いません。

SDK は、その軽量なサブセットを 1 つのフラグ light_stealth にまとめています。これは、整合性のある少数のメタデータバンドル（hardwareConcurrency、deviceMemory、colorDepth、devicePixelRatio、maxTouchPoints）から 1 つを、これらのネイティブスイッチだけで適用するものです。シードはどのバンドルを使うかを選ぶだけで、エンジンには渡されません。そのため canvas や WebGL のノイズはなく、同じマシン上の light_stealth セッションはすべてホストの canvas ハッシュを共有します。これらを区別する必要がある場合は、lightStealth を使わずに、アカウントごとの fingerprint シードを使ってください。TLS ClientHello と実際のブラウザバージョンは変わりません。screen の寸法は、デフォルトではあえて偽装しません（screenWidth などでオプトイン）。実際の描画サーフェスと辻褄の合わない偽の画面は見破られやすいためです。スケーリングなしのディスプレイでは、選ばれた devicePixelRatio がそのディスプレイに合っているか確認するか、自分で設定してください。明示的に指定したオプションは常にプリセットより優先されます。

import { launch } from "clearcote";
// one coherent metadata bundle; "my-seed" only picks which one — no seed reaches the engine, so no canvas noise:
const browser = await launch({ lightStealth: true, fingerprint: "my-seed" });

// or set individual values by hand (no --fingerprint needed):
const b2 = await launch({
  hardwareConcurrency: 8,
  deviceMemory: 8,
  devicePixelRatio: 1.25,
  maxTouchPoints: 0,
});

全スイッチ一覧

名前や効果で絞り込んだり、1 つのサブシステムに限定したりできます。スイッチをクリックすると、その働きと、有効な最短の書き方を確認できます。

使用例

以下はコマンドラインフラグをそのまま並べたものです。Python と Node の完全なワークフローは使用例を参照してください。

整合性のとれた、完全な Windows アイデンティティ：

--fingerprint=acme-tenant-7 \
--fingerprint-platform=windows \
--fingerprint-brand=Chrome \
--accept-lang=en-US,en \
--lang=en-US \
--timezone=America/New_York \
--fingerprint-hardware-concurrency=8

GPU 文字列をカスタマイズした Windows アイデンティティ（Windows の ANGLE が報告する形式）：

--fingerprint=42 \
--fingerprint-platform=windows \
--fingerprint-gpu-vendor="Google Inc. (NVIDIA)" \
--fingerprint-gpu-renderer="ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 (0x00002504) Direct3D11 vs_5_0 ps_5_0, D3D11)"

これらの文字列が変えるのは報告される内容であって、描画そのものではありません。ピクセルは引き続きこのマシンの GPU から得られます。実際に描画に使う GPU を指定するか、Canvas ブリッジを使ってください。macos プラットフォームは、オープンビルドではアイデンティティ文字列（UA、Client Hints、navigator.platform）だけを変更します。ライセンスビルドでは 155 r47 以降、実在する Mac を表現し、チップ、スレッド数、メモリ、画面、グラフィックスレンダラー、macOS のバージョン、音声が互いに整合します。また、android はベストエフォートのモバイルペルソナです。

位置情報と時計が一致するよう、位置とタイムゾーンをセットで固定します：

--fingerprint=nyc-1 \
--timezone=America/New_York \
--fingerprint-location=40.7128,-74.0060

実機の値をインポートする

合成したシードの代わりに、実際の Chrome が報告した値をそのまま報告させることもできます。対象は GPU 文字列と getParameter のテーブル、画面、フォント、音声、オーディオです。置き換わるのは値だけで、描画は引き続き自分のマシンが行います。そのため、プロファイルで 2 つのアカウントの canvas を別々にすることはできません。それができるのはアカウントごとの --fingerprint シードです。両方ではなく、どちらか一方を使ってください。実機の値にはプロファイル、アカウントごとの描画の分離にはシードです。プロファイルは、厳選された clearcote-profiles ライブラリ（GPU ベンダーのタグ付きで、実機のプロファイルが数千件）から入手するか、コレクターで自分で取得し、読み込んだうえで読み込まれたことを確認します：

import { launch } from "clearcote";
// path to a captured .json profile, a profile object, or a JSON string
const browser = await launch({ fingerprintProfile: "./real-machine.json" });
// fields present in the profile override what the browser would report;
// absent fields keep the browser's defaults. Pass no fingerprint seed alongside a profile.

取得の流れ：複製したい実際の Chrome でコレクターのページを開き、JSON を書き出して、fingerprintProfile（SDK）/ --fingerprint-profile（エンジン）で渡します。検証には tools/fingerprint-collect/verify_profile.py を使います。

各パッチの役割

オープンビルドの各スイッチは、それぞれ中身を読めるエンジンパッチに対応しています。差分は patches/ にあり、各パッチの 1 行要約は patches/README.md にあります。「ライセンスビルド」と記載されたスイッチは、ライセンスビルド独自のパッチセットによるもので、こちらは公開されていません。

個々の値よりも整合性のほうが重要です。プラットフォーム、タイムゾーン、ロケール、GPU が組み合わせとしてもっともらしくなるようにしてください。エンジンがそれらをどう一貫させているかはアーキテクチャを、なぜこれが JavaScript による偽装より優れているかは検知の仕組みを参照してください。