クライアントのヒント

良い記事ですね。詳しくはこちらをクリックしてください。

クライアントのヒント
国際標準
開発者GoogleW3C
Webサイトhttps://wicg.github.io/ua-client-hints/

クライアントヒントはHTTPプロトコルの拡張機能であり、サーバーがクライアント(通常はウェブブラウザ)にその設定に関する情報を問い合わせることを可能にします。これにより、サーバーはクライアントへの応答を調整することができます。例えば、クライアントが画面が非常に小さいことを通知した場合、サーバーはより小さな画像を送信することができます。クライアントは、HTTPヘッダーフィールドと呼ばれるHTTPプロトコルの特定の部分を使用してデータを送信するか、ウェブページで実行される JavaScriptコードに同じ情報を公開することで、要求された情報を通知することで、この要求に応答することができます。

クライアントヒントは、2013 年にGoogle のエンジニアによって提案され、ユーザーエージェント ヘッダーに代わるプライバシー重視の方法として設計されました。これは、Google のプライバシー サンドボックスという取り組みの一環として行われました。ユーザーエージェント ヘッダーは、クライアントがサーバーに対して自身を識別するために送信するコード スニペットです。当初は統計目的のために意図されていましたが、これらのヘッダーはウェブサイト間でユーザーを追跡するためのツールになりつつありました。クライアントヒントは、同じ情報を共有するためのより制御された方法を提供することで、この問題に対処することを目的としていました。プライバシーに重点を置いているにもかかわらず、クライアントヒントの初期の設計は他のブラウザから批判に直面しました。提起された主な懸念の 1 つは、プロトコルによってサードパーティ ドメインによる新しい形式の追跡が可能になる可能性があるということでした。サードパーティ ドメインとは、画像やスクリプト ファイルなどのリソースを読み込む、ウェブサイトが所有していないウェブサーバーのことです。これらの懸念にもかかわらず、Chrome は 2020 年 8 月にクライアントヒントのサポートを実装しました

プライバシー研究者たちは、クライアントヒントが主にユーザーを追跡するJavaScriptコードによって使用されているのではないかと懸念を表明しています。2023年にルーヴェン・カトリック大学ラドバウド大学が行った研究では、インターネット上の上位10万のウェブサイトを調査したところ、クライアントヒントへのアクセスの大部分は、追跡や広告目的で使用されるJavaScriptコードから来ていることが明らかになりました。

背景

1992年、 HTTPプロトコルの拡張機能が導入され、クライアントからサーバーに送信されるUser-AgentHTTPヘッダーが追加されました。このヘッダーには、クライアントの名前とバージョンを識別する単純な文字列が含まれていました。このヘッダーは、統計目的とプロトコルに違反したクライアントの追跡のみを目的としていました。その後、User-Agentヘッダーはますます複雑になり、ユーザーを一意に識別できる重要な情報が含まれるようになりました。多くの場合、この情報はブラウザフィンガープリンティングに使用され、サイトはユーザーにJavaScriptをロードすることなく、サイト間で受動的にユーザーを追跡できます。[ 1 ]

歴史

クライアントヒント仕様の最初の草案は、2013年にGoogleのエンジニアによって提案されました。この仕様は、 2015年11月にインターネット技術タスクフォース(IETF)の草案となりました。2021年に、この仕様は実験的なコメント要求(RFC)の状態にアップグレードされました。[ 2 ]この指定は、IETFがクライアントヒント仕様をインターネット標準として受け入れたが、未解決の問題がまだ残っているか、インターネットでまだ広く採用されていないことを示しています。[ 3 ]同じ頃、WebブラウザがWeb上でHTTPクライアントヒントを処理する方法に関する仕様が、W3Cコミュニティグループレポートの草案として公開されました。[ 2 ]

2020年、Googleはブラウザによるユーザーエージェント(UA)宣言を廃止する意向を発表した。 [ 4 ]この廃止は、プライバシーサンドボックスと呼ばれる、ウェブサイトがプライバシーを侵害することなくユーザー情報にアクセスできるようにウェブに変更を加えるという、Googleによるより広範な取り組みの一環であった。彼らは、同じ情報を共有するためのより制御された方法を可能にすることから、クライアントヒントをユーザーエージェントヘッダーのプライバシー保護の代替手段として挙げた。[ 5 ]しかし、最初のクライアントヒントの提案は、プライバシーの懸念から他のブラウザから反発を受けた。 2019年、Braveは最初の提案について懸念を表明し、インターネット上でユーザーを追跡するために使用できる方法を挙げた。[ 6 ] Firefoxを開発しているMozillaは、当初この提案を有害と分類し、Safariを開発しているAppleもこの提案に対して否定的な立場をとった。[ 7 ]こうした懸念にもかかわらず、Chromeは2020年8月にHTTPクライアントヒントのサポートを実装しました。UA文字列の廃止はCOVID-19パンデミックの影響で遅れましたが、このプロセスは2023年2月に完了しました。[ 8 ]

当初反対していたMozillaは、その後中立的な立場に転じ[ 7 ]、Braveはクライアントヒントの実装をChromeと同期させました[ 2 ] 。 2024年現在、ウェブユーザーの75%以上がクライアントヒントをサポートするブラウザを使用しています[ 2 ] 。

機構

