User-Agent 説明:UA、ブラウザフィンガープリンティング、そしてClient Hints

User-Agent解説:UA文字列やブラウザの指紋からClient Hintsまで

ブラウザの開発者ツールでネットワークパネルを開くと、ほとんどの場合User-Agentヘッダーが表示されます。簡単な導入のようです:どのブラウザがリクエストを行っているか、どのオペレーティングシステムで動作しているか、そしてどのバージョンだと主張しているか。

そのため、ヘッダーをデバイスIDとして扱ったり、一行変更でブラウザが別のデバイスに変わると考えたくなるのです。どちらの考えも部分的にしか正しくありません。

User-Agent文字列、またはUAはクライアントが宣言する互換性情報です。これは信頼できるアイデンティティ認証ではなく、クライアントはそれを変更できます。しかし、それは孤立して存在するものではありません。サイトはUAをClient Hints、JavaScript API、画面プロパティ、フォント、Canvas、WebGL、ネットワークコンテキスト、挙動と比較できます。したがって、有用な問いは単にUAが変更可能かどうかだけでなく、ブラウザの完全な観測可能な表面でどのような役割を果たすかです。

本記事では、HTTP標準とブラウザのフィンガープリンティング研究を用いて、4つの質問に答えます。

なぜUA文字列がブラウザの考古学の一片のように見えるのでしょうか?
UAどれだけの特定情報が貢献できるのか、そして研究をどのように解釈すべきか?
なぜ、UAだけを変えるだけでより明らかな矛盾が生じるのでしょうか?
UA ReductionとUser-Agent Client Hintsは実際に何を変えたのでしょうか?

この記事におけるUA主にHTTP User-Agentリクエストヘッダーを意味します。また、JavaScriptではnavigator.userAgentとnavigator.userAgentDataについても議論しています。これらのインターフェースは関連していますが、すべてのブラウザやコンテキストで恒久的に同一ではありません。

1. User-Agentとは何か?

RFC 9110 第10.1.5条は、User-Agentをリクエストを提出したユーザーエージェントに関する情報を含むフィールドとして定義します。その簡略化された文法は以下の通りです:

User-Agent = product *( RWS ( product / comment ) )
product    = token [ "/" product-version ]

簡単に言えば、文字列は製品名で始まり、バージョンを含むこともあります。さらに多くの製品やコメントを投稿できます。この標準は、相互運用性の回避策、診断、分析などの用途を認めていますが、実装において不要な詳細を明かさないよう推奨しています。より長く具体的なUAはリクエストサイズと指紋認証リスクの両方を増加させます。

現代のChromiumデスクトップUAは次のようなものかもしれません。

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/145.0.0.0 Safari/537.36

文字列をスペースで分割すると、Chromeとは無関係に見えるいくつかの名前が明らかになります。

トークン	今日の一般的な意味	よくある誤解
`Mozilla/5.0`	歴史的互換性トークン	ブラウザはFirefoxまたはMozilla製品でなければなりません
`Windows NT 10.0`	Windowsプラットフォームカテゴリー;約UAは Windows 10 と 11	を確実に区別できませんコンピュータは10
`Win64; x64`	x86-64アーキテクチャ上の64ビットWindowsであることのヒント	これは正確な物理CPUモデル
`AppleWebKit/537.36`	エンジン系譜と互換性トークン	Chrome は依然としてSafariの完全な実装
`KHTML, like Gecko`	歴史的互換性用語	KHTMLもGeckoも稼働中です。
`Chrome/145.0.0.0`	Chrome/Chromiumファミリーと主要バージョン;低位バージョンのコンポーネントは削減可能です。正確なパッチバージョンを明らかにします
`Safari/537.36`	古いサイトとの互換性のためにトークンを保持した	ブラウザはSafari

初期のウェブサイトはブラウザ名で分岐することが多かったため、UAが冗長になりました。新しいブラウザは、正しいページを得るために古い製品との互換性を主張しなければなりませんでした。これらの宣言は時間をかけて蓄積され、文字通り読むことはできない歴史的記録を生み出しました。

