ユーザーエージェント クライアントヒント

1. はじめに

このセクションは規範的ではありません.

現在、ユーザーエージェントは通常、各リクエストとともに User-Agent HTTPリクエストヘッダーフィールドをサーバーに送信して自身を識別します（[rfc9110]のSection 5.5.3で定義）。理想的には、このヘッダーによってサーバーはコンテンツネゴシエーションができ、特定のユーザーエージェントに最適なリソースを送信し、帯域幅やユーザー体験を最適化できます。しかし実際には、このヘッダーの値はデフォルトとしては不適切なほど多くのユーザーのデバイス情報を露出する一方で、誤ったサーバー側のヒューリスティクスを回避するためにユーザーエージェントを意図的に偽装することもあります。

例えば、iOS版Chromeの最近のバージョンは次のように自身を識別します:

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X)
            AppleWebKit/605.1.15 (KHTML, like Gecko)
            CriOS/69.0.3497.105 Mobile/15E148 Safari/605.1

一方、Edgeの最近のバージョンは次のように自身を識別します:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
            AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.2704.79
            Safari/537.36 Edge/18.014

これらの文字列には多くの情報（そしてかなりの虚偽情報）が詰め込まれています。バージョン番号、プラットフォームの詳細、モデル情報などがすべてリクエストごとに送信され、様々なフィンガープリンティング手法の基盤となっています。各ベンダーは自身のユーザーエージェント文字列の変更を試みてきましたが、歴史的な手法を妨げてきた開発者からのフィードバックにはいくつかのカテゴリがあります:

1. ブランドとバージョン情報（例: "Chrome 69"）により、Webサイトは特定のリリースに存在する既知のバグを回避することができます。例えばContent Security Policyの実装はベンダーごとに大きく異なり、どのブラウザがパースと実行を担当するかを知らずにHTTPレスポンスにどのポリシーを送るべきか判断するのは困難です。

2. 開発者はしばしばユーザーエージェントやプラットフォームに基づいて送信するコンテンツをネゴシエートします。例えば、あるアプリケーションフレームワークは、iOS上のアプリをAndroid上の同じアプリとは異なるスタイルにして、それぞれのプラットフォームの美学やデザインパターンに合わせます。

3. #1と同様に、OSのリビジョンやアーキテクチャが特定のバグの原因となり得るため、Webサイトのコードで回避策を取ることができ、ダウンロードする適切な実行ファイル（32bit/64bit、ARM/Intelなど）選択にも有用です。

4. 高度な開発者はモデルやメーカー情報を使ってデバイスの能力（例: [FacebookYearClass]）に合わせてサイトを調整したり、モデルやメーカー固有のパフォーマンスバグやリグレッションを特定します。

本ドキュメントは、User-Agent文字列からより積極的にエントロピーを除去し、本当にクライアントの詳細が必要なサーバーだけがそれらを受け取れるようにする仕組みを提案します。ブランドやバージョン情報、基盤となるOSのブランドとメジャーバージョン、デバイスの詳細を提供できる複数の新しいクライアントヒント（[RFC8942]）を導入します。これらのデータを常に全員に送信するのではなく、ユーザーエージェントはサイトごとの要求に応じてより細かいデータの送信可否を判断し、ネットワーク上に露出するパッシブフィンガープリンティングの表面を減らします（ベストプラクティス1、[FINGERPRINTING-GUIDANCE]参照）。

1.1. 例

このセクションは規範的ではありません.

あるユーザーが最新バージョンの"Examplary Browser"でhttps://example.com/に初めてアクセスします。そのユーザーエージェントはHTTPリクエストとともに以下のヘッダーを送信します:

Sec-CH-UA: "Examplary Browser"; v="73", ";Not?A.Brand"; v="27"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"

サーバーはユーザーの基盤プラットフォームバージョンに合わせたコンテンツをレンダリングしたいので、初回レスポンスでAccept-CHヘッダー（[RFC8942]のSection 2.2.1）を送信して、追加情報を要求します:

Accept-CH: Sec-CH-UA-Platform-Version

これに応じて、ユーザーエージェントは次のリクエストでプラットフォームバージョン情報を含めます:

Sec-CH-UA: "Examplary Browser"; v="73", ";Not?A.Brand"; v="27"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-CH-UA-Platform-Version: "14.0.0"

1.2. ユースケース

このセクションは規範的ではありません.

このセクションでは、現在のUser-Agent文字列の用途と、UA-CH（User-Agent Client Hints）で同様の機能をどのように実現できるかを記載します。

1.2.1. 差別化配信

1.2.1.1. ブラウザ機能に基づく

同様にJavaScriptを配信する際、最新のES機能が使えるブラウザにはトランスパイル（結果として肥大化や非効率なコードになる）を避けられます。画像配信時も、一部ブラウザはAcceptリクエストヘッダーを更新しない場合や、MIMEタイプだけでは同一フォーマットのバリアントを判別できない場合（例: WebP）もあり、その場合はブラウザとバージョンの情報が正しい画像バリアントの配信に不可欠です。

このユースケースを成立させるには、サーバーがブラウザとその意味のあるバージョンを把握し、それを利用可能な機能リストにマッピングする必要があります。これにより、どのポリフィルやコードバリアントを配信すべきかが分かります。

UA-CHでこれを行うサービスは、デフォルトで全リクエストに送信されるSec-CH-UAヘッダーを検査し、それに基づいてレスポンスを変更する必要があります。

1.2.1.2. ブラウザバグ回避策

このユースケースでは、サーバーがブラウザとその意味あるバージョンを把握し、影響するバグを認識し、該当する場合に回避策を適用する必要があります。

