draft-ietf-httpbis-client-hints-09.txt   draft-ietf-httpbis-client-hints-10.txt 
HTTP Working Group I. Grigorik HTTP Working Group I. Grigorik
Internet-Draft Y. Weiss Internet-Draft Y. Weiss
Intended status: Experimental Google Intended status: Experimental Google
Expires: August 21, 2020 February 18, 2020 Expires: August 21, 2020 February 18, 2020
HTTP Client Hints HTTP Client Hints
draft-ietf-httpbis-client-hints-09 draft-ietf-httpbis-client-hints-10
Abstract Abstract
HTTP defines proactive content negotiation to allow servers to select HTTP defines proactive content negotiation to allow servers to select
the appropriate response for a given request, based upon the user the appropriate response for a given request, based upon the user
agent's characteristics, as expressed in request headers. In agent's characteristics, as expressed in request headers. In
practice, clients are often unwilling to send those request headers, practice, clients are often unwilling to send those request headers,
because it is not clear whether they will be used, and sending them because it is not clear whether they will be used, and sending them
impacts both performance and privacy. impacts both performance and privacy.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Client Hint Request Header Fields . . . . . . . . . . . . . . 4 2. Client Hint Request Header Fields . . . . . . . . . . . . . . 4
2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4 2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4
2.2. Server Processing of Client Hints . . . . . . . . . . . . 5 2.2. Server Processing of Client Hints . . . . . . . . . . . . 5
3. Advertising Server Support . . . . . . . . . . . . . . . . . 5 3. Advertising Server Support . . . . . . . . . . . . . . . . . 5
3.1. The Accept-CH Response Header Field . . . . . . . . . . . 5 3.1. The Accept-CH Response Header Field . . . . . . . . . . . 5
3.1.1. Interaction with Caches . . . . . . . . . . . . . . . 6 3.1.1. Interaction with Caches . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.1. Information Exposure . . . . . . . . . . . . . . . . . . 6 4.1. Information Exposure . . . . . . . . . . . . . . . . . . 6
5. Cost of Sending Hints . . . . . . . . . . . . . . . . . . . . 8 4.2. Deployment and Security Risks . . . . . . . . . . . . . . 8
5.1. Deployment and Security Risks . . . . . . . . . . . . . . 8 4.3. Abuse Detection . . . . . . . . . . . . . . . . . . . . . 8
5.2. Abuse Detection . . . . . . . . . . . . . . . . . . . . . 9 5. Cost of Sending Hints . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Interaction with Variants Response Header Field . . 11 Appendix A. Interaction with Variants Response Header Field . . 11
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 11
B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.5. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.5. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.6. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 11 B.6. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 11
B.7. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 12 B.7. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 12
B.8. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 12 B.8. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 12
B.9. Since -08 . . . . . . . . . . . . . . . . . . . . . . . . 12 B.9. Since -08 . . . . . . . . . . . . . . . . . . . . . . . . 12
B.10. Since -09 . . . . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
There are thousands of different devices accessing the web, each with There are thousands of different devices accessing the web, each with
different device capabilities and preference information. These different device capabilities and preference information. These
device capabilities include hardware and software characteristics, as device capabilities include hardware and software characteristics, as
well as dynamic user and client preferences. Applications that want well as dynamic user and client preferences. Applications that want
to allow the server to optimize content delivery and user experience to allow the server to optimize content delivery and user experience
skipping to change at page 8, line 15 skipping to change at page 8, line 15
challenging. challenging.
o Implementations specific to certain use cases or threat models MAY o Implementations specific to certain use cases or threat models MAY
avoid transmitting some or all of Client Hints header fields. For avoid transmitting some or all of Client Hints header fields. For
example, avoid transmission of header fields that can carry higher example, avoid transmission of header fields that can carry higher
risks of linkability. risks of linkability.
Implementers SHOULD support Client Hints opt-in mechanisms and MUST Implementers SHOULD support Client Hints opt-in mechanisms and MUST
clear persisted opt-in preferences when any one of site data, clear persisted opt-in preferences when any one of site data,
browsing history, browsing cache, cookies, or similar, are cleared. browsing history, browsing cache, cookies, or similar, are cleared.
5. Cost of Sending Hints 4.2. Deployment and Security Risks
While HTTP header compression schemes reduce the cost of adding HTTP
header fields, sending Client Hints to the server incurs an increase
in request byte size. Servers SHOULD take that into account when
opting in to receive Client Hints, and SHOULD NOT opt-in to receive
hints unless they are to be used for content adaptation purposes.
Due to request byte size increase, features relying on this document
to define Client Hints MAY consider restricting sending those hints
to certain request destinations [FETCH], where they are more likely
to be useful.
5.1. Deployment and Security Risks
Deployment of new request headers requires several considerations: Deployment of new request headers requires several considerations:
o Potential conflicts due to existing use of field name o Potential conflicts due to existing use of field name
o Properties of the data communicated in field value o Properties of the data communicated in field value
Authors of new Client Hints are advised to carefully consider whether Authors of new Client Hints are advised to carefully consider whether
they should be able to be added by client-side content (e.g., they should be able to be added by client-side content (e.g.,
scripts), or whether they should be exclusively set by the user scripts), or whether they should be exclusively set by the user
agent. In the latter case, the Sec- prefix on the header field name agent. In the latter case, the Sec- prefix on the header field name
skipping to change at page 9, line 5 skipping to change at page 8, line 37
from setting them in user agents. Using the "Sec-" prefix signals to from setting them in user agents. Using the "Sec-" prefix signals to
servers that the user agent - and not application content - generated servers that the user agent - and not application content - generated
the values. See [FETCH] for more information. the values. See [FETCH] for more information.
By convention, request headers that are client hints are encouraged By convention, request headers that are client hints are encouraged
to use a CH- prefix, to make them easier to identify as using this to use a CH- prefix, to make them easier to identify as using this
framework; for example, CH-Foo or, with a "Sec-" prefix, Sec-CH-Foo. framework; for example, CH-Foo or, with a "Sec-" prefix, Sec-CH-Foo.
Doing so makes them easier to identify programmatically (e.g., for Doing so makes them easier to identify programmatically (e.g., for
stripping unrecognised hints from requests by privacy filters). stripping unrecognised hints from requests by privacy filters).
5.2. Abuse Detection 4.3. Abuse Detection
A user agent that tracks access to active fingerprinting information A user agent that tracks access to active fingerprinting information
SHOULD consider emission of Client Hints headers similarly to the way SHOULD consider emission of Client Hints headers similarly to the way
it would consider access to the equivalent API. it would consider access to the equivalent API.
Research into abuse of Client Hints might look at how HTTP responses Research into abuse of Client Hints might look at how HTTP responses
that contain Client Hints differ from those with different values, that contain Client Hints differ from those with different values,
and from those without. This might be used to reveal which Client and from those without. This might be used to reveal which Client
Hints are in use, allowing researchers to further analyze that use. Hints are in use, allowing researchers to further analyze that use.
5. Cost of Sending Hints
While HTTP header compression schemes reduce the cost of adding HTTP
header fields, sending Client Hints to the server incurs an increase
in request byte size. Servers SHOULD take that into account when
opting in to receive Client Hints, and SHOULD NOT opt-in to receive
hints unless they are to be used for content adaptation purposes.
Due to request byte size increase, features relying on this document
to define Client Hints MAY consider restricting sending those hints
to certain request destinations [FETCH], where they are more likely
to be useful.
6. IANA Considerations 6. IANA Considerations
This document defines the "Accept-CH" HTTP response field, and This document defines the "Accept-CH" HTTP response field, and
registers it in the Permanent Message Header Fields registry. registers it in the Permanent Message Header Fields registry.
6.1. Accept-CH 6.1. Accept-CH
o Header field name: Accept-CH o Header field name: Accept-CH
o Applicable protocol: HTTP o Applicable protocol: HTTP
o Status: standard o Status: standard
skipping to change at page 12, line 25 skipping to change at page 12, line 25
o Issue 730: Replaced Key reference with Variants. o Issue 730: Replaced Key reference with Variants.
o Issue 700: Replaced ABNF with structured headers. o Issue 700: Replaced ABNF with structured headers.
o PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 o PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105
B.9. Since -08 B.9. Since -08
o PR 985: Describe the bytesize cost of hints. o PR 985: Describe the bytesize cost of hints.
o PR 776: Add Sec- and CH- prefix considerations. o PR 776: Add Sec- and CH- prefix considerations.
o PR 1001: Clear CH persistence when cookies are cleared. o PR 1001: Clear CH persistence when cookies are cleared.
B.10. Since -09
o PR 1064: Fix merge issues with "cost of sending hints".
Acknowledgements Acknowledgements
Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Ben Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Ben
Greenstein, Tarun Bansal, Roy Fielding, Vasiliy Faronov, Ted Hardie, Greenstein, Tarun Bansal, Roy Fielding, Vasiliy Faronov, Ted Hardie,
Jonas Sicking, Martin Thomson, and numerous other members of the IETF Jonas Sicking, Martin Thomson, and numerous other members of the IETF
HTTP Working Group for invaluable help and feedback. HTTP Working Group for invaluable help and feedback.
Authors' Addresses Authors' Addresses
Ilya Grigorik Ilya Grigorik
 End of changes. 7 change blocks. 
19 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/