したがって、UA解析の最初のルールは単純です:これは互換性プロトコルであり、厳密なデバイス記述ではありません。

2. なぜウェブサイトは今でもUAを使うのか?

UAは追跡だけに使われるわけではありません。正当な用途には以下が含まれます:

互換性の問題が知られている古いブラウザへのフォールバックとして機能します。
適切なインストーラーやダウンロード形式の選択;
診断ログでバージョン固有の障害を見つけること;
広範なブラウザファミリー、プラットフォーム、メジャーバージョンの分布測定、
自動化されたトラフィックや悪意のあるトラフィックにおける不可能な組み合わせの特定。

問題は、UAスニッフィングが狭い互換性のフォールバックから製品名で機能を推測する段階に変わったときに始まります。コードはChromeを認識し、特定のAPIが存在すると想定することがあります。この仮定は、組み込み型WebView、Chromium由来ブラウザ、エンタープライズポリシーを持つブラウザ、フリーズしたUA、ヘッダーを変更したクライアントなどで失敗する可能性があります。

より堅牢な操作順序は次の通りです:

能力検出が可能な場合は、必要なAPIや動作を直接テストしてください。
ブラウザ識別が避けられない場合は、アドホックな正規表現ではなく、維持されたパーサを使用してください。
製品が本当に必要としている粗いカテゴリーのみを保管してください。
未知のブランド、未知のバージョン、欠けているフィールドのバックアップを提供します。

3. UAブラウザの指紋ですか?

より正確には、UAはブラウザのフィンガープリントへの1つの入力であり、通常は完全なフィンガープリントではありません。

ブラウザのフィンガープリンティングには秘密のシリアル番号は必要ありません。これはブラウザが露出した比較的安定で識別できる属性の集合を測定します。UAブラウザファミリー、バージョン、プラットフォームについての手がかりを提供しています。画面の寸法、フォント、タイムゾーン、Canvas、WebGL、AudioContextなどのインターフェースがさらなる情報を追加します。

Laperdrixらによる調査Browser Fingerprinting: A Surveyでは、これらの技術を無状態認識の一形態として論じています。サイトは必ずしも最初にCookieを書く必要はありません。ブラウザが公開する属性からの訪問を関連付けようと試みることができます。「ステートレス」はサーバーが何も保存しないという意味ではありません。これは、認識資料が永続的なクライアント側識別子に依存しないことを意味します。

1. 論文の10ビット結果は何を意味するのか?

2010年のPanopticlick研究How Unique Is Your Web Browser?では、ピーター・エッカーズリーが約47万件のブラウザ指紋を分析しました。同紙は次のように報じています:

完全な指紋には、そのサンプルには平均約18.1ビットの識別情報が含まれていました。
直感的に言えば、平均的な指紋は286,777台のブラウザで約1回しか発生しません。
表は、UA列だけで約10.0ビットの平均情報を報告していました。
FlashまたはJavaが有効なブラウザでは、完全な指紋の94.2%がユニークでした。

自己情報は一般的に次のように表記されます:

I(x) = -log₂ P(x)

あるUAが集団で確率1/1024で起こる場合、それを観測することで10ビットの情報が得られます。これは、UAが正確に1,024の可能な値を持っているとか、あるいは一意に人を識別するという意味ではありません。それは、その観察が平均してどれだけの不確実性を取り除くかを示しています。

2. なぜ2010年の結果は今日のウェブにおいて一定ではないのか?

結果は依然として重要ですが、少なくとも3つの条件が必要です。

プライバシーテストページの訪問者は、すべてのインターネットユーザーの無作為抽出ではありませんでした。
2010年のブラウザ、プラグイン、UAバージョンの多様性は現在のエコシステムとは大きく異なっていました。
UA Reduction、プラグイン表面の縮小、指紋認証防止の導入により、観察可能な属性の分布が変化しました。

この研究は、UAやその他の属性が測定可能な識別情報をもたらすという主張を支持しています。今日、あるUAが必ずちょうど10ビットのエントロピーを持つと言うことは支持しません。指紋認証の力は、人口、時間帯、ブラウザのポリシー、信号の組み合わせに依存します。