UA-CHでこれを行うサービスは、デフォルトで全リクエストに送信されるSec-CH-UAヘッダーを検査し、それを使ってレスポンスを変更します。

1.2.2. マーケットシェア分析

マーケットシェア分析には、サーバーが以下のいずれかの情報を認識する必要があります: ユーザーエージェント名とそのバージョン、OSとそのバージョン、デバイスモデル。それらを記録し、相対的なマーケットシェアを算出します。

UA-CHを使ってマーケットシェア分析を行いたいサイトは、デフォルトで全リクエストに送信されるSec-CH-UAヘッダーを検査して記録します。ユースケースによっては追加のUAクライアントヒント（例: モバイルデバイスモデル分析）も要求できます。

設計上、brandsリストの個々のエントリを見るだけでは、人気の低いブラウザの本当のブランド名と有名なブラウザのGREASE（偽ブランド）を区別しにくくなります。人気の低いブラウザは互換性目的で複数の有名ブランド名を含むことがあり、この手法だと、ユーザーは人気の高いブラウザの使用者として分類され、利用シェアの見方が歪むことになります。

そのため分析目的では、brandsリストをユニットとして扱い、区別したい（ブラウザ、バージョン）ペアごとに既知のbrandsリストと比較する方が良いです。新しいブラウザやバージョンが登場した際は既知リストを定期的に更新する必要がありますが、未知のブラウザで閉じること自体は問題になりません。

こうした既知brandsリストは中央で管理し、caniuseやMDNのように多くのサイトで利用されることもできます。

仕様では、ブラウザが送信するbrandsリストをバージョンごとに固定することを推奨しており、使用率集計を簡単にし、キャッシュにも有利です。既知brandsリストはブランドセットから（ブラウザ、バージョン）ペアへの単純なマッピングになります。

1.2.3. コンテンツ適応

1.2.3.1. ブラウザベースの適応

ブラウザとしては、前者は可能にし、後者は抑制したいと考えています。

1.2.3.2. モバイル専用サイト

その場合、モバイルデバイスのユーザーにモバイル専用サイトを配信することが有効です。これを実現するには、HTML配信時にユーザーがモバイルデバイスかどうかをサーバーが把握する必要があります。

UA-CHでモバイル専用サイトを配信したいサイトは、デフォルトで全リクエストに送信されるSec-CH-UA-Mobileヘッダーを利用できます。

1.2.3.3. 低スペックデバイス

分岐基準がメモリであれば、Device-Memory Client Hintで判別可能です。その他の場合でもUA-CHでSec-CH-UA-Modelヒントを選択的に取得できます。

これらのヒントは初期状態では送信されないため、追加の設定が必要です。

トップレベルオリジンはAccept-CH: Device-Memory, Sec-CH-UA-Modelヘッダーをレスポンスに含めてヒントの送信を要求する必要があります。すべてのナビゲーションリクエストで適応が必須なら、ヒントがない場合はリダイレクトが必要です。あるいは、Critical-CHを使ってクライアント側に追加のリクエスト/レスポンス往復を処理させることもできます。

こうした適応を行う第三者オリジンは、トップレベルオリジンから委任が必要です。トップレベルオリジンはAccept-CHでヒントを要求し、さらにPermissions-Policyヘッダーで第三者オリジンへ委任する必要があります。

1.2.3.4. OS固有のスタイル

この場合は、前述の「低スペックデバイス」と同様に、Sec-CH-UA-PlatformおよびSec-CH-UA-Platform-Versionヒントを利用します。

1.2.3.5. OS統合

この場合も「OS固有のスタイル」と同様に、Sec-CH-UA-PlatformとSec-CH-UA-Platform-Versionヒントが必要です。

1.2.3.6. ブラウザ・OS固有の実験

1.2.4. ユーザーログイン通知

こうした通知を有効にするには、サイトはブラウザの商用ブランド名を認識し、ユーザーへ伝える必要があります。多くの場合、プラットフォーム名やバージョンも通知に含め、ユーザーがどのデバイスか判断できるようにします。

この種の通知はサーバー側適応を必要としないため、必要な情報取得にはuserAgentData.getHighEntropyValues()メソッドを使う方が適しています。

1.2.5. 適切なバイナリエグゼキュータブルのダウンロード

このユースケースを解決するため、ダウンロードサイトはSec-CH-UA-Platform、Sec-CH-UA-Platform-Version、Sec-CH-UA-Arch、Sec-CH-UA-Bitnessヒント（またはAPIで取得）を利用して、ユーザーに最適なバイナリを提案できます。

1.2.6. コンバージョンモデリング

1.2.7. 脆弱性フィルタリング

こうしたプロキシは、リダイレクト手順を追加するか、Client Hint reliability mechanismsのいずれかを利用して、ブラウザのフルバージョンとプラットフォームバージョンの取得をオプトインし続ける必要があります。

1.2.8. ログとデバッグ

1.2.9. フィンガープリンティング

ユーザーフィンガープリンティングとは、複数の情報源からユーザー情報を収集・組み合わせてユーザー固有の識別子を生成し、Cookieなどの状態を消しても後から認識できるようにする手法です。

この場合、オリジンはできるだけ多くのエントロピーを集めようとするため、あらゆるヒントを収集することになります。

1.2.9.1. スパムフィルタリングとボット検知

将来的には、スパムフィルタリングやボット検知ユースケースを解決できる代替手法やAPIが登場することが期待されます。例えば、ブラウザがユーザーのために識別エントロピーの収集を制限する介入（Privacy Budget提案など）をする場合です。

1.2.9.2. 永続的なユーザー追跡

1.2.9.3. 既知のボット・クローラーのブロック

