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