4. なぜUAだけを変えることが裏目に出るのか?

UAは暗号学的証拠のないクライアント宣言です。サーバーはこのヘッダーからデバイスの工場出荷時の真実を読み取ることはできません。しかし、異なる観測値が合理的に適合しているかどうかは確認できます。

User-Agent信号と他のブラウザ信号間の一貫性

あるUAがモバイルブラウザであると主張しているが、ページにはタッチポイントがなく、ウィンドウが一貫してデスクトップディスプレイに似ており、Client Hintsがデスクトッププラットフォームを報告していないとします。どの一つの観察にも正当な例外があるかもしれません。いくつかの安定した矛盾が組み合わさっても、分類可能なパターンを形成し得ます。

Panopticlick論文では同様の事例がすでに記録されており、一部のブラウザはFlashをサポートしながらiPhoneであると主張し、また一部のFirefox UAはInternet Explorerでしか利用できないストレージ機能と並行して登場しました。2018年のFP-Scanner研究はこの問題を体系的に検証しました。一部のアンチフィンガープリンティング拡張やスプーフィングツールはインターフェース間で不整合を生み出し、検出器が修正された属性を識別し、場合によっては元のブラウザやオペレーティングシステムファミリーを推測できるようにしました。

すべての矛盾が悪意というわけではありません。リモートデスクトップ、アクセシビリティツール、エンタープライズポリシー、互換性レイヤー、珍しいハードウェアなどが、すべて独特の組み合わせを生み出すことがあります。慎重なリスクシステムは、矛盾を自動的にユーザーをブロックする理由ではなく、確率的な証拠として扱うべきです。

ブラウザプロファイル管理において重要なのは以下の3つの特性です。

内部整合性: UA、Client Hints、プラットフォーム、アーキテクチャ、タッチ、スクリーン信号は互いに直接矛盾してはなりません。
時間経過の安定性: 長寿命のプロフィールは理由なく毎回リリースごとに劇的に変わるべきではありません。
**もっともらしい多様性:**プロファイルは異なるかもしれませんが、稀な機械的に生成された組み合わせが必ずしも安全とは限りません。

FP-STALKER研究はまた、属性の変更が自動的に連鎖を妨げるわけではないことも示しました。モデルは安定した属性や妥当なバージョン変更を用いて、以前の指紋と後の指紋をつなげることができます。

5. UA Reductionが取り組む問題は何でしょうか?

ほとんどのリクエストには伝統的なUAが送られます。リクエストを受け取ったファーストパーティまたはサードパーティのエンドポイントは、受動的に読み取ることができます。文字列が正確であればあるほど、受信者はデフォルトでより識別可能な情報を得られます。

ChromiumのUser-Agent Reductionプランはこのデフォルトの細分さを軽減します:

Chrome 101以降、デスクトップのマイナー版、ビルド版、パッチ版は0.0.0にまで縮小されました。
後のフェーズではデスクトップオペレーティングシステムのバージョン、CPU詳細、Androidデバイス情報が統合されました。
縮小Android UAでは、Android 10; Kなどの固定プラットフォームおよびモデル値を使用します。
本当に詳細が必要なサイトはUser-Agent Client Hintsを要求できます。

簡約形式は次のようにまとめられます:

Mozilla/5.0 (<unified platform information>)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/<major version>.0.0.0 Safari/537.36

リダクションはレガシー UAの受動的な指紋処理面積を減少させます。ブラウザの指紋認証を完全に排除するものではありません。メジャーバージョン、広範なプラットフォーム、モバイル状態は可視化される一方で、他のAPI、ネットワーク特性、挙動は情報を提供できます。

6. User-Agent Client Hintsどのように機能するのか?

一般的なメカニズムはRFC 8942で定義されており、WICGUser-Agent Client Hints草稿はUA特有の場を記述しています。この手法は、かつて非構造化文字列に存在していた情報を構造化フィールドに分割し、デフォルトで送信される低エントロピーのヒントと、サイトが通常明示的に要求する高エントロピーのヒントを区別します。