スパムフィルタリングの場合と同様、将来的にはUser-Agent文字列照合に代わる手法が登場することが期待されます。

2. インフラストラクチャ

この仕様はClient Hints Infrastructure、HTTP Client Hints、Infra Standard、Permissions Policyに依存します。[CLIENT-HINTS-INFRASTRUCTURE] [RFC8942] [INFRA] [permissions-policy-1]

この仕様で使用される用語の一部は、Structured Field Values for HTTPで定義されています。[rfc9651]

3. ユーザーエージェントヒント

以下のセクションでは、サーバーが[RFC8942]で定義されたClient Hintsインフラストラクチャを通じて受信を選択できる、特定のユーザーエージェントに関する詳細を公開するHTTPリクエストヘッダーフィールドを定義します。以下の定義では、各ユーザーエージェントが自身のプロパティをいくつか定義していると仮定します:

• ブランド - ユーザーエージェントの商用名称（例: "cURL", "Edge", "The World’s Best Web Browser"）。32文字未満のASCII英字でなければなりません。

• フォームファクター - デバイスのフォームファクター。従来はUser-Agent文字列内の<deviceCompat>トークンとして表現（例: "Tablet", "VR"など）。

• フルバージョン - ユーザーエージェントまたはそのbrandsリスト内ブランドに対応するビルドバージョン（例: "72.0.3245.12", "3.14159", "297.70E04154A"など）。

• モデル - ユーザーエージェントのデバイスモデル（例: "", "Pixel 2 XL"など）。

• モバイル性 - ユーザーエージェントのデバイスがモバイルデバイスかどうかを示す真偽値（例: ?0 または ?1）。

• プラットフォームブランド - ユーザーエージェントのOSの商用名（例: "Windows", "iOS", "AmazingOS"など）。

• プラットフォームバージョン - ユーザーエージェントのOSバージョン（例: "NT 6.0", "15", "17G"など）。

• プラットフォームアーキテクチャ - ユーザーエージェントのCPUアーキテクチャ（例: "ARM", "x86"など）。

• プラットフォームビット数 - ユーザーエージェントのCPUアーキテクチャのビット数（例: "32", "64"）。

• 重要バージョン - マーケティングバージョン（例: "72", "3", "12.1"など）。ユーザーエージェントまたはbrandsリスト内のブランドに対応し、ウェブで区別可能な機能を含む（例: レンダリングエンジンや同等クラスのフルバージョンなど）。

• wow64性 - ユーザーエージェントのバイナリが64ビットWindows上で32ビットモードで動作しているかどうかを示す真偽値（例: ?0 または ?1）。

ユーザーエージェントは、これらの文字列を簡潔にすることが望ましいですが、サーバーはすべての値について任意の値を受け入れなければなりません。値はすべてユーザーエージェントが自由に構成できます。

ユーザーエージェントは、高エントロピーなプラットフォームアーキテクチャ値を以下のバケットに分類しなければなりません:

• x86 CPUアーキテクチャ => "x86"

• ARM CPUアーキテクチャ => "arm"

その他のCPUアーキテクチャは、合理的な場合はこれらの値のいずれかにマップするか、空文字列にマップできます。

ユーザーエージェントは、以下の2つの条件が両方適用されるプラットフォーム以外では、プラットフォームアーキテクチャやプラットフォームビット数に空文字列または架空値を返すべきです:

• 実行ファイルのバイナリダウンロードが予想される。

• 異なるCPUアーキテクチャごとに異なる実行ファイルリソースが必要であり、それぞれの実行ファイルリソースが利用可能である。

ユーザーエージェントは、モバイル性がfalseの場合、モデルに空文字列を返さなければなりません。また、モバイル性がtrueでも、通常モデルが公開されるプラットフォーム以外ではmodelに空文字列を返さなければなりません。

ユーザーエージェントは、sf-string型のヒントには空文字列、sf-boolean型のヒントにはfalse、その他架空値などを返しても構いません。これは、プライバシー・互換性・その他理由による場合であり、以下のヒントのリクエストに対して適用できます: フルバージョン、プラットフォームアーキテクチャ、プラットフォームビット数、wow64性、モデル。

3.1. 'Sec-CH-UA' ヘッダーフィールド

Sec-CH-UAリクエストヘッダーフィールドは、サーバーにユーザーエージェントのブランド情報と重要バージョン情報を提供します。これはStructured Headerであり、値はリストでなければなりません[rfc9651]。 リストの項目はすべて文字列でなければなりません。各項目の値には"v"パラメータとしてユーザーエージェントのバージョンを含めることが推奨されます。

ヘッダーのABNFは:

Sec-CH-UA = sf-list

リクエストのSec-CH-UA値を返すためには、以下の手順を実行します:

1. brandsを"重要バージョン"でブランド作成を実行した結果とする。

2. listをbrandsおよび"重要バージョン"でブランド-バージョンリスト作成を実行した結果とする。

3. listでリストの直列化を実行した出力を返す。

注: 他の多くのClient Hintsと異なり、低エントロピーヒントテーブルに含まれているため、 Sec-CH-UAヘッダーは、サーバーがAccept-CHヘッダーで受信を選択しているかどうかに関係なくデフォルトで送信されます（ただし、ポリシー制御クライアントヒント機能で制御可能です）。 これはブランド情報と重要バージョン番号のみを含み、どちらも他のヘッダーの構造を調べたり、特定のブラウザリリースごとに導入・変更された機能の有無をテストすることで明確に判別できるため、低エントロピーと見なされます（[Janc2014]）。

注: Sec-CH-UAはbrandsリスト内の各ブランドのメジャーバージョンを公開します。フルバージョンが必要なユースケースについては、Sec-CH-UA-Full-Version-Listを参照してください。

