ユーザー エージェントの情報量削減とは

ユーザー エージェント（UA）の情報量削減は、パッシブ フィンガープリントに使用される可能性がある、ユーザー エージェント文字列で共有される識別情報を最小限に抑えます。これらの変更が一般提供にロールアウトされたため、すべてのリソース リクエストの User-Agent ヘッダーは縮小されています。その結果、特定の Navigator インターフェース（navigator.userAgent、navigator.appVersion、navigator.platform など）からの戻り値が削減されます。

User-Agent 文字列の使用についてサイトコードを確認する必要があります。ユーザー エージェント文字列の解析に依存してデバイスモデル、プラットフォーム バージョン、ブラウザのフルバージョンを読み取る場合は、User-Agent Client Hints API を実装する必要があります。

User-Agent Client Hints（UA-CH）

User-Agent Client Hints は、すべての User-Agent データにアクセスできますが、サーバーが特定のデータに対する明示的な必要性を積極的に宣言している場合に限ります。

パッシブに公開されたユーザーデータを削除することで、リクエスト ヘッダー、JavaScript API、その他のメカニズムによって意図的に公開される情報の量をより適切に測定し、削減できます。

UA と UA-CH の削減が必要な理由

これまでユーザー エージェント文字列は、HTTP リクエストごとに、ユーザーのブラウザ、オペレーティング システム、バージョンに関する大量のデータ文字列をブロードキャストしていました。これには、次の 2 つの理由から問題がありました。

  • 詳細の粒度と豊富さは、ユーザーの識別につながる可能性があります。
  • この情報はデフォルトで利用可能になっているため、隠れたトラッキングが行われる可能性があります。

UA と UA-CH の削減により、デフォルトで基本情報のみが共有されるため、ユーザーのプライバシーが向上します。

削減されたユーザー エージェントには、リクエストの送信元であるブラウザのブランドと重要なバージョン（パソコンまたはモバイル）、プラットフォームが含まれます。より多くのデータにアクセスするには、User-Agent Client Hints を使用して、ユーザーのデバイスや状態に関する特定の情報をリクエストできます。

さらに、User-Agent 文字列は時間の経過とともに長く複雑になり、エラーが生じやすい文字列の解析になっていました。UA-CH は、解釈しやすい構造化データと信頼性の高いデータを提供します。UA 文字列を解析する既存のコードは中断できません（ただし、返されるデータは少なくなります）。また、サイトで特定のクライアント情報が必要な場合は、UA-CH に移行する必要があります。

削減された UA と UA-CH の仕組み

削減された User-Agent 文字列と UA-CH の仕組みの簡単な例を以下に示します。 詳細な例については、User-Agent Client Hints によるユーザーのプライバシーとデベロッパー エクスペリエンスの向上をご覧ください。

ユーザーがブラウザを開き、アドレスバーに「example.com」と入力します。

  1. ブラウザが、ウェブページを読み込むリクエストを送信します。

    1. ブラウザには、ユーザー エージェント文字列を削減した User-Agent ヘッダーが含まれます。たとえば、User-Agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.0.0 Mobile Safari/537.36 です。

    2. ブラウザは、デフォルトの User-Agent Client Hints ヘッダーに同じ情報を含めます。次に例を示します。

      Sec-CH-UA: "Chrome"; v="98"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

  2. サーバーは、Accept-CH レスポンス ヘッダーを使用して、デバイスモデルなど、追加の Client Hints を送信するようブラウザに要求できます。たとえば、Accept-CH: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA-Model です。

  3. ブラウザは、ポリシーとユーザー構成を適用して、後続のリクエスト ヘッダーでサーバーに返すことを許可するデータを決定します。次に例を示します。

    Sec-CH-UA: "Chrome"; v="93"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"
Sec-CH-UA-Model: "Pixel 2"

重要な Client Hints

最初のリクエストで特定の Client Hints のセットが必要な場合は、Critical-CH レスポンス ヘッダーを使用できます。Critical-CH 値は、Accept-CH によってリクエストされた値のサブセットである必要があります。

たとえば、最初のリクエストには Device-Memory と Viewport-Width のリクエストが含まれ、ここで Device-Memory は重大とみなされます。

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory, Viewport-Width
Vary: Device-Memory, Viewport-Width
Critical-CH: Device-Memory

ウェブページを適切に表示するために重要なヒント（Critical-CH）がブラウザで必要になる場合、サーバーは Accept-CH ヘッダーを使用してこの追加情報をリクエストできます。その後、ブラウザは重要なヒントを含むページに対する新しいリクエストを送信できます。

まとめると、Accept-CH はページに必要なすべての値をリクエストしますが、Critical-CH はページを適切に読み込むために読み込み時に必要とする値のサブセットのみをリクエストします。詳しくは、Client Hints の信頼性仕様をご覧ください。

UA-CH API を使用してタブレット デバイスを検出する

モバイル、タブレット、デスクトップ デバイスの境界線はますます狭くなり、動的なフォーム ファクタが一般的になっています（折りたたみ画面、ノートパソコン モードとタブレット モードの切り替えなど）。レスポンシブ デザインと機能検出を使用して、適切なユーザー インターフェースを表示することをおすすめします。

ただし、User-Agent 文字列と User-Agent Client Hints の両方にブラウザが提供する情報は、同じソースから取得されるため、同じ形式のロジックが機能します。

たとえば、UA 文字列でこのパターンがオンになっている場合、次のようになります。

  • 電話パターン: 'Android' + 'Chrome/[.0-9]* Mobile'
  • タブレットのパターン: 'Android' + 'Chrome/[.0-9]* (?!Mobile)'