UA ReductionとUser-Agent Client Hintsのリクエストフロー

簡略化された初期の要請は次のようになります。

GET /download HTTP/1.1
User-Agent: Mozilla/5.0 (...) Chrome/145.0.0.0 Safari/537.36
Sec-CH-UA: "Chromium";v="145", "Not_A Brand";v="99"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

サーバーが本当にインストーラーを選択するためにアーキテクチャとビットリティが必要な場合、次のように応答できます:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness
Vary: Sec-CH-UA-Arch, Sec-CH-UA-Bitness

ブラウザがこの仕組みをサポートし、セキュリティおよびポリシー要件が満たされた場合、後から次のような要求が出されることがあります:

Sec-CH-UA-Arch: "x86"
Sec-CH-UA-Bitness: "64"

一般的なUA Client Hintsには以下が含まれます:

フィールド	典型的な目的	情報レベル
`Sec-CH-UA`	ブランドおよびメジャーバージョン一覧	通常は低エントロピー
`Sec-CH-UA-Mobile`	クライアントがモバイル体験を好むかどうか	通常は低エントロピー
`Sec-CH-UA-Platform`	広範囲プラットフォームカテゴリー	通常は低エントロピー
`Sec-CH-UA-Arch`	CPUアーキテクチャ	高いエントロピー;必要に応じてリクエスト
`Sec-CH-UA-Bitness`	アーキテクチャのビットネス	高いエントロピー;必要に応じてリクエスト
`Sec-CH-UA-Platform-Version`	プラットフォーム版	高いエントロピー;必要に応じてリクエスト
`Sec-CH-UA-Full-Version-List`	報告されたブランドの完全版	高いエントロピー;必要に応じてリクエスト
`Sec-CH-UA-Model`	デバイスモデル	高いエントロピー;必要に応じてリクエスト

3つの工学的な細部は見落としがちです。

1. Client Hintsがすべて自動的に送信されるわけではありません

低エントロピーのヒントはデフォルトで現れることがあります。高エントロピーのヒントは通常、Accept-CH応答を必要とします。初期ナビゲーション、サブリソース、権限ポリシー、安全なトランスポート、ブラウザのサポートなど、すべてが到着する内容に影響を与えます。サーバーはすべてのオプションフィールドが欠如することを許可しなければなりません。

2. ブランドリストは意図的にパーサーの堅牢性をテストしています

Sec-CH-UAには複数のブランドや、適合性テスト用の合成ブランドが含まれていることがあります。コードは最初のエントリーが必ず製品名であると仮定してはならず、未知のブランドが現れても失敗してはなりません。構造化されたフィールドを解析し、知らないエントリーは無視し、将来のブランドのために余地を残しましょう。

3. ヒントに反応が異なる場合は、正しいキャッシュ処理が必要です

アーキテクチャやプラットフォーム、その他のヒントで応答が変わった場合は、Varyまたはそれに相当するキャッシュキー戦略を正しく設定してください。そうでなければ、共有キャッシュはあるデバイスクラスで生成されたコンテンツを別のデバイスクラスに提供することもあります。

7. Client Hints伝統的なUAよりもプライベートなのでしょうか?

情報の露出方法を改善するが、指紋採取からの免疫は提供しない。

従来のUAは、受動的かつデフォルトで大きな非構造化バンドルを明らかにします。Client Hintsそのバンドルをフィールドに分割し、エントロピーの高い情報の要求をより明確にし、ブラウザがポリシー、権限、プライバシー予算のコントロールを適用する機会を与えます。

しかし、アーキテクチャ、完全バージョン、プラットフォームバージョン、デバイスモデルは依然として識別性を高めることができます。RFC 8942はプライバシーと性能を設計上の制約として明示的に扱っています。開発者は以下を問うべきです:

この機能は本当にフィールドを必要とするのでしょうか?
能力検出やユーザー選択で置き換えられるのでしょうか?
アプリケーションは粗いカテゴリだけを保存できますか?
生の値はどのくらいの期間保持され、誰がそれにアクセスできるのか?
サードパーティのリソースも同じヒントを受け取るのでしょうか?