3.2. 'Sec-CH-UA-Arch' ヘッダーフィールド

Sec-CH-UA-Archリクエストヘッダーフィールドは、 特定のユーザーエージェントが実行されているプラットフォームのアーキテクチャ情報をサーバーに提供します。 これはStructured Headerであり、値は文字列でなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Arch = sf-string

3.3. 'Sec-CH-UA-Bitness' ヘッダーフィールド

Sec-CH-UA-Bitnessリクエストヘッダーフィールドは、 特定のプラットフォームビット数情報をサーバーに提供します。 これはStructured Headerであり、値は文字列でなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Bitness = sf-string

3.4. 'Sec-CH-UA-Form-Factors' ヘッダーフィールド

Sec-CH-UA-Form-Factorsリクエストヘッダーフィールドは、ユーザーエージェントのフォームファクター情報をサーバーに提供します。これはStructured Headerであり、値はリストでなければなりません[rfc9651]。追加のフィンガープリンティングエントロピーを防ぐため、ヘッダー値は辞書順で、値は大文字小文字を区別します。

ヘッダーは以下の一般的なフォームファクター値のいずれかまたは複数でデバイスのフォームファクターを記述するべきです: "Desktop", "Automotive", "Mobile", "Tablet", "XR", "EInk", "Watch"。該当する全フォームファクター値を含めるべきです。

ヘッダーのABNFは:

Sec-CH-UA-Form-Factors = sf-list

3.5. 'Sec-CH-UA-Full-Version' ヘッダーフィールド

Sec-CH-UA-Full-Versionは非推奨であり、今後削除されます。開発者はSec-CH-UA-Full-Version-Listの利用を推奨します。

Sec-CH-UA-Full-Versionリクエストヘッダーフィールドは、ユーザーエージェントのフルバージョン情報をサーバーに提供します。これはStructured Headerであり、値は文字列でなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Full-Version = sf-string

3.6. 'Sec-CH-UA-Full-Version-List' ヘッダーフィールド

Sec-CH-UA-Full-Version-Listリクエストヘッダーフィールドは、brandsリスト内の各ブランドのフルバージョン情報をサーバーに提供します。これはStructured Headerであり、値はリストでなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Full-Version-List = sf-list

リクエストのSec-CH-UA-Full-Version-List値を返すためには、以下の手順を実行します:

1. brandsを"フルバージョン"でブランド作成を実行した結果とする。

2. listをbrandsおよび"フルバージョン"でブランド-バージョンリスト作成を実行した結果とする。

3. listでリストの直列化を実行した出力を返す。

3.7. 'Sec-CH-UA-Mobile' ヘッダーフィールド

Sec-CH-UA-Mobileリクエストヘッダーフィールドは、 ユーザーエージェントが「モバイル」体験を希望するかどうかをサーバーに提供します。これはStructured Headerであり、値は真偽値でなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Mobile = sf-boolean

注: 上記のSec-CH-UA同様、低エントロピーヒントテーブルに含まれているため、 Sec-CH-UA-MobileヘッダーはサーバーがAccept-CHヘッダーで受信を選択しているかどうかに関係なくデフォルトで送信されます（ただし、ポリシー制御クライアントヒント機能で制御可能です）。これはユーザーが直接制御できる単一ビット情報なので低エントロピーと見なされます。

3.8. 'Sec-CH-UA-Model' ヘッダーフィールド

