フィンガープリントとは、ユーザーがウェブサイトに戻ったときにユーザーを特定することや、複数のウェブサイトで同じユーザーを特定することを指します。 多くの特性は、設定と他者の設定とで異なる場合があります。たとえば、別の種類のデバイスを使用している場合 異なるブラウザ、異なる画面サイズ、異なるフォントがインストールされていることなどが挙げられます。フォントが「Dejavu Sans」の場合 そうしないと、どのウェブサイトでもそのフォントを確認することでユーザーと私の違いを見分けることができます。このように フィンガープリントは機能します。これらのデータポイントのコレクションを構築し、それぞれにユーザーを区別するための追加の方法を提供します。
より正式な定義は次のようになります。フィンガープリントとは、明白であって自明ではない長期的存続期間を さまざまな特性を考慮して、できるだけ多くのユーザーと区別しようとします。
フィンガープリントがユーザーのプライバシーを阻害する理由
ユーザーのフィンガープリントが重要なエッジケースとして、たとえば不正行為の検出があります。しかし フィンガープリントは サイトをまたいでユーザーをトラッキングするために使用されている。多くの場合、トラッキングはユーザーの同意なしに、または場合によってはベースとして行われる ユーザーに十分に通知していない無効な同意がある場合。そうすることで、ユーザーは多くの場合、 裏切られた気がします。
フィンガープリントとは、ユーザーを密かに区別する方法を見つけることです。フィンガープリントを使用すると、 同じウェブサイトの同じユーザーとして認識されたり、2 つの異なるブラウザ プロファイルで同じユーザーが同時に認識されたりすることがあります。 つまり、フィンガープリントを使用すると、サイトをまたいでユーザーをトラッキングできます。決定論的で明白なトラッキング手法では 保存される Cookie の保存などの処理は、ユーザーによってある程度監視され、制御される （前のモジュールでは、そうしたアプローチのいくつかを説明しました）。しかし、フィンガープリントは、 秘密であるから。不変の特性に基づいており、たいていは目に見えない形で発生します。これが 「fingerprinting」を使用します。デジタル版か端部の指紋かにかかわらず、指紋の変更はせいぜい難しい 指で操作します。
ブラウザ ベンダーはユーザーがトラッキングを好まないということを認識しており、フィンガープリントを制限する機能を継続的に実装しています。 （その一部は前のモジュールで確認しました）。ここでは、これらの機能がビジネスに与える影響について見ていきます 引き続きプライバシーを保護する方法で行いたい処理を行う方法を学びます。これは、ブラウザ保護の仕組みと フィンガープリントの使用を止める方法ではなく、実行する内容と方法に影響します。
実際には、ほとんどのデベロッパーとほとんどの企業は、ユーザーのフィンガープリントを使用する必要はありません。アプリでユーザーにログインを要求する場合は、 この場合、ユーザーは同意を得たうえで、一方的にオプトアウトできる方法で、ニュース メディアに対して いつでも利用できます。これは、どのユーザーがログインしているかを把握するためのプライバシー保護の方法です。アプリが ユーザーにログインを要求することで、ユーザーのプライバシー保護を強化できます。プライバシー（セキュリティ、コンプライアンス、 必要なデータだけに拡張できます）。
すべきこと
フィンガープリントについてサードパーティを評価します。thirdparty モジュールの一部として、 対象のサードパーティ サービスと、それらが行うウェブ リクエストのリストがすでに存在する可能性があります。場合によっては を使ってリクエストを検査し、送信元に返されているデータ（ある場合）を確認します。しかし、これはしばしば困難です。 フィンガープリントは、その性質上、ユーザーの承認を必要としないデータのリクエストを伴う秘密のプロセスです。
サードパーティ サービスや依存関係のプライバシー ポリシーも参照して、フィンガープリントに該当するかどうかを探すことも重要です。 あります。「確率的マッチング」と呼ばれることや、確率的マッチング手法の一部と言われることもあります。 「決定論的マッチング」とは異なります
フィンガープリントの仕組み
多くの場合、これらすべての属性の個人的な組み合わせは、あなた、または 少なくとも類似の人々のグループに対してのみです。密かに追跡するために使用できます。
補足: パッシブ フィンガープリントとアクティブ フィンガープリント
ここでは、パッシブなフィンガープリント技術と能動的なフィンガープリント技術を明確に区別する必要があります。パッシブなフィンガープリント デフォルトで Web サイトに渡される情報を使用する手法です。アクティブ フィンガープリント手法は、 ブラウザに対して明示的に追加情報を求めます。この区別が重要な理由は、ブラウザが アクティブな手法の検知と傍受、または軽減を試みることができます。API を制限したり、ダイアログの背後でゲートウェイ化したりできる ユーザーに許可を求める（そのため、それらが使用されていることをユーザーに警告する、またはユーザーが拒否することを許可する） 。受動的な手法は、すでに Web サイトに提供されたデータを使用する手法です。これは多くの場合、歴史的に 情報スーパーハイウェイの初期段階において、その情報はすべてのサイトに提供されました。user-agent 文字列は、 後ほど詳しく説明します。大量の情報を提供するために役立つと考えられていました。 ユーザーのブラウザ、バージョン、オペレーティング システムに関する情報。 基づいて処理します。ただし、これにより、利用可能な識別情報の量、情報、 ユーザーを区別するのに役立ちますこのような情報は次第に利用できなくなったり 識別されなくなるからです自分の作業がこの情報に依存しているのであれば、たとえば 依存する場合、ブラウザが情報を停止または停止することが多くなると、このコードは機能しなくなる可能性があります。 ここでは、テストが最善の防御策です（後述）。
参考: 指紋認証可能性の測定
これらの各データポイントが提供する情報量を表す技術的尺度はエントロピーと呼ばれ、ビット単位で測定されます。 多数の異なる値（インストールされているフォントのリストなど）がある機能は、多くのビットに影響する可能性があります。 つまり、大きな違い（使用しているオペレーティング システムなど）がないものが、 いくつかあります。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 データにもこのアプローチを採用できます。一例として
ページ パフォーマンスの測定に使用する非常に正確なタイミング API
window.performance.now() から。ブラウザはこれらの値を認識します
ただし、返される値の精度は意図的に 20 マイクロ秒の単位で切り上げ
フィンガープリントでの使用を避ける必要があります（さらに、タイミング攻撃を回避するためのセキュリティのためにも）。ここでの目標は、
API の有用性を維持する一方で、識別性を意図的に排除する、つまり「集団免疫」を提供することを作成することにより、
自分に特有なものではなく、他の人のデバイスのように見えるようにできます。Safari のシステム構成が簡素化されている
まさにそのためです
プライバシー バジェットの執行
プライバシー バジェットは、各フィンガープリント サーフェスで明らかになった情報をブラウザが推定することを提案する提案です。 ブラウザには実装されていません。ユーザーのプライバシーを保護しながら、強力な API を使用できるようにすることが目標です。詳しくは、プライバシー バジェットの提案をご覧ください。
広範なテスト環境を使用する
これらすべてが、アプリやサービスの構築方法に影響します。特に、多様な回答やアプローチがある この分野のブラウザやプラットフォームをまたいでつまり、複数の異なる環境で作業をテストすることが重要です。 もちろん、これは常に重要ですが、HTML レンダリングまたは CSS が特定の環境では一定であると考えるのが妥当です。 使用するブラウザやプラットフォームに関係なく、特定のレンダリング エンジンを使用できます。そのため、 （まばたきベースのブラウザなど）。厳密に言えば、これは API の使用については重要ではありません。同じブラウザを共有するブラウザであるため、 フィンガープリントに対して API サーフェスを強化する方法が大きく異なる場合があります。
すべきこと
- 自社の分析結果とユーザー層を確認し、テストで優先すべきブラウザ群を見極めます。
- テストにおすすめのブラウザは、Firefox、Chrome、Edge、パソコンの Safari、Android の Chrome、Samsung Internet です。 iOS では Safariこれにより、3 つの主要なレンダリング エンジン（Firefox の Gecko、Blink のさまざまなフォーク）でテストを実施できます。 Chrome、Edge、Samsung Internet、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 ユーザー エージェント ヘッダー。ほぼ以前から、ユーザーはウェブ デベロッパーに対して 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 が提供するデータを変更するもう一つの例です。 空のユーザーエージェントヘッダーを送信すると、その存在を前提とする無数の Web サイトが破損します。一般的にブラウザが何をしているか そこから詳細を一部削除して その後ほとんど変更しないということです（これについては、 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を探します。そのようなコードには、 確認します。 - 独自のコードで用途が見つかった場合は、そのコードが何をチェックしているかを調べ、その区別を行うための別の方法を見つける （または、代わりの依存関係を見つけるか、問題を報告するか、更新を確認して、依存関係をアップストリームで操作します）。ときどきある バグを回避するためにはブラウザの差別化は欠かせませんが、ユーザー エージェントが凍結されてしまうと、それをやり方ではなくなってしまうでしょう。
- 無事かもしれない。ブランド、メジャー バージョン、プラットフォームというコアバリューだけを使用しているならば、これらは変わらないでしょう。 user-agent 文字列が正確に入力されていること。
- MDN では、ユーザー エージェント文字列（「ブラウザ スニッフィング」）への依存を回避するための優れた方法が示されています。 主な処理は特徴検出です
- なんらかの形でユーザー エージェント文字列に依存している場合（有用なコアバリューをいくつか使用している場合でも）、それは 新しいブラウザ リリースで提供されるユーザー エージェントでテストすることをおすすめします。今後リリースされるブラウザでテストすることは可能 使用できますが、カスタム ユーザー エージェント文字列を 説明します。ユーザー エージェント文字列は、Chrome、Edge、 Firefox、 Safari、 ローカル開発を行う際に、ユーザーから受け取る可能性のあるさまざまなユーザー エージェント値をコードがどのように処理しているかをチェックできます。
Client Hints API
この情報を提供するための主要な提案の 1 つに、User-Agent Client Hints があります。
一部のブラウザでは対応していません。サポートするブラウザでは、Sec-CH-UA という 3 つのヘッダーが渡されます。これにより、
ブラウザのブランドとバージョン番号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
}