HTTP クライアントヒント

この文書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表示される場合に限り、BCP 14 [RFC2119] および RFC8174 の説明に従って解釈されます。

本書では、拡張バッカス・ノアンフォーム (ABNF) 表記を [RFC5234] に従って使用します。

ユーザエージェントはデフォルト設定、ユーザ設定、およびAccept-CHで表現されたサーバの好みに基づいて、リクエストで送信するクライアントヒントを選択します。ユーザエージェントとサーバは以下に示すオプトインメカニズムを使用して、効率的なコンテンツ適応のために送信する必要があるヘッダフィールドを交渉でき、オプションで（例えば [CLIENT-HINTS-INFRASTRUCTURE] に概説されたような）追加のメカニズムを使用して、同じヘッダフィールドへの第三者のアクセスを制御する委任ポリシーを交渉することができます。ユーザエージェントは、低エントロピーと見なされないヒントを送信する場合にはオプトインを必要とすることをSHOULDです。低エントロピーヒントの例は [CLIENT-HINTS-INFRASTRUCTURE] の低エントロピーヒント表を参照してください。

実装者はクライアントヒントのサポートを実装する際のフィンガープリンティングの影響を認識し、本書のセキュリティに関する考慮事項（セクション 4）に記載された考慮点に従う必要があります。

1つ以上のクライアントヒントヘッダフィールドを含むリクエストを受け取った場合、サーバはそれらの情報に基づいて応答を最適化できます。その際、かつリソースがキャッシュ可能である場合、サーバは選択した応答に影響を与えるヒントと後続のリクエストに対してその応答が適切であるかどうかを示すために、Vary レスポンスヘッダフィールド（RFC7231 セクション 7.1.4）を生成するMUSTあります。

サーバは理解していないまたはサポートしていないヒントを無視するMUSTです。無視されたヒントをユーザエージェントに示すメカニズムはありません。

さらに、サーバはクライアント処理を助ける関連値を伝える追加のレスポンスヘッダフィールド（使用されるヒントによって指定されるもの）を生成することができます。

Accept-CH レスポンスヘッダフィールドは、その値に示されたヒントに対するサーバのサポートを示します。ユーザエージェント情報をクライアントヒント経由で受け取りたいサーバは、できるだけ早い段階でレスポンスに Accept-CH レスポンスヘッダを追加することをSHOULDです。

  Accept-CH = sf-list

Accept-CH: Sec-CH-Example, Sec-CH-Example-2

ユーザエージェントが Accept-CH を含む HTTP レスポンスを受け取ると、それはオリジンが後続の同一オリジンリクエストに対して示されたリクエストヘッダフィールドを受け取ることにオプトインしたことを示します。オプトインは安全でないトランスポート（HTTPS とは異なるスキームを使用する）で配信された場合は無視されるMUSTです。オプトインは持続されオリジンに結び付けられることがSHOULDであり、ユーザエージェントの定義するユーザのセッション期間中にサーバのオリジンへの後続リクエストでクライアントヒントの配信を可能にします。あるオプトインは以前に持続されたオプトイン値を上書きし、その代わりに持続されることがSHOULDです。

上記の Accept-CH の例は、ユーザエージェントが "https://site.example" へのナビゲーションに対する応答として受け取り、安全なトランスポートで配信された場合、持続された Accept-CH の設定は "https://site.example" に結び付けられます。例えば "https://site.example/foobar.html" へのナビゲーションにはその後使用されますが、例えば "https://foobar.site.example/" には使用されません。同様に、ナビゲーションの応答から構築されたページによって開始される任意の同一オリジンのリソースリクエスト（例："https://site.example/image.jpg"）にはその設定を使用しますが、クロスオリジンのリソースリクエスト（例："https://thirdparty.example/resource.js"）には使用しません。この設定は "https://other.example/" へのナビゲーションなど、他のオリジンから開始された "https://site.example" へのリソースリクエストには拡張されません。

1つ以上のクライアントヒントに基づいて応答を選択する場合、かつリソースがキャッシュ可能である場合、サーバはキャッシュキーにどのヒントが影響するかおよび選択された応答が後のリクエストに対して適切かどうかを示すために Vary レスポンスヘッダフィールドを生成する必要があります。

Vary: Sec-CH-Example

上の例はキャッシュキーに Sec-CH-Example ヘッダフィールドを含める必要があることを示します。

Vary: Sec-CH-Example, Sec-CH-Example-2

上の例はキャッシュキーに Sec-CH-Example および Sec-CH-Example-2 ヘッダフィールドを含める必要があることを示します。

本書に依存する機能で使用されるリクエストヘッダフィールドは、プライバシーを考慮したプロアクティブなコンテンツネゴシエーションを可能にし、受動的なフィンガープリンティングベクトルの露出を避けるためにユーザの環境に関する情報を公開します。しかし、実装者は、最悪の場合においては、管理されていない監視されない能動的フィンガープリンティングが受動的なフィンガープリンティングより優れているとは限らないことを念頭に置く必要があります。ユーザのプライバシーの利益を提供するためには、ユーザエージェントはクライアントヒントを使用する機能によって露出される情報の悪用を防ぐさらなるポリシーを適用する必要があります。

これらの機能が露出する情報はユーザについて新たな情報を明らかにする可能性があり、実装者は以下の考慮事項、推奨、およびベストプラクティスを検討すべきです。

基本的な前提は、リクエストヘッダとしてユーザについての情報を露出することは（セキュリティの観点から）他の手段で情報を露出することと同等であるということです。（例えば、オリジンが JavaScript API を使用してその情報にアクセスし、自身のサーバに送信できる場合など。）