Sec-CH-UA-Modelリクエストヘッダーフィールドは、 特定のユーザーエージェントが実行されているデバイス情報をサーバーに提供します。これはStructured Headerであり、値は文字列でなければなりません[rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-Model = sf-string

3.9. 'Sec-CH-UA-Platform' ヘッダーフィールド

Sec-CH-UA-Platformリクエストヘッダーフィールドは、 特定のユーザーエージェントが実行されているプラットフォーム情報をサーバーに提供します。これはStructured Headerであり、値は文字列でなければなりません[rfc9651]。値は以下の一般的なプラットフォーム値のいずれかに一致することが推奨されます: "Android", "Chrome OS", "Fuchsia", "iOS", "Linux", "macOS", "Windows", "Unknown"。

ヘッダーのABNFは:

Sec-CH-UA-Platform = sf-string

注: Sec-CH-UA同様、低エントロピーヒントテーブルに含まれているため、Sec-CH-UA-PlatformヘッダーはサーバーがAccept-CHヘッダーで受信を選択しているかどうかに関係なくデフォルトで送信されます（ただし、ポリシー制御クライアントヒント機能で制御可能です）。

3.10. 『Sec-CH-UA-Platform-Version』ヘッダーフィールド

Sec-CH-UA-Platform-Version リクエストヘッダーフィールドは、特定の プラットフォームバージョン 上で ユーザーエージェント が実行されている情報をサーバーに提供します。 これは Structured Header であり、値は 文字列 でなければなりません [rfc9651]。 値は プラットフォームバージョンの取得 を プラットフォームブランド で実行した結果です。

プラットフォームバージョンの取得は、文字列 platform を与えて、次の手順を実行します:

1. もし platform が "Linux" なら:

   1. 空文字列を返す。

2. もし platform が "Android" なら:

   1. OS の android.os.Build.VERSION.RELEASE 文字列を取得し platformReturnedVersionString とする。

   2. platformReturnedVersionString で 統一プラットフォームバージョン文字列の生成 を実行した結果を返す。

3. もし platform が "iOS" なら:

   1. currentDevice から返される UIDevice オブジェクトの systemVersion を取得し platformReturnedVersionString とする。

   2. platformReturnedVersionString で 統一プラットフォームバージョン文字列の生成 を実行した結果を返す。

4. もし platform が "Windows" なら:

   1. 利用可能な場合（Windows 10以上）、Windows.Foundation.UniversalApiContract の整数バージョンを取得して文字列に変換し platformReturnedVersionString とする。そうでなければ、レガシーWindowsバージョン番号の取得 の結果を platformReturnedVersionString とする。

   2. platformReturnedVersionString で 統一プラットフォームバージョン文字列の生成 を実行した結果を返す。

5. platformVersionComponentList を リストとする。

6. もし platform が "macOS" なら:

   1. processInfo 情報エージェントから返される NSProcessInfo オブジェクトの operatingSystemVersion プロパティを macOSVersion とする。

   2. macOSVersion の majorVersion, minorVersion, patchVersion をこの順で platformVersionComponentList に 追加する。

7. もし platform が他の値なら:

   1. その platform 上で他のブラウザとの相互運用性につながる最も適したフォーマットに基づき、1～3個のバージョン部品を 追加する。

   2. platformVersionComponentList の長さが3未満の場合、長さが3になるまで "0" を 追加する。

8. platformVersionComponentList を U+002E FULL STOP (.) 区切りで 連結した結果を返す。

レガシーWindowsバージョン番号の取得は、次の手順を実行します:

1. GetVersionEx API の Win32 OSVERSIONINFO の dwMajorVersion を major とする。

2. GetVersionEx API の Win32 OSVERSIONINFO の dwMinorVersion を minor とする。

3. major が 6 かつ minor が 3（Windows 8.1）の場合、"0.3" を返す。

4. major が 6 かつ minor が 2（Windows 8）の場合、"0.2" を返す。

5. major が 6 かつ minor が 1（Windows 7）の場合、"0.1" を返す。

6. それ以外の場合、"0" を返す。

統一プラットフォームバージョン文字列の生成は、文字列 input を与えて、次の手順を実行します:

1. platformVersionComponentList を リスト、index を0とする。

2. platformVersionUnprocessedTokenList を リストとして 厳密分割を input に対して U+002E FULL STOP (.) で実行した結果とする。

3. index が3未満の間:

   1. index が platformVersionUnprocessedTokenList の長さ未満の場合:

      1. platformVersionUnprocessedTokenList[index] が符号なし整数なら、文字列に変換し 追加する。

      2. それ以外の場合は "0" を 追加する。

   2. index が platformVersionUnprocessedTokenList の長さ以上の場合:

      1. "0" を 追加する。

   3. index を1増やす。

4. platformVersionComponentList を U+002E FULL STOP (.) 区切りで 連結した結果を返す。

ヘッダーのABNFは:

Sec-CH-UA-Platform-Version = sf-string

3.11. 『Sec-CH-UA-WoW64』ヘッダーフィールド

Sec-CH-UA-WoW64 リクエストヘッダーフィールドは、 ユーザーエージェントのバイナリが64ビットWindows上で32ビットモードで動作しているかどうかをサーバーに提供します。 これは Structured Header であり、値は 真偽値 でなければなりません [rfc9651]。

ヘッダーのABNFは:

Sec-CH-UA-WoW64 = sf-boolean

注: これらのクライアントヒントは、以下の client hints tokens のセットで利用できます: Sec-CH-UA, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Form-Factors, Sec-CH-UA-Full-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA-WoW64

4. インターフェース

dictionary NavigatorUABrandVersion {
  DOMString brand;
  DOMString version;
};

dictionary UADataValues {
  DOMString architecture;
  DOMString bitness;
  sequence<NavigatorUABrandVersion> brands;
  sequence<DOMString> formFactors;
  sequence<NavigatorUABrandVersion> fullVersionList;
  DOMString model;
  boolean mobile;
  DOMString platform;
  DOMString platformVersion;
  DOMString uaFullVersion; // deprecated in favor of fullVersionList
  boolean wow64;
};

dictionary UALowEntropyJSON {
  sequence<NavigatorUABrandVersion> brands;
  boolean mobile;
  DOMString platform;
};

[Exposed=(Window,Worker)]
interface NavigatorUAData {
  readonly attribute FrozenArray<NavigatorUABrandVersion> brands;
  readonly attribute boolean mobile;
  readonly attribute DOMString platform;
  Promise<UADataValues> getHighEntropyValues(sequence<DOMString> hints);
  UALowEntropyJSON toJSON();
};

interface mixin NavigatorUA {
  [SecureContext] readonly attribute NavigatorUAData userAgentData;
};

Navigator includes NavigatorUA;
WorkerNavigator includes NavigatorUA;

注: ユーザーエージェント情報の高エントロピー部分は Promise 経由で取得されます。これは ユーザーエージェント が、（例: ユーザーに許可を求めるなど）時間のかかるチェックの後に情報公開を制御できるようにするためです。

4.1. 処理モデル

4.1.1. WindowOrWorkerGlobalScope

各 ユーザーエージェント には、brands（ブランドリスト）が関連付けられており、これは リストであり、ブランド作成 を 重要バージョンで実行した結果です。

すべての WindowOrWorkerGlobalScope オブジェクトには brands frozen array（ブランドフローズン配列）が関連付けられており、 FrozenArray<NavigatorUABrandVersion> です。 初期値は フローズン配列生成 を ユーザーエージェント の brands に対して実行した結果です。

さらに、すべての WindowOrWorkerGlobalScope オブジェクトには full version list frozen array（フルバージョンリストフローズン配列）が関連付けられており、 FrozenArray<NavigatorUABrandVersion> です。 これは フローズン配列生成 を ブランド作成（フルバージョン指定）で実行した結果です。

4.1.2. ブランド作成

ブランド作成を version type で行う際は、次の手順を実行します:

1. list を リストとする。

2. Assert version type は "full version" または "significant version" のいずれかであること。

3. brand が ユーザーエージェントまたは 同等クラス を表す場合、各 brand について:

   1. version を 文字列として、次の通り初期化:

      1. version type が "full version" なら、フルバージョンに対応する文字列とする。

      2. version type が "significant version" なら、重要バージョンに対応する文字列とする。

   2. dict を新しい NavigatorUABrandVersion 辞書として初期化し、brand に brand、version に version をセット。

   3. dict を 追加する。

4. ユーザーエージェントは次の手順を実行するべきです:

   1. list に1つ追加の item を追加し、NavigatorUABrandVersion 辞書を brand に 任意ブランド、version に 任意バージョン生成の結果をセットする。

   2. list の item の順序をランダム化する。

   注: これらのランダム要素生成時のキャッシュばらつき最小化には、ビルド時に決定し、ユーザーエージェントの重要バージョンの存続期間中は同一とする方法も考えられます。

   注: これらのランダム化処理のタイミングや理由については § 7.2 GREASEのようなUAブランドリスト を参照してください。

5. list を返す。

同等クラスは互換性があると考えられるブラウザのグループを表します。たとえば、共通レンダリングエンジンは 同等クラス を形成することがあります。

4.1.3. 任意のブランドとバージョン値の作成

任意ブランドの作成では、ユーザーエージェントは以下の手順を必ず実行する必要があります:

1. arbitraryBrand を 文字列として、ASCII英字と0x20 (SP)で構成します。arbitraryBrandは一つ以上の0x20 (SP)バイトを含み、20ASCIIバイト以内で、先頭・末尾が0x20 (SP)であってはなりません。

2. arbitraryBrandList を ASCII空白で arbitraryBrand を分割した結果とします。

3. greaseyStack を スタックとします。

4. greaseyChars を リストとして « 0x20 (SP), 0x28 (左括弧), 0x29 (右括弧), 0x2D (-), 0x2E (.), 0x2F (/), 0x3A (:), 0x3B (;), 0x3D (=), 0x3F (?), 0x5F (_) » のASCIIバイトを格納します。

5. index を0とします。

6. indexがarbitraryBrandListのサイズ−1より小さい間、以下を繰り返します:

   1. greaseyStackへ greaseyCharsからランダムに選ばれたitemをpushします。

   2. indexを1増やします。

7. greaseyBrandList を リストとして、indexを0にします。

8. greaseyStack が空でない間、以下を繰り返します:

   1. greaseyBrandListへ arbitraryBrandList[index] を追加します。

   2. item を greaseyStackからpopした結果とします。

   3. greaseyBrandListへ item を追加します。

   4. indexを1増やします。

9. greaseyBrandListへ arbitraryBrandList[index] を追加します。

10. 先頭・末尾のASCII空白除去したgreaseyBrandListの連結（区切り無し）の結果を返します。

任意バージョンの作成はversion typeを与えて、以下の手順を実行します:

1. Assert version typeは"full version"または"significant version"のいずれかであること。

2. arbitrary versionを文字列として、次のように初期化します:

   1. version typeが"full version"なら、arbitrary versionをフルバージョンの形式に一致させますが、値自体は一致させません。

   2. version typeが"significant version"なら、arbitrary versionを重要バージョンの形式に一致させますが、値自体は一致させません。

3. arbitrary versionを返します。

注: ユーザーエージェントは、適切なバージョンチェックのために任意に低いバージョン値を送ることがあり、時期によって値を変えるべきです。

4.1.4. ブランド-バージョンリスト作成

ブランド-バージョンリスト作成はbrandsとversion typeを与えて、次の手順を実行します:

1. list を リストとして初期化（空）。

2. Assert version typeは"full version"または"significant version"のいずれかであること。

3. brands内の各brandについて:

   1. versionを文字列として、次の通り初期化:

      1. version typeが"full version"なら、versionをフルバージョンに対応する文字列。

      2. version typeが"significant version"なら、versionを重要バージョンに対応する文字列。

   2. parameterを辞書として初期化（空）。

   3. parameter["param_key"]に "v" をセット。

   4. parameter["param_value"]にversionをセット。

   5. pairをbrandのbrandとparameterのタプルとする。

   6. listへ pairを追加。

4. listを返す。

4.1.5. ゲッター

取得時、brands 属性は、thisの関連グローバルオブジェクトのbrands frozen arrayを返さなければなりません。

取得時、mobile 属性は、ユーザーエージェントのモバイル性を返す必要があります。

取得時、platform 属性は、ユーザーエージェントのプラットフォームブランドを返す必要があります。

4.1.6. getHighEntropyValues メソッド

getHighEntropyValues(hints) メソッドは以下の手順を必ず実行します:

1. pを新しいpromiseとして、現在のrealmで作成します。

2. uaDataを新しいUADataValuesとします。

3. uaData["brands"] に thisの関連グローバルオブジェクトのbrands frozen arrayをセットします。

4. uaData["mobile"] に、ユーザーエージェントのモバイル性をセットします。

5. uaData["platform"] に、ユーザーエージェントのプラットフォームブランドをセットします。

6. もしthisの関連グローバルオブジェクトの関連Documentがch-ua-high-entropy-values機能の利用を許可されていない場合、pをuaDataでresolveします。

7. それ以外の場合、以下の手順を並行して実行します:

   1. もしhintsが"architecture"を含むなら、uaData["architecture"] にユーザーエージェントのプラットフォームアーキテクチャをセット。

   2. もしhintsが"bitness"を含むなら、uaData["bitness"] にユーザーエージェントのプラットフォームビット数をセット。

   3. もしhintsが"formFactors"を含むなら、uaData["formFactors"] にユーザーエージェントのフォームファクターをセット。

   4. もしhintsが"fullVersionList"を含むなら、uaData["fullVersionList"] にthisの関連グローバルオブジェクトのfull version list frozen arrayをセット。

   5. もしhintsが"model"を含むなら、uaData["model"] にユーザーエージェントのモデルをセット。

   6. もしhintsが"platformVersion"を含むなら、uaData["platformVersion"] にプラットフォームバージョンの取得の結果をセット。

   7. もしhintsが"uaFullVersion"を含むなら、uaData["uaFullVersion"]

   8. もしhintsが"wow64"を含むなら、uaData["wow64"] にユーザーエージェントのwow64性をセット。

   9. permission task sourceにタスクをキューし、pをuaDataで解決します。

8. pを返します。

4.1.7. toJSON メソッド

toJSON() メソッドは以下の手順を必ず実行します:

1. uaLowEntropyDataを新しいUALowEntropyJSONとします。

2. uaLowEntropyData["brands"] に thisの関連グローバルオブジェクトのbrands frozen arrayをセットします。

3. uaLowEntropyData["mobile"] に、ユーザーエージェントのモバイル性をセットします。

4. uaLowEntropyData["platform"] に、ユーザーエージェントのプラットフォームブランドをセットします。

5. uaLowEntropyDataを返します。

5. Permissions-Policy統合

この仕様は、文字列"ch-ua-high-entropy-values"で識別されるポリシー制御機能を定義しています。これは'*'のデフォルト許可リストを持ちます。これにより、特定ドキュメントがgetHighEntropyValues() API経由で高エントロピークライアントヒント値を返すかどうかが決まります。

注: ドキュメントが"ch-ua-high-entropy-values"機能の利用を許可されていない場合、getHighEntropyValues() APIは便宜上引き続き低エントロピー値を返します。

6. セキュリティとプライバシーの考慮点

6.1. セキュアな転送

Client Hintsは非セキュアなエンドポイントには配信されません（[RFC8942]のSection 2.2.1参照）。これは、ユーザーエージェント情報が平文チャネルで漏れることを防ぎ、ネットワーク攻撃者が特定エージェントの行動プロファイルを蓄積する機会を減らします。

6.2. 委任

Client HintsはPermissions Policy（[permissions-policy-1]）経由でトップレベルページから委任されます。これにより、ユーザーエージェント情報がサブリソースリクエストとともに送信される可能性が減り、パッシブフィンガープリンティングの潜在性が低減します。

この委任はappend client hints to requestの一部として定義されています。

6.3. フィンガープリンティング

User Agent Client Hintsの主な目的は、User-Agentヘッダーフィールドでウェブ全体に露出されるデフォルトのエントロピー量を減らし、パッシブフィンガープリンティングへの悪用を防ぐことです。

ユーザーエージェントは、どのヒントを提供するかを選択することができ、未編集のUser-Agentヘッダーに含まれる以上の情報が提供されないよう期待されます。ユーザーエージェントは、提供したくない値については空文字列を返したり、ヒント自体の返却を拒否できます。

ただし、一部またはすべてのヒントが要求され、第一者または委任された第三者によるアクティブフィンガープリンティングに使われる可能性は残ります。§ 6.4 アクセス制限で述べたように、ユーザーエージェントはユーザーを積極的にフィンガープリンティングすることが知られている当事者へのアクセス制限ポリシーを検討すべきです。

ユーザーエージェントは、個人またはごく少数のユーザにのみユニークとなるGREASEブランドリストによるフィンガープリンティングベクトルを作らないよう配慮すべきです。むしろ、任意ブランドが多くのユーザー間で共有される戦略（例: 全ユーザーのメジャーバージョンごとに安定させる）を取るべきです。

6.4. アクセス制限

上記Client Hintsで公開される情報は、ユーザーエージェントやその実行デバイスについてかなり多くの情報を明かします。ユーザーエージェントは、この情報へのアクセスを許可する前に慎重な判断を行うべきであり、上記のセキュアな転送・委任要件に加えて制限を課す場合があります。たとえば、ユーザーエージェントは、実行ファイルのダウンロードを意図したリクエストのみでプラットフォームアーキテクチャやプラットフォームビット数を公開したり、サーバーに公開する値をユーザーが制御できるようにしたり、明示的なユーザー操作（許可プロンプトや設定画面）でアクセスを管理することも可能です。

7. 実装上の考慮事項

7.1. 'User-Agent' ヘッダー

ユーザーエージェントはUser-Agentヘッダーの使用を非推奨とし、本ドキュメントで説明するClient Hintsモデルへの情報粒度の移行を推奨すべきです。このヘッダーは、既存サイトのコンテンツネゴシエーションコードが引き続き必要とするため、近い将来完全に削除することは困難と考えられます（新しいブラウザがこの分野で苦労した最近の例については[Rossi2015]参照）。

推奨される方法としては、各ユーザーエージェントが自身のUser-Agentヘッダー値を固定し、互換性維持のため"like Gecko"や"AppleWebKit/537.36"のような古い宣言を永続保持することです。これは時間とともに、まずバージョン番号の固定、そしてプラットフォームやモデル情報をより一般的なものに変えることで、ヘッダーの提供するフィンガープリントを削減できます。

7.2. GREASEのようなUAブランドリスト

歴史的に、ユーザーエージェントは自身のブランドを偽り、サイトのUA判定スクリプトをすり抜けたり、UAベースの許可/拒否リストでユーザーがブロックされるのを防ぐ動機が強く働いてきました。

短期的にはブランドリストの悪用を防ぐために期待値をリセットすることも有効ですが、長期的には十分ではありません。ネットワークプロトコルの世界ではGREASEという概念が導入されています（[I-D.ietf-tls-grease]）。 この考え方をこの問題に応用できます。

複数の値から成るbrandsを持つことで、brandsリストの標準的な処理を促進できます。ランダムに追加された意図的に誤ったカンマ区切りの値を順序を変えて含めることで、特定文字列への固着（ossification）を防ぎやすくなります。

いくつかの例を挙げてみます:

• 未知のブラウザを許可リストから排除しないようにするため、Chromeは存在しないブラウザブランドをUAセットに含め、時々入れ替えることができます。

  • "Chrome"; v="73", "(Not;Browser"; v="12"

• Chromiumバージョンによる同等クラスを有効化するため、Chromeはレンダリングエンジンとそのバージョンを追加できます。

  • "Chrome"; v="73", "(Not;Browser"; v="12", "Chromium"; v="73"

• Chromiumバージョンによる同等クラスへの依存を促進するために、Chromeが自身をセットから外すこともできます。

  • "(Not;Browser"; v="12", Chromium"; v="73"

• Chromiumベースの他のブラウザも同様のUA文字列を使い、自身のブランドもセットに含めることでサイトが個別集計できるようにします。

  • "Chrome"; v="73", "Xwebs mega"; v="60", "Chromium"; v="73", "(Not;Browser"; v="12"

ユーザーエージェントは必ずbrandsに複数値（うち一つは任意値）を含めなければなりません。

brandsの値の順序は、受信側が特定値の位置に依存しないよう、時期によって変化しなければなりません。

GREASE戦略選択時は、ユーザーエージェントはキャッシュばらつきや分析用途を考慮し、同一ユーザーエージェントバージョン間でばらつきを最小化すべきです。

注: キャッシュや分析のばらつき最小化には、UAセット内のGREASE値をビルド時に決定し、ユーザーエージェントの重要バージョン存続期間中は同一にする方法が考えられます。

7.3. 'Sec-CH-' プレフィックス

ユーザーランドJavaScriptによるUA-CHヘッダーの操作・改変を禁止することで、セキュリティ面で多くの利点があります。一方、ユースケース上、ユーザーランドでの書き換えが求められる正当な理由は見当たりません。

そのため、TAGとの議論に基づき、JavaScript（例: fetchやService Workers）からこれらヘッダーへの書き込みを禁止し、ブラウザ制御のクライアントヒントとして区別することで、CORSプリフライトを発生させずにドキュメント化・リクエストに含めることが合理的です。

このため、本仕様で定義するリクエストヘッダーはSec-CH-プレフィックスを含みます。

8. IANAに関する考慮事項

この文書は Sec-CH-UA, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Form-Factors, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA-WoW64, および Sec-CH-UA-Full-Version-List のHTTPリクエストヘッダーフィールドを定義し、パーマネントメッセージヘッダーフィールドレジストリ ([RFC3864]) に登録することを意図しています。

また、User-Agent ヘッダーフィールドの使用を非推奨にすることも意図しています。

8.1. 'Sec-CH-UA' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.1 'Sec-CH-UA' ヘッダーフィールド)

