フィンガープリントとは、ユーザーがウェブサイトに戻ったときにユーザーを識別しようとすること、または異なるウェブサイト間で同じユーザーを識別することです。多くの特徴は、自分の設定と他の人の設定とで異なる場合があります。たとえば、使用するデバイスとブラウザが異なる、画面サイズが異なる、インストール済みのフォントが異なる、などが考えられます。「Dejavu Sans」というフォントがインストールされていて、インストールされていない場合、どのウェブサイトでもフォントを確認することで、あなたと私の違いを判断できます。これがフィンガープリントの仕組みです。これらのデータポイントのコレクションを構築し、それぞれがユーザーを区別するためのより多くの方法を提供します。
より正式な定義は次のようになります。フィンガープリントとは、ユーザー設定に関する明白で明白でない長期間の特性を使用して、可能な限り多くの他のユーザーと区別しようとするアクションです。
フィンガープリントがユーザーのプライバシーを阻害する理由
不正行為の検出など、ユーザーのフィンガープリントが重要なエッジケースがいくつかあります。ただし、フィンガープリントは、サイトをまたいでユーザーをトラッキングする場合にも使用されます。このトラッキングは、ユーザーの同意なしに行われることが多く、場合によってはユーザーに十分な情報を提供していない無効な同意に基づいて行われます。そうすると、ユーザーは不安を感じ、裏切られたように感じることがよくあります。
フィンガープリントとは、あるユーザーと別のユーザーをひそかに区別する方法を見つけることです。フィンガープリントを使用すると、同じウェブサイト上の同じユーザーであることや、2 つの異なるブラウザ プロファイルで同じユーザーを同時に認識することができます。つまり、フィンガープリントを使用すると、サイトをまたいでユーザーをトラッキングできます。一意のユーザー固有の ID で Cookie を保存するなど、決定論的で明白なトラッキング方法は、ある程度はユーザーが観察して制御することができます（前のモジュールで、これらのアプローチの一部について説明しました）。ただし、フィンガープリントは秘密であるため、厳密に回避することはより困難です。変化しない特性に依存しており、ほとんどの場合、目に見えない形で発生します。これが「フィンガープリント」と呼ばれる理由です。デジタル指紋でも指の端にある指紋でも、変更するのは非常に困難です。
ブラウザ ベンダーは、ユーザーがトラッキングされることを好まないことを認識しており、フィンガープリントを制限する機能を継続的に実装しています（その一部は前のモジュールで確認しました）。ここでは、これらの機能がビジネス要件に及ぼす影響と、プライバシーを保護しながら必要な機能を実現する方法について説明します。これは、フィンガープリントに対するブラウザ保護が、フィンガープリントの実行を止める方法ではなく、実行内容とその方法にどのように影響するかという点に重点を置いています。
実際には、ほとんどのデベロッパーとほとんどの企業は、ユーザーのフィンガープリントを作成する必要がありません。アプリでユーザーにログインが必要な場合、ユーザーは同意を得たうえで、いつでも一方的にオプトアウトできる方法で、デベロッパーに対して本人確認を行います。これは、ログインしているユーザーを把握するための、プライバシーを保護するための方法です。アプリでは、ユーザーにログインをまったく求めなくても、ユーザーのプライバシーをより一層保護できます（これにより、必要なデータのみが収集されます）。
推奨事項
サードパーティがフィンガープリントを行うかどうかを評価します。サードパーティ サービスと、そのサービスが行うウェブ リクエストの一覧が、サードパーティ モジュールですでに提供されている場合があります。これらのリクエストを検査して、送信元に返されているデータ（ある場合）を確認できます。ただし、多くの場合、これは困難です。フィンガープリントは本質的に秘密のプロセスであり、ユーザーの承認を伴わないデータのリクエストが含まれます。
サードパーティのサービスと依存関係のプライバシー ポリシーを読んで、使用中のフィンガープリントの兆候を見つけることもおすすめします。「確定的マッチング」ではなく「確率的マッチング」と呼ばれることもあります。また、「確定的マッチング」ではなく「確率的マッチング」と呼ばれることもあります。
フィンガープリントの仕組み
多くの場合、これらの属性の個人の組み合わせは、あなた自身、または少なくとも似たような少数のグループに固有のものです。これは、あなたをひそかに追跡するために使用できます。
補足: パッシブ フィンガープリントとアクティブ フィンガープリント
ここで、パッシブ フィンガープリント手法とアクティブ フィンガープリント手法には有用な違いがあります。パッシブ フィンガープリントは、デフォルトでウェブサイトに提供された情報を使用する手法です。アクティブ フィンガープリントは、ブラウザに対して明示的に追加情報を調べる手法です。この区別が重要な理由は、ブラウザはアクティブな手法の検出と傍受、または軽減を試みる可能性があるためです。API を制限できます。または、ユーザーに権限を求めるダイアログの背後で API を設定できます（これにより、API が使用されていることをユーザーに警告するか、ユーザーがデフォルトで拒否できるようにできます）。受動的手法とは、ウェブサイトにすでに提供されているデータを使用する手法です。多くの場合、情報スーパーハイウェイの新興期には、その情報がすべてのサイトに与えられていたためです。ユーザー エージェント文字列はその一例であり、これについては後で詳しく説明します。ユーザーのブラウザ、バージョン、オペレーティング システムに関する多くの情報を提供し、それに基づいてウェブサイトが異なる内容を表示する際に有用と考えられていました。ただし、これにより、使用可能な識別情報、つまりユーザーを識別できる情報の量も増加します。そのため、このような情報は今後利用できなくなるか、少なくとも凍結されて区別できなくなります。この情報に依存する場合（ユーザー エージェントごとに異なるコードブランチを使用している場合など）、ブラウザがその情報を固定または停止するようになり、このコードが機能しなくなる可能性があります。テストはここでの最善の防御です（後述）。
補足: フィンガープリント可能性の測定
これらのデータポイントが提供する情報の量の技術的な尺度はエントロピーと呼ばれ、ビット単位で測定されます。取り得る値が多数ある機能（インストールされているフォントのリストなど）は、全体に占める割合も多くなります。そのため、識別能力があまりないもの（使用しているオペレーティング システムなど）では、わずかな値しか追加されない場合があります。HTTP Almanac では、さまざまな API からのレスポンスを「ハッシュ」に結合するこのプロセスが、既存のフィンガープリント ライブラリによって自動化されている仕組みについて説明しています。これは、少数のユーザー グループ（おそらくは 1 人だけ）を識別することもあります。Maud Nalpas が、こちらの YouTube 動画でこれについて詳しく説明していますが、簡単に言うと、友だちのリストで、友だちの好きな音楽、好きな食べ物、使用言語のリストが表示され、友だちの名前が削除されたとします。1 人のリストによって、その人を友だちの中で一意に識別できる可能性が高くなり、少なくとも、少数のユーザーのみに絞り込まれます。これがフィンガープリントの仕組みです。好きなもののリストが「ハッシュ」になります。このハッシュを使用すると、接続されていない 2 つのサイトでユーザーを同一人物として識別しやすくなります。トラッキングの目的は、ユーザーのプライバシー要求を回避することです。
ブラウザはフィンガープリントに対してどのように対処しますか？
重要なのは、ウェブサイト（またはウェブサイトに含まれるサードパーティ）がユーザーの識別フィンガープリントを計算したり、フィンガープリントの一意性に寄与する異なる情報を組み合わせたりする方法を、ブラウザ ベンダーが十分に認識しているということです。これらの方法の中には、ブラウザのユーザー エージェント文字列など、明示的かつ意図的なものもあります。ユーザー エージェント文字列は、多くの場合、ブラウザ、オペレーティング システム、使用中のバージョンを識別します（あなたと私が異なるブラウザを使用している場合、あなたと私を区別するのに役立ちます）。フォントのリスト、ブラウザで使用できるビデオ / オーディオ デバイスなど、一部の方法はフィンガープリントを意図的に作成していないにもかかわらず、最終的にはそうすることになっています。（ブラウザでこれらのデバイスを使用する必要はなく、名前でデバイスのリストを取得するだけです）。また、キャンバス要素上のフォントのアンチエイリアスの正確なピクセル レンダリングなど、リリースのかなり後もフィンガープリントに寄与することが確認されています。他にもたくさんあり、ブラウザが私のものと異なる方法によってエントロピーが追加されるため、あなたと私の違いを識別し、ウェブサイト間で個人をできるだけ一意に識別する方法に寄与する可能性があります。https://amiunique.org には、指紋に寄与する可能性のある機能のリストが長く（ただし、間違いなく包括的ではない）リストがあります。ユーザーが指紋や金銭的関心を強く望まない場合、リストは常に増え続けます。
特定の強力な API をサポートしていない
ユーザーのフィンガープリントを計算するための上記のすべてのアプローチに対するブラウザ ベンダーからの回答は、これらの API から利用可能なエントロピーの量を減らす方法を見つけるというものです。最も制限の厳しい選択肢は、そもそもこれらを実装しないことです。これは、さまざまなハードウェアとデバイスの API（クライアントサイド ウェブアプリからの NFC や Bluetooth アクセスなど）向けに、いくつかの主要なブラウザで行われており、フィンガープリントが実装されていない理由として、フィンガープリントとプライバシーに関する懸念が挙げられています。これは明らかに、アプリやサービスに影響を与える可能性があります。API を実装していないブラウザでは API をまったく使用できないため、一部のハードウェア アプローチが制限または完全に除外される可能性があります。
ユーザー権限ゲートウェイ
ブラウザ ベンダーが採用している 2 つ目のアプローチは、なんらかの明示的なユーザー許可なしに API やデータにアクセスできないようにすることです。この方法は、セキュリティ上の理由からもよく使用されます。ウェブサイトは、ユーザーの許可なくウェブカメラで写真を撮影できないようにする必要があります。プライバシーとセキュリティには、似たような関心事があるかもしれません。もちろん、誰かの位置情報を特定すること自体はプライバシー侵害ですが、指紋の一意性の要因でもあります。位置情報を表示する権限を要求しても、位置情報によってフィンガープリントの一意性が増す余計なエントロピーは減少しませんが、目に見えない形でフィンガープリントを実行することがなくなるため、基本的に位置情報をフィンガープリントに使用することはなくなります。フィンガープリントの目的は、ユーザーを密かに区別することです。識別しようとしていることをユーザーが認識できるようにする場合は、フィンガープリント手法は必要ありません。ユーザーにアカウントを作成してもらい、そのアカウントを使用してログインしてもらいます。
予測不可能性の追加
場合によって使用される 3 つ目のアプローチは、ブラウザ ベンダーが API からのレスポンスを「ファジング」して、粒度を下げて識別性を下げることです。これは、データ モジュールのランダム化レスポンス メカニズムの一部として、ユーザーからデータを収集する際に、識別対象のデータを誤って収集しないようにする方法として説明しました。ブラウザ ベンダーは、ウェブアプリやサードパーティが利用できる API データに対してもこのアプローチを採用できます。一例として、window.performance.now() のページ パフォーマンスの測定に使用する非常に正確な Timing API があります。ブラウザはこれらの値をマイクロ秒単位の精度で認識しますが、フィンガープリントでの使用を避けるために（もちろんタイミング攻撃を回避するセキュリティのためにも）最も近い 20 マイクロ秒境界に丸めて、値の精度を意図的に下げています。ここでの目標は、API の有用性を維持しつつ、レスポンスの識別性を低くすることです。つまり、デバイスを自分に独特なものではなく、他人のデバイスのように見せることで、本質的に「集団免疫」を提供することです。Safari では、システム構成の簡素化されたバージョンが用意されているのはこのためです。
プライバシー バジェットの適用
プライバシー バジェットは、各フィンガープリント サーフェスによって明らかになる情報をブラウザが推定することを提案する提案です。まだブラウザに実装されていません。その目的は、ユーザーのプライバシーを保護しながら強力な API を使用できるようにすることです。プライバシー予算の提案に関する詳細
広範なテスト環境を使用する
これらはすべて、アプリやサービスの構築方法に影響します。特に、この分野のブラウザとプラットフォームには多種多様なレスポンスやアプローチがあります。つまり、複数の異なる環境で作業をテストすることが重要です。もちろん、これは常に重要ですが、特定のレンダリング エンジンにブラウザやプラットフォームがあっても、HTML レンダリングまたは CSS が一定であると仮定するのが合理的です（そのため、たとえば 1 つの Blink ベースのブラウザでのみテストしたくなるかもしれません）。これは明らかに API の使用には当てはまりません。レンダリング エンジンを共有するブラウザは、フィンガープリントに対して API サーフェスを強化する方法が大きく異なる可能性があるためです。
推奨事項
- ご自身のアナリティクスとオーディエンスを確認して、テスト時に優先すべきブラウザ群を決定します。
- テストに適したブラウザには、Firefox、Chrome、Edge、パソコンの Safari、Android の Chrome と Samsung Internet、iOS の Safari などがあります。これにより、3 つの主要なレンダリング エンジン（Firefox の Gecko、Chrome、Edge、Samsung Internet の Blink の各種フォーク、Safari の Webkit）と、モバイルとパソコンの両方のプラットフォームでテストを実施できます。
- サイトがタブレット、スマートウォッチ、ゲーム機などのあまり一般的でないデバイスでも使用されている可能性がある場合は、それらのデバイスでもテストします。 一部のハードウェア プラットフォームでは、モバイルやパソコンでブラウザの更新に遅れが生じることがあります。つまり、これらのプラットフォームのブラウザで一部の API が実装されていないか、使用できない可能性があります。
- ユーザーのプライバシーをモチベーションと主張している 1 つ以上のブラウザでテストします。Safari のテクノロジー プレビュー、Chrome の Canary、Firefox の Beta チャンネルなど、一般的なブラウザの今後のプレリリース バージョンとテスト バージョンを可能な限り提供します。API の互換性の維持により、ユーザーに影響が及ぶ前に、サイトに影響する API の互換性の問題や変更を特定できます。同様に、既存のアナリティクスはユーザーの環境を考慮します。ユーザーベースに古い Android スマートフォンが多数ある場合は、それらもテストに含めてください。開発チームのように高速なハードウェアや最新リリースを利用できる人はほとんどいません。
- クリーンなプロファイルとシークレット/シークレット ブラウジング モードの両方を使用してテストします。個人用プロファイルで必要な権限がすでに付与されている可能性があります。質問に対してサイトの権限を拒否した場合の動作をテストします。
- Firefox のフィンガープリント保護モードでページを明示的にテストします。これにより、ページでフィンガープリントを作成しようとしたときに権限ダイアログが表示され、一部の API ではファジングされたデータが返されます。 これにより、サービスに含まれる第三者がフィンガープリント可能なデータを使用しているか、独自のサービスがそれに依存しているかどうかを確認できます。その後、意図的なファジングによって、必要な処理が難しくなるかどうかを検討できます。必要に応じて修正を行い、データを別のソースから取得する、そのデータを使用せずに行う、またはより粒度の細かいデータを使用することを検討してください。
- 前述のサードパーティ モジュールで説明したように、サードパーティの依存関係を監査して、フィンガープリントの手法が使用されているかどうかを確認することも重要です。パッシブ フィンガープリントは検出が困難です（サードパーティがサーバーでそれを行っている場合は不可能です）。ただし、フィンガープリント モードでは、一部のフィンガープリント手法にフラグが付けられる場合があります。また、navigator.userAgent の使用や、
<canvas>オブジェクトの予期しない作成を探すと、さらに調査が必要なアプローチが見つかることもあります。また、サードパーティに関するマーケティング資料や技術資料で「確率的一致」という用語が使用されているかどうかを調べることも重要です。これは、フィンガープリント技術が使用されていることを示す場合があります。
クロスブラウザ テストツール
プライバシーを保護するためのコードテストを自動化するのは困難です。手動でテストする際に注意すべき点については、すでに説明しました。たとえばサイトがアクセスしようとしている API について、権限を拒否するとどうなりますか。また、ユーザーにどのように表示されますか。 自動テストでは、サイトがユーザーの信頼を損なうような動作をするのか、逆にユーザーに不信感を抱かせるのか、何かが隠されているとお考えになるのかを判断することはできません。
ただし、サイトの監査が完了したら、新しいブラウザ バージョン（または今後の「ベータ版」や「プレビュー版」）で不具合がないことを確認する API のテストを自動化できます。このテストの大部分は、既存のテストスイートの一部になります。API サーフェス カバレッジを使用する場合、自動テストツールで考慮すべき点として、ほとんどのブラウザでは、使用可能な API と機能をある程度制御できることが挙げられます。Chrome では、Firefox と同様に、コマンドライン スイッチを使用します。テストツールのセットアップでこのコマンドライン スイッチにアクセスできると、API をオンまたはオフにした状態で特定のテストを実行できます。（たとえば、起動時にブラウザフラグを追加する方法については、Cypress の browser-launch プラグインと、Puppeteer の launch.args パラメータをご覧ください）。
大まかな情報についてのみ user-agent 文字列を利用する
別の例として、ウェブの開始時から、ブラウザは HTTP User-Agent ヘッダーのすべてのリクエストで自身の説明を送信しています。以前から、ウェブ デベロッパーに対し、ユーザー エージェント ヘッダーの内容を使用してブラウザごとに異なるコンテンツを配信しないよう推奨してきました。そしてその間も、ウェブ デベロッパーは一部（ただしすべてではない）に一定の根拠を示してきました。ブラウザは、最適なユーザー エクスペリエンスを提供できないようウェブサイトが除外されることを望んでいないため、その結果、すべてのブラウザが他のすべてのブラウザになりすまし、ユーザー エージェント文字列は次のようになります。
Mozilla/5.0 (Linux; Android 6.0.1; SGP771 Build/32.2.A.0.253; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36.
とりわけ Mozilla/5.0 は 20 年以上前に最初の宇宙飛行士が国際宇宙ステーションに搭乗したのと同時にリリースされたブラウザであると主張しています。ユーザー エージェント文字列はフィンガープリントの豊富なエントロピーのソースであり、フィンガープリント可能性を軽減するために、ブラウザ メーカーはすでにユーザー エージェント ヘッダーを凍結しているか、その処理に取り組んでいます。これは、API を完全に削除することなく、API が提供するデータを変更するもう一つの例です。空の user-agent ヘッダーを送信すると、そのヘッダーが存在すると想定して無数のウェブサイトが動作しなくなってしまいます。ブラウザは一般的に、詳細情報の一部を取り除き、それ以降はほぼ変更しないままにします。（この問題は Safari、Chrome、Firefox で確認できます）。このように詳細なフィンガープリントから保護するということは、本質的には、ユーザー エージェント ヘッダーの精度に依存しなくなるということです。正確な場合は、代わりのデータソースを見つけることが重要です。
ユーザー エージェントのデータは完全になくなるわけではなく、精度が低いか、古いが変化しない数値が報告される可能性があるため、精度が低い場合があります。たとえば、Firefox、Safari、Chrome では、報告される macOS バージョン番号がすべて 10 に制限されています（詳しくは、ユーザー エージェント文字列の削減に関する更新をご覧ください）。Chrome がユーザー エージェント文字列のデータを削減する具体的な方法については、User-Agent Reduction をご覧ください。ただし、報告されるブラウザのバージョン番号にはメジャー バージョンのみが含まれ（そのため、ブラウザのバージョンが 123.10.45.108 であっても、バージョン番号は 123.0.0.0 のように表示され、OS のバージョンは 1 つの詳細に変更されません）したがって、架空の「Windows 20」で Chrome バージョン 123.45.67.89 を実行した場合、バージョン番号は次のようになります。
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/123.0.0.0 Safari/537.36
必要な情報（ブラウザのバージョン）は、Windows 版 Chrome 123 で引き続きご利用いただけます。ただし、チップ アーキテクチャ、Windows のバージョン、模倣している Safari のバージョン、ブラウザのマイナー バージョンなどは、フリーズ後はご利用いただけなくなります。
これを、別のプラットフォームの「現在の」Chrome ユーザー エージェントと比較します。
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36,
異なる点は Chrome のバージョン番号（104）とプラットフォーム ID だけです。
同様に、Safari のユーザー エージェント文字列にはプラットフォームと Safari のバージョン番号が表示され、iOS の OS のバージョンも示されますが、それ以外のものはすべてフリーズされます。したがって、仮想的な macOS 20 で実行されている架空の Safari バージョン 1234.5.67 のユーザー エージェントは次のようになります。
Mozilla/5.0 (Macintosh; **Intel Mac OS X 10_20_0**) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15,
架空の iOS 20 であれば、次のようになります。
Mozilla/5.0 (iPhone; CPU **iPhone OS 20_0** like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/**20.0 Mobile/15E148 Safari/605.1.15**.
繰り返しになりますが、コア情報（Safari で、iOS または macOS 用）は入手でき、iOS の Safari には現在も iOS のバージョン番号が用意されています。ただし、これまで入手できた付随情報のほとんどは、その後凍結されています。重要なのは、これには Safari のバージョン番号が含まれますが、この番号は必ずしも利用可能なわけではありません。
報告されたユーザー エージェントへの変更については、活発な議論が交わされました。https://github.com/WICG/ua-client-hints#use-cases の要約には、変更の根拠と理由のいくつかがまとめられています。また、Rowan Merewood は、UA の提案のコンテキストで、差別化のためにユーザー エージェントから移行するための戦略をいくつか解説したスライド資料を提供しています。
ファジング
ファジングとは、セキュリティ プラクティスにおける用語です。予期しない値をうまく処理してセキュリティの問題を明らかにするために、予期しない値で API を呼び出します。ウェブ デベロッパーはクロスサイト スクリプティング（XSS）に精通している必要があります。クロスサイト スクリプティングでは、挿入された HTML をページで正しくエスケープしない（<script> というテキストを使用して検索クエリを実行する）ために、ページに悪意のあるスクリプトを追加する処理が一般的です。バックエンド デベロッパーは SQL インジェクションに気付くでしょう。これは、ユーザー入力を正しく検証しないデータベース クエリによってセキュリティ上の問題が生じることです（特に、Little Bobby Tables の xkcd によって示されています）。ファジング（ファズテスト）は、さまざまな無効な入力や予期しない入力を API に提供し、セキュリティ リーク、クラッシュ、その他の不適切な処理の結果をチェックする自動試行に適しています。これらはすべて、意図的に不正確な情報を提供する例です。ただし、ここでは、デベロッパーにこのデータへの依存をやめるよう促すために、ブラウザが（ユーザー エージェントを意図的に不正確にして）予防的に行っています。
推奨事項
- コードベースで、ユーザー エージェント文字列への依存がないか確認します（
navigator.userAgentを検索すると、クライアント側のコードでほとんどのオカレンスが見つかる可能性があり、バックエンド コードは依存関係を含むUser-Agentをヘッダーとして探します）。 - 独自のコード内で使用を見つけたら、そのコードが何をチェックしているかを調べて、その区別を行うための別の方法を見つけます（または、代わりの依存関係を見つけるか、問題を報告するか更新を確認して、アップストリームの依存関係について作業します）。バグを回避するためにブラウザの差別化が必要になることもありますが、凍結されると、ユーザー エージェントがこれを行う方法ではなくなります。
- 安全かもしれません。ブランド、メジャー バージョン、プラットフォームのコアバリューのみを使用している場合は、ほぼ間違いなく、ユーザー エージェント文字列で正確な値を使用できます。
- MDN には、ユーザー エージェント文字列（「ブラウザ スニッフィング」）（主な機能検出）への依存を避けるための適切な方法が説明されています。
- なんらかの形でユーザー エージェント文字列に依存している場合は（有用であり続けるいくつかのコア値を使用している場合でも）、新しいブラウザ リリースに含まれる今後のユーザー エージェントでテストすることをおすすめします。ベータ版ビルドやテクノロジー プレビュー ビルドによって、今後リリースされるブラウザ バージョン自体でテストすることもできますが、テスト用のカスタム ユーザー エージェント文字列を設定することもできます。ローカルで開発する際に Chrome、Edge、Firefox、Safari では、ユーザー エージェント文字列をオーバーライドして、ユーザーから受け取る可能性のあるさまざまなユーザー エージェント値をコードがどのように処理するかをチェックできます。
Client Hints
この情報を提供するための主要な提案の 1 つに User-Agent Client Hints がありますが、これはすべてのブラウザでサポートされているわけではありません。対応ブラウザは、ブラウザのブランドとバージョン番号を示す Sec-CH-UA、モバイル デバイスからリクエストが送信されたかどうかを示す Sec-CH-UA-Mobile、オペレーティング システムの名前を示す Sec-CH-UA-Platform の 3 つのヘッダーを渡します。（これらのヘッダーは単純な文字列ではなく構造化ヘッダーであるため、解析が思ったよりも難しくなります。これは、ブラウザが「厄介な」値を送信することで強制され、適切に解析されなければ正しく処理されません。これは、前述のように、ブラウザが事前に行う「ファズテスト」の例です。このデータを使用するデベロッパーは、不適切または遅延解析によって不適切な結果（存在しないブランドや正しく閉じていない文字列が表示されるなど）をもたらすように設計されているため、データを適切に処理する必要があります）。幸いなことに、このデータは、ブラウザから navigator.userAgentData として直接 JavaScript に提供されます。サポートするブラウザでは、このオブジェクトのようになります。
{
"brands": [
{
"brand": " Not A;Brand",
"version": "99"
},
{
"brand": "Chromium",
"version": "96"
},
{
"brand": "Google Chrome",
"version": "96"
}
],
"mobile": false
}