8. サーバー側UA処理のエンジニアリングガイダンス

1. UAを身元や権威の証明として使わないこと

UA表示の選択肢や互換性のバックアップをサポートできます。それが身元、承認、支払い信託、セキュリティ境界を決定するべきではありません。クライアント制御の値はアクセス制御の認証情報として機能しません。

2. ブラウザリストよりも能力検出を優先すること

フロントエンドがAPIを必要とする場合は、その機能を直接テストしてください:

if ('share' in navigator) {
  // Offer the system share feature.
} else {
  // Fall back to copying a link.
}

能力検出は、派生ブラウザ、実験機能、エンタープライズポリシー、将来のリリースを「Chrome 145で有効にする」といったルールよりも適切に処理します。

3. レガシー UA、Client Hints、未知の状態を受け入れる

移行時には、サーバーはレガシー UA(UA・Client Hintsの両方)のみを受け取るか、両方の大幅に縮小された形態を受け取ることがあります。データモデルは、すべてのフィールドを正確に埋めるオペレーティングシステムやデバイスモデルを推測するのではなく、unknownできるようにすべきです。

4. ログの粒度を減らす

もし分析がデスクトップとモバイル、ブラウザファミリー、メジャーバージョンだけを必要とするなら、生のUA文字列やすべての高エントロピーのヒントを無期限に保持しないでください。データの最小化はプライバシーリスクを減らし、分析パイプラインがわずかな変動を意味のある次元として扱うことを防ぎます。

5. 異常を証拠として扱い、評決として扱うこと

あるAPIが異なる挙動をしているとWindows主張するUAは、せいぜいリスクシグナルの一つに過ぎません。エンタープライズ環境、仮想化、リモートセッション、互換性レイヤー、支援技術などは、正当な異常を生じさせることがあります。一つのミスマッチを自動的な不正判定に変えると誤検知が発生します。

9. マルチプロファイル環境でUAどのように設定すべきか?

地域をまたぐテスト、広告プレビュー、アカウント運営、プライバシー隔離において、最も異例なUAを作ることを目標にすべきではありません。プロファイルは説明可能で安定し、周囲の環境と互換性があるべきです。

以下の内容を順に確認してください:

ブラウザ版: UAメジャーバージョンは実際のエンジンとその機能に対して妥当であるべきです。
オペレーティングシステム: UAプラットフォーム、Client Hintsプラットフォーム、JavaScript見えるプラットフォームカテゴリは互換性があるべきです。
アーキテクチャとビットリティ: UA、Client Hints、実行環境は直接的に矛盾する主張をしてはなりません。
デバイスフォームファクター: モバイル宣言はタッチサポート、ビューポート、ピクセル比、インタラクションパターンと並んで意味を持つべきです。
地域別コンテキスト: 言語、タイムゾーン、地理位置情報、プロキシ出口は機械的に一致する必要はありませんが、実際のワークフローには合致するはずです。
プロファイルの安定性: あるアカウントやテストIDが長寿命プロファイルを再利用する場合は、理由なくプラットフォームとメジャーバージョンを切り替えるのは避けましょう。

PurpleMarkの現在のプロファイル変換は、選択したオペレーティングシステムをUAプラットフォームにマッピングし、まず設定済みのChrome/またはCriOS/トークンからブラウザ版を抽出しようとします。使えるバージョンが存在しない場合は、現在のエンジンの主要バージョンから合理的なフォールバックを導き出します。目的は1つの孤立した文字列を偽装することではなく、一貫したブラウザプロファイルモデル内に設定UA配置することです。

プロファイルの孤立とパラメータの整合性は、技術的な相関やテストバイアスを減らすことができます。アカウントが決して連携しない保証はできず、プラットフォームのルール、アカウントデータ、支払い情報、責任ある運営慣行の代替にもなりません。これらの機能は、合法的なプライバシー保護、認可されたテスト、そしてコンプライアンスのある業務活動にのみ使用してください。

10. よくある質問