8.2. 'Sec-CH-UA-Arch' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Arch

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.2 'Sec-CH-UA-Arch' ヘッダーフィールド)

8.3. 'Sec-CH-UA-Bitness' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Bitness

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.3 'Sec-CH-UA-Bitness' ヘッダーフィールド)

8.4. 'Sec-CH-UA-Form-Factors' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Form-Factors

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.4 'Sec-CH-UA-Form-Factors' ヘッダーフィールド)

8.5. 'Sec-CH-UA-Full-Version' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Full-Version

適用プロトコル: http

ステータス: 非推奨

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.5 'Sec-CH-UA-Full-Version' ヘッダーフィールド)

8.6. 'Sec-CH-UA-Full-Version-List' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Full-Version-List

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.6 'Sec-CH-UA-Full-Version-List' ヘッダーフィールド)

8.7. 'Sec-CH-UA-Mobile' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Mobile

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.7 'Sec-CH-UA-Mobile' ヘッダーフィールド)

8.8. 'Sec-CH-UA-Model' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Model

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.8 'Sec-CH-UA-Model' ヘッダーフィールド)

8.9. 'Sec-CH-UA-Platform' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Platform

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.9 'Sec-CH-UA-Platform' ヘッダーフィールド)

8.10. 'Sec-CH-UA-Platform-Version' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-Platform-Version

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.10 'Sec-CH-UA-Platform-Version' ヘッダーフィールド)

8.11. 'Sec-CH-UA-WoW64' ヘッダーフィールド

ヘッダーフィールド名: Sec-CH-UA-WoW64

適用プロトコル: http

ステータス: 標準

著者/変更管理者: IETF

仕様書: この仕様 (§ 3.11 'Sec-CH-UA-WoW64' ヘッダーフィールド)

8.12. 'User-Agent' ヘッダーフィールド

ヘッダーフィールド名: User-Agent

適用プロトコル: http

ステータス: 非推奨

著者/変更管理者: IETF

仕様書: この仕様 (§ 7.1 'User-Agent' ヘッダーフィールド) と [rfc9110] のSection 5.5.3

9. 謝辞

この仕様への貴重なフィードバックおよび貢献に対して Aaron Tagliaboschi、 Ali Beyad、 ArkUmbra、 Dustin Mitchell、 Erik Anderson、 jasonwee、 Luke Williams、 Mike West、 Martin Thomson、 そして Toru Kobayashi に感謝します。