クライアントヒントプロトコルは、ユーザーエージェント(UA)(通常はブラウザ)とサーバーという2つのエンティティを定義します。これら2つのエンティティは相互に通信して、ユーザーに提供するコンテンツの種類をネゴシエートします。[ 9 ]Accept-CHこのプロセスでは、サーバーがUAにHTTPヘッダーを含む応答を送信します。このヘッダーには、必要なクライアントヒントHTTPヘッダーのリストが含まれています。[ 2 ]その後、UAは、それらのヒントをサポートしている限り、後続の各応答で要求されたクライアントヒントを返すことが期待されます。サーバーはこれらのヘッダーを使用して、UAに提供するコンテンツの種類を決定します。[ 9 ] UAが特定のクライアントヒントを理解またはサポートしない場合は、UAにその特定のクライアントヒントを無視するように指示されます。特定のクライアントヒントをキャッシュできない場合は、サーバーはVaryUAに送信する別のヘッダーで該当するクライアントヒントヘッダーを指定する必要があります。これにより、キャッシュメカニズムは、応答が異なるクライアントヒント値に基づいて変化する可能性があることを理解するようになります。[ 9 ]ブラウザを具体的に識別するクライアントヒントについては、プロトコルのユーザーがブラウザ固有の特異な動作に依存することを防ぐために、追加のランダムなブラウザ識別子がグリースとして含まれています。 [ 10 ] [ 11 ]

JavaScript を許可する UA の場合、 navigator.userAgentDataJavaScript APIを通じて追加のオプションを利用できます。この API により、JavaScript はクライアントヒントヘッダーによって提供されるのと同じ情報を取得できます。[ 11 ] API は提供するデータを低エントロピーデータと高エントロピーデータの 2 種類に分けます。低エントロピーデータは、ブラウザが稼働しているプラ​​ットフォームやブラウザのブランドなど、多数のユーザー間で類似する可能性が高い情報に対応します。一方、高エントロピーデータは、ブラウザの正確なバージョン番号やユーザーのデバイスのモデルなどの詳細を含み、ユーザー間で大きく異なる場合があります。低エントロピーデータはオブジェクトパラメータとして API に含まれていますが、ユーザーを一意に識別できる高エントロピーデータは、ブラウザがユーザーのgetHighEntropyValues()許可を求めたり、追加のチェックを実行したりできるようにする API の関数を呼び出すことによって、クライアントが明示的に取得する必要があります。[ 12 ]

コンテンツ ネゴシエーション を開始するために、HTTP サーバーはAccept-CHHTTP 要求の応答にヘッダーを追加します。

HTTP / 1.1 200 OK ... Accept-CH: ビューポート幅 ... 

ユーザーエージェントがビューポート幅のクライアントヒントをサポートしている場合、ユーザーエージェントはViewport-Width後続のすべてのリクエストにヘッダーを追加します。

GET /ギャラリーHTTP / 1.1 ... ビューポート幅: 1920 ... 

サーバーはヘッダーの情報を用いてViewport-Width、クライアントに提供するコンテンツの種類を決定します。例えば、サーバーが非常に大きな画像を持っている場合、その画像がビューポートに収まらない場合は、より小さな画像を返すようにサーバーを設定できます。[ 13 ]

プライバシーに関する懸念

クライアントヒント提案が最初に公開されたとき、それは重大なプライバシーの懸念に直面しました。BraveやMozillaなどのブラウザベンダーは、提案の初期草案の特定の条項により、ウェブサイトがブラウザにクライアントヒントデータをサードパーティのドメインに提供するように指示できることを指摘しました。サードパーティのドメインとは、JavaScriptコードを実行せず、画像やスクリプトファイルなどのリソースを読み込むドメインです。[ 6 ]初期草案の条項では、コンテンツ配信ネットワーク(CDN)やクラウドサービスプロバイダーなどのサードパーティのドメインが許可されます。CDNは、ウェブサイトのコンテンツを地理的に分散したサーバー群のネットワーク全体に配信してウェブサイトの速度と信頼性を向上させます。CloudflareやGoogle Cloudなどのクラウドプロバイダーは、ウェブサイトやアプリケーションにデータストレージ、コンピューティング能力、インフラストラクチャなどのサービスを提供しています。これらのエンティティは、ブラウザにクライアントヒント情報を元のウェブサイトと一緒に自社のサーバーに送信するように指示することで、ウェブ上でユーザーを追跡できます。[ 6 ] [ 14 ]また、Client-Hint提案は許容度が高すぎて、HTTPヘッダーを読むだけでは得られないプライバシーを侵害する新たな情報がサーバーに漏洩することを明示的に許可しているという懸念も提起された。[ 14 ]さらに、 NoScript拡張機能のようなユーザーのプライバシー保護を目的とした拡張機能も、サイトがユーザーのプライバシーを侵害する情報を漏洩するのを防ぐのが著しく困難になるという理由で、この提案に反対した。[ 6 ]

クライアントヒントがGoogle ChromeMicrosoft Edgeなどの主要なブラウザに採用されて以来、プライバシー研究者は、実際のトラッキングへの利用について懸念を表明している。[ 15 ]ルーヴェン・カトリック大学とラドバウド大学の研究者による 2023 年の調査では、上位 10 万のウェブサイトのうち、ウェブページによって読み込まれる JavaScript ファイルの 60% がクライアントヒントのJavaScript API にアクセスしており、そのほとんどはトラッキングおよび広告スクリプトで、その多くはGoogleから提供されていたことが判明した。これらのスクリプトファイルの 90% 以上が、取得したデータを追跡ドメインに流出させていた。[ 16 ]ボン・ライン・ジーク応用科学大学の研究者による 2024 年 5 月のその後の調査では、インターネット上のウェブサイトにおけるクライアントヒントの全体的な採用率は低かったものの、トラッキングで知られるサードパーティのドメインのかなりの数が HTTP クライアントヒントのデータにアクセスしていたことが指摘されている。[ 17 ]

参照

参考文献

引用

出典