Q1: UAを変更するとブラウザが別のブラウザに変わるのでしょうか?

いいえ。クライアントが宣言する内容の一部を変えます。JavaScriptエンジン、レンダリングパイプライン、ネットワークスタック、サポートされているWeb APIの代替ではありません。

Q2: ウェブサイトは「本物の」内容を読むことができるのかUA?

すべてのウェブサイトがブラウザをバイパスして読める、普遍的なハードウェアレベルの「リアルUA」は存在しません。それでもサイトはClient Hints、能力テスト、その他の指紋信号を比較し、矛盾する主張を見つけ出し、確率的推論を行うことができます。

Q3: 縮小UAはWindows 10とWindows 11を区別できますか?

減少したレガシー UA通常は、両者がWindows NT 10.0を報告するため、信頼性を保つことはできません。UA Client Hintsをサポートするブラウザは、サイトからより詳細なプラットフォームバージョン情報が求められた場合に提供されることがあります。サーバーはフィールドの欠落やマッピングの違いを処理しなければなりません。

Q4: JavaScriptを無効化すると曝露は止UAますか?

完全には。HTTP User-Agentはリクエストヘッダーであり、ページJavaScriptを実行する前にページリクエストと一緒に送信できます。JavaScriptを無効にすると一部の収集面は失われますが、現代のウェブの大部分が壊れます。

Q5: User-Agent Client Hints完全に置き換えられるのでしょうか?

それを短期的に決めつけないでください。多くのクライアントやサーバーは依然としてレガシー UAに依存しており、サポートUA Client Hints様々です。Client Hintsを段階的な強化として扱いましょう。利用可能な場合は構造化された情報を優先しつつ、レガシー UAや未知の状態に対するバックアップは保持します。

Q6: ランダム生成UA匿名性は向上しますか?

必ずしもそうとは限りません。一つのフィールドをランダム化すると、バージョン、プラットフォーム、タッチ、レンダリング信号と矛盾が生じる可能性があります。長寿命プロファイルの場合、共通で安定し内部互換性のある構成の方が、頻繁なランダムな変更よりも通常より説得力があります。

11. 結論

User-Agentは信頼できる身分証明書でも無関係な文字列でもありません。ウェブ互換性、プライバシー、リスク分析の交差点に位置しています。開発者にとっては、過去の重荷を伴う互換性の入力です。指紋研究者にとっては、測定可能な統計情報を持つ属性です。ブラウザベンダーにとっては、これはデフォルトの露出対象であり、削減する必要があります。

主要な考え方は三つの主張に当てはまります。

UAを文字通りに読まないでください。多くの歴史的互換性トークンが含まれています。
UAを単独で評価しないでください。実用的な認識は、信号の組み合わせとそれらが時間をかけて進化していくことから生まれます。
Client Hintsを単なる「よりUAな場」と考えないでください。その価値は、構造化され、要求主導され、規制可能な開示にあります。

システムがブラウザ名の識別から必要な機能のテストへ、そして利用可能なすべての詳細を収集するのではなく、必要なものだけを要求する段階に移行すると、UA本来の役割、すなわち互換性の手がかりに戻り、アイデンティティの真実ではありません。

参考文献と標準

Peter Eckersley. How Unique Is Your Web Browser?. Privacy Enhancing Technologies Symposium, 2010.
Pierre Laperdrix, Nataliia Bielova, Benoit Baudry, Gildas Avoine. Browser Fingerprinting: A Survey. ACM Transactions on the Web, 2020.
Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. USENIX Security Symposium, 2018.
Antoine Vastel, Pierre Laperdrix, Walter Rudametkin, Romain Rouvoy. FP-STALKER: Tracking Browser Fingerprint Evolutions. IEEE Symposium on Security and Privacy, 2018.
IETF. RFC 9110: HTTP Semantics, 2022.
IETF. RFC 8942: HTTP Client Hints, 2021.
WICG. User-Agent Client Hints, Draft Community Group Report.
Chromium. User-Agent Reduction.
Chrome for Developers. Improve user privacy and developer experience with User-Agent Client Hints.