一致するデフォルトの UA-CH ヘッダー インターフェースを確認できます。

  • 電話パターン: Sec-CH-UA-Platform: "Android"、Sec-CH-UA-Mobile: ?1
  • タブレットのパターン: Sec-CH-UA-Platform: "Android"、Sec-CH-UA-Mobile: ?0

または、同等の JavaScript インターフェースを使用します。

  • 電話パターン: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === true
  • タブレットのパターン: navigator.userAgentData.platform === 'Android' && navigator.userAgentData.mobile === false

ハードウェア固有のユースケースでは、高エントロピー Sec-CH-UA-Model ヒントを使用してデバイスモデル名をリクエストできます。

低減された UA を使用してテストするにはどうすればよいですか？

まず、サイトコードを確認して、User-Agent 文字列のインスタンスと使用を確認します。ユーザー エージェント文字列の解析に依存してデバイスモデル、プラットフォーム バージョン、ブラウザのフル バージョンを読み取っているサイトの場合は、UA-CH API を実装する必要があります。

UA-CH API に更新したら、ユーザー エージェントから想定どおりのデータを取得できるかテストする必要があります。テスト方法は 3 つあり それぞれ複雑さが増します

ユーザー エージェントの情報量削減のスケーリングにより、すべての Chrome デバイスにリリースされる UA 文字列は完全に削減されます。量の削減は、2022 年第 2 四半期の Chrome のマイナー リリースから開始されました。

カスタム文字列をローカルでテストする

カスタムのユーザー エージェント文字列を使用してさまざまなデバイスをシミュレートしてサイトをテストする場合は、--user-agent="Custom string here" コマンドライン フラグを指定して Chrome を起動します。詳細については、コマンドライン フラグをご覧ください。

または、Chrome DevTools でデバイス エミュレータを使用します。

サイトのコード内で文字列を変換する

既存の Chrome の user-agent 文字列をクライアント側またはサーバー側のコードで処理する場合、その文字列を新しい形式に変換して、互換性をテストできます。テストするには、文字列をオーバーライドして置換するか、新しいバージョンとテストを並べて生成します。

Client Hints と Critical Hints のサポート

サーバーに返される 3 つのデフォルトの Client Hints（ブラウザ名とメジャー バージョン、ブラウザがモバイル デバイスにあるかどうかを示すブール値、オペレーティング システム名）があります。これらは、Transport Layer Security Protocol（TLS）ハンドシェイクの後に送信されます。これらはブラウザですでに利用可能で、サポートされています。

ただし、サイトをレンダリングするために重要な情報を取得しなければならない場合もあります。

重要なヒントを最適化する

TLS handshake は、ブラウザとウェブサーバーの間に安全な接続を確立するための最初のステップです。Critical-CH レスポンス ヘッダーは、何もしなくても、最初のリクエストが重大なヒントなしで送信された場合に、すぐにリクエストを再試行するようブラウザに伝えるように設計されています。

重要なヒントを含む Client Hints のシーケンス図。
サーバーからクリティカル ヒントがリクエストされると、クライアントは、クリティカル ヒントを含むウェブページに対する最初のリクエストを再試行します。この例では、Sec-CH-UA-Model のヒントが 2 回リクエストされます。1 回目は Accept-CH を使用した Client Hints で、2 回目は Critical-CH を使用した重要なヒントです。

クリティカル ヒント（Critical-CH ヘッダー）を最適化するには、この handshake をインターセプトし、Client Hints のモデルを提供する必要があります。これらの手順は複雑で、高度な知識が必要になる場合があります。

ACCEPT_CH HTTP/2 および HTTP/3 フレームと TLS ALPS 拡張機能の組み合わせは、サーバーの Client Hints 設定を最初の HTTP リクエストに時間どおりに配信するための接続レベルの最適化です。これらは複雑な構成を必要とするため、本当に重要な情報についてのみ、この方法を使用することをおすすめします。

BoringSSL（OpenSSL のフォーク）を使用すると、Chromium で Google の試験運用版機能を使用できます。現時点では、ALPS は BoringSSL にのみ実装されています。

重要なヒントを使用する必要がある場合は、重要なヒントの信頼性と最適化に関するガイドをご覧ください。

よくある質問

Accept-CH ヘッダーで指定されたヒントはどのくらいの期間送信されますか？

Accept-CH ヘッダーで指定されたヒントは、ブラウザ セッションの間、または別のヒントセットが指定されるまで送信されます。

UA-CH は HTTP/2 および HTTP/3 で動作しますか？

UA-CH は HTTP/2 と HTTP/3 の両方の接続で動作します。

サブドメイン（および CNAME）で高エントロピー UA-CH にアクセスするには、トップレベル ページ Permissions-Policy が必要ですか？

リクエスト ヘッダーの高エントロピー UA-CH は、そのオリジンが DNS 側でどのように定義されているかにかかわらず、クロスオリジン リクエストでは制限されます。委任は、クロスオリジン サブリソースの Permissions-Policy を介して処理するか、クロスオリジン コンテキストで実行される JavaScript を介して取得する必要があります。

ユーザー エージェントの情報量削減が bot 検出に与える影響

Chrome で User-Agent 文字列を変更しても、bot が送信することを選択した User-Agent 文字列に直接影響することはありません。

bot は Chrome が送信する情報量の削減を反映するために独自の文字列を更新することを選択できますが、これは完全に実装の選択です。Chrome は引き続き同じユーザー エージェント形式を送信しており、bot が Chrome ユーザー エージェント文字列の末尾に独自の識別子を付加した場合も引き続き送信可能です。

特定の bot に関する懸念がある場合は、ユーザー エージェント文字列を変更する予定があるかどうかをオーナーに直接問い合わせることをおすすめします。

交流とフィードバックの共有

補足説明