クライアントヒントは明示的なオプトインメカニズムであるため、ユーザの環境に関する情報にアクセスしたいサーバはそれを積極的に要求する必要があり、クライアントやプライバシー研究者がどのオリジンがそのデータを収集しているかを追跡し、必要に応じて対応できるようになります。ヘッダに基づくオプトインにより受動的なフィンガープリンティングベクトルの削除が可能になります。例として、ユーザエージェントは User-Agent 文字列によって露出する情報を削減し、User-Agent Client Hints [UA-CH] を通じてその情報への能動的アクセスを可能にすることができます。あるいは、ユーザエージェントはスクリプトを通じて既に利用可能な情報（例：Save-Data クライアントヒント <https://wicg.github.io/savedata/#save-data-request-header-field>）を公開することで、受動的フィンガープリンティングの表面を増やすことなく同等の情報を提供することができます。クライアントヒント機能をサポートし、ある情報をオプトインしたサーバに送信するユーザエージェントは、同等の情報を受動的に送信することを避けるべきです。

したがって、本書に依拠してクライアントヒントヘッダを定義する機能は、既にユーザエージェントによってアプリケーションに提供されている情報（既存のリクエストヘッダ、HTML、CSS、または JavaScript など）でない新しい情報を提供してはならないMUST NOTです。

エントロピー：

非常に詳細なデータを露出すると、異なるオリジンへの複数のリクエスト間でユーザを識別するのに利用され得ます。ヘッダフィールド値の表現できる範囲を減らすか、現在の値の正確な表現ではなく近似となる列挙された範囲に制限することで、プライバシーを改善しリンク可能性のリスクを低減できます。

機微性（センシティビティ）：

機能はユーザの機微な情報を露出してはSHOULD NOTなりません。そのため、アプリケーションが利用できるが特定のユーザ操作（例えば許可プロンプトやユーザのアクティベーション）により制限されている情報は、クライアントヒントとして露出してはSHOULD NOTです。

時間による変化：

機能は、状態変化自体が（例：JavaScript のコールバックを通じて）露出されない限り、時間とともに変化するユーザ情報を露出してはSHOULD NOTです。

異なる機能は低エントロピー、非機微、静的な情報（例：ユーザエージェント情報）と高エントロピー、機微、動的な情報（例：位置情報）の間の空間の異なる点に位置します。ユーザエージェントは特定の機能によって提供される価値とこれらの考慮事項とのトレードオフを検討し、機能ごとやその他の細かい基準で異なるポリシーを持つことを望むかもしれません。

• 実装者は、一部またはすべてのクライアントヒントヘッダフィールドの配信をオプトインオリジンのみに制限することをSHOULD検討すべきであり、オプトインオリジンが明示的に別のオリジンにクライアントヒントヘッダフィールドの要求を委任する許可を与えていない限りは除きます。
• プライバシー上の懸念と帯域幅制限の間のバランスをユーザに許可する選択メカニズムを提供することを検討する実装者は、受動的フィンガープリンティングのリスクのようなプライバシー影響をユーザに説明することが困難または事実上不可能である可能性があることも考慮する必要があります。
• 特定のユースケースや脅威モデルに特化した実装は、クライアントヒントヘッダフィールドの一部またはすべての送信を回避してもよい（MAY）。例えば、リンク可能性のリスクが高いヘッダフィールドの送信を回避するなどです。

ユーザエージェントはサイトデータ、閲覧キャッシュ、クッキー、またはそれに類するものがクリアされたときに保持されたオプトイン設定をクリアすることがMUSTです。

• 既存のヘッダフィールド名の使用による潜在的な衝突
• ヘッダフィールド値で伝達されるデータの特性

新しいクライアントヒントの作成者は、それらがクライアント側コンテンツ（例：スクリプト）によって追加可能である必要があるか、それともクライアントヒントがユーザエージェントによって独占的に設定される必要があるかを慎重に検討することが勧められます。後者の場合、ヘッダフィールド名の "Sec-" プレフィックスはスクリプトや他のアプリケーションコンテンツがユーザエージェント内でそれらを設定することを防ぐ効果があります。"Sec-" プレフィックスを使用することは、ユーザエージェント（アプリケーションコンテンツではなく）が値を生成したことをサーバに示します。詳細は [FETCH] を参照してください。

慣例として、クライアントヒントであるリクエストヘッダは CH- プレフィックスを使用することが推奨されており、これにより CH-Foo のようにフレームワークを使用していることを識別しやすくなります。"Sec-" プレフィックスと組み合わせると Sec-CH-Foo のようになります。これによりプログラム的に識別しやすくなり（例えばプライバシーフィルタが認識しないヒントをリクエストから削除する場合など）、扱いやすくなります。

Accept-CH オプトインメカニズムを使用して交渉されたクライアントヒントのリクエストヘッダは、フィールド名が sf-token に一致するMUSTです。

能動的フィンガープリンティング情報へのアクセスを追跡するユーザエージェントは、クライアントヒントヘッダの発行を同等の API へのアクセスと同様に考慮することをSHOULD検討すべきです。

クライアントヒントの悪用に関する研究は、クライアントヒントを含むリクエストに対する HTTP レスポンスが異なる値を持つものや値を持たないものとどのように異なるかを調べることが考えられます。これにより、どのクライアントヒントが使用されているかを明らかにし、その使用をさらに分析することができます。

ヘッダフィールド名:

Accept-CH

適用プロトコル:

HTTP

ステータス:

experimental

著者/変更管理者:

IETF

仕様文書:

本 RFC のセクション 3.1

関連情報:

クライアントヒントに関するもの