idnits 2.17.1 draft-west-lang-client-hint-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2018) is 1975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-client-hints-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-httpbis-client-hints (ref. 'I-D.ietf-httpbis-client-hints') == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-08 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. West 3 Internet-Draft Google 4 Intended status: Standards Track November 29, 2018 5 Expires: June 2, 2019 7 The 'Lang' Client Hint 8 draft-west-lang-client-hint-00 10 Abstract 12 This document defines a Client Hint that aims to allow developers to 13 opt-in to the ability to perform content negotiation based on the set 14 of natural languages preferred by the user agent. This new mechanism 15 is intended to improve upon the privacy properties of the "Accept- 16 Language" header, and eventually to supplant it entirely. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 2, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 2. The 'Lang' Client Hint . . . . . . . . . . . . . . . . . . . 3 56 2.1. The 'Sec-CH-Lang' Header Field . . . . . . . . . . . . . 3 57 2.2. Integration with Fetch . . . . . . . . . . . . . . . . . 4 58 3. Security and Privacy Considerations . . . . . . . . . . . . . 4 59 3.1. Secure Transport . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Access Restrictions . . . . . . . . . . . . . . . . . . . 5 62 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 63 4.1. The 'Accept-Language' Header . . . . . . . . . . . . . . 5 64 4.2. The 'Sec-CH-' prefix . . . . . . . . . . . . . . . . . . 6 65 4.3. What about weight? . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. 'Sec-CH-Lang' Header Field . . . . . . . . . . . . . . . 6 68 5.2. 'Accept-Language' Header Field . . . . . . . . . . . . . 7 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 8 71 A.1. draft-west-ua-client-hints-00 . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Today, user agents generally specify a set of preferred languages as 77 part of each HTTP request by sending the "Accept-Languages" header 78 along with each request (defined in Section 5.3.5 of [RFC7231]). 79 This header aims to give servers the opportunity to serve users the 80 best content available in a language they understand. For example, 81 my browser currently sends the following header: 83 Accept-Language: en-US, en;q=0.9, de;q=0.8 85 This tells the server something along the lines of "This user prefers 86 American English, but will accept any English at all. If no English- 87 languge content is available, try German!". If the server has 88 English-language content, it might redirect the user agent to that 89 preferred content. If not, it might try German. 91 In the best case, this kind of content negotiation sincerely improves 92 the user experience, giving them legible content they enjoy reading. 93 This comes with a cost, however, as language preferences are fairly 94 unique, and end up exposing quite a bit of entropy to the web. 96 This document proposes a mechanism that might allow user agents to 97 reduce the passive fingerprinting surface exposed by the "Accept- 98 Language" header by replacing it with a new "Sec-CH-Lang" Client Hint 99 ([I-D.ietf-httpbis-client-hints]) that servers can opt-into 100 receiving. Rather than broadcasting this information to everyone on 101 the network, all the time, user agents can make reasonable decisions 102 about how to respond to given sites' requests for language 103 preferences. 105 1.1. Example 107 A user navigates to "https://example.com/" for the first time. Their 108 user agent sends no language preferences along with the HTTP request. 109 The server, however, is interested in rendering content consistent 110 with the users' preferences, and requests this data by sending an 111 "Accept-CH" header (Section 2.2.1 of [I-D.ietf-httpbis-client-hints]) 112 along with the response: 114 Accept-CH: Lang 116 In response, the user agent includes language preferences in 117 subsequent requests: 119 Sec-CH-Lang: "en-US", "en", "de" 121 1.2. Notational Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. The 'Lang' Client Hint 131 The 'Lang' Client Hint exposes a user agent's language preferences to 132 a server. The definitions below assume that each user agent has 133 defined a "preferred languages list", which contains an arbitrary 134 number of strings adhering to the "language-range" grammar defined in 135 Section 2.1 of [RFC4647], and which is sorted in descending order of 136 user preference. The example given above, for instance, might result 137 in the list << "en-US", "en", "de" >>. 139 2.1. The 'Sec-CH-Lang' Header Field 141 The "Sec-CH-Lang" request header field gives a server information 142 about a user agent's language preferences. It is a Structured Header 143 ([I-D.ietf-httpbis-header-structure]) whose value MUST be a list 144 ([I-D.ietf-httpbis-header-structure], Section 3.2). Each item in the 145 list MUST be a string ([I-D.ietf-httpbis-header-structure], 146 Section 3.7). 148 The header's ABNF is: 150 Sec-CH-Arch = sh-list 152 To generate a "Sec-CH-Lang" header value for a given request, user 153 agents MUST: 155 1. If the request's client-hints set includes "Lang", then: 157 1. Let "value" be a Structured Header whose value is an empty 158 list. 160 2. For each item in the user agent's "preferred languages list": 162 1. Append the item to "value". 164 3. Set a header in request's header list whose name is "Sec-CH- 165 Lang", and whose value is "value". 167 2.2. Integration with Fetch 169 The Fetch specification should call into the following algorithm in 170 place of the current Step 1.4 in its HTTP-network-or-cache fetch 171 algorithm. 173 To set the language metadata for a request ("r"), the user agent MUST 174 execute the following steps: 176 1. If request's header list does not contain "Accept-Language", then 177 the user agent MAY append a header whose name is "Accept- 178 Language" and whose value corresponds to the requirements in 179 Section 5.3.5 of [RFC7231] to "request"'s header list. 181 2. Set request's "Sec-CH-Lang" header, as described in Section 2.1. 183 3. Security and Privacy Considerations 185 3.1. Secure Transport 187 Client Hints will not be delivered to non-secure endpoints (see the 188 secure transport requirements in Section 2.2.1 of 189 [I-D.ietf-httpbis-client-hints]). This means that language 190 preferences will not be leaked over plaintext channels, reducing the 191 opportunity for network attackers to build a profile of a given 192 agent's behavior over time. 194 3.2. Delegation 196 Client Hints will be delegated from top-level pages via Feature 197 Policy (once a few patches against Fetch and Client Hints and Feature 198 Policy land. This reduces the likelihood that language preferences 199 will be delivered along with subresource requests, which reduces the 200 potential for passive fingerprinting. 202 o Fetch integration of Accept-CH opt-in: 203 https://github.com/whatwg/fetch/issues/773 205 o HTML integration of Accept-CH-Lifetime and the ACHL cache: 206 https://github.com/whatwg/html/issues/3774 208 o Adding new CH features to the CH list in Fetch: 209 https://github.com/whatwg/fetch/issues/725 211 o Other PRs for adding the Feature Policy 3rd party opt-in: 212 https://github.com/whatwg/fetch/issues/811 and 213 https://github.com/wicg/feature-policy/issues/220 215 3.3. Access Restrictions 217 Language preferences expose quite a bit of entropy to the web. User 218 agents ought to exercise judgement before granting access to this 219 information, and MAY impose restrictions above and beyond the secure 220 transport and delegation requirements noted above. For instance, 221 user agents could choose to deliver the "Sec-CH-Lang" header only on 222 navigation, but not on subresource requests. Likewise, they could 223 offer users control over the values revealed to servers, or gate 224 access on explicit user interaction via a permission prompt or via a 225 settings interface. 227 4. Implementation Considerations 229 4.1. The 'Accept-Language' Header 231 User agents SHOULD deprecate the "Accept-Language" header in favor of 232 the Client Hints model described in this document. This deprecation 233 can take place in stages, perhaps by first limiting the scopes in 234 which the header is sent (navigations not subresources, etc), but the 235 goal should be to remove the header entirely in favor of this opt-in 236 model. 238 4.2. The 'Sec-CH-' prefix 240 Based on some discussion in https://github.com/w3ctag/design-reviews/ 241 issues/320, it seems reasonable to forbid access to these headers 242 from JavaScript, and demarcate them as browser-controlled client 243 hints so they can be documented and included in requests without 244 triggering CORS preflights. A "Sec-CH-" prefix seems like a viable 245 approach, but this bit might shift as the broader Client Hints 246 discussions above coalesce into something more solid that lands in 247 specs. 249 4.3. What about weight? 251 The "Accept-Language" header includes an optional weight along with 252 each listed language (e.g. "en;q=0.3" is less preferred than 253 "de;q=0.9"). A potential application of that is expressing equal 254 preference for two or more languages, but the challenge of exposing 255 such an option to users (compared to an ordered list) seems to make 256 practical use unlikely. Moreover, widely-used implementations of the 257 "Accept-Language" header blindly assign weights in exactly this way 258 (see Chromium's "HttpUtil::GenerateAcceptLanguageHeader", and 259 Firefox's "rust_prepare_accept_languages"). 261 In this document, I'm boldly (foolishly?) asserting that "q" 262 weighting can be removed without impact, in favor of assigning 263 semantic meaning to the ordering of the items in the header list. 265 5. IANA Considerations 267 This document intends to define the "Sec-CH-Lang" HTTP request header 268 field, and to register it in the permanent message header field 269 registry ([RFC3864]). 271 It also intends to deprecate the "Accept-Language" header field. 273 5.1. 'Sec-CH-Lang' Header Field 275 Header field name: Sec-CH-Lang 277 Applicable protocol: http 279 Status: standard 281 Author/Change controller: IETF 283 Specification document: this specification (Section 2.1) 285 5.2. 'Accept-Language' Header Field 287 Header field name: Accept-Language 289 Applicable protocol: http 291 Status: deprecated 293 Author/Change controller: IETF 295 Specification document: this specification (Section 4.1), and 296 Section 5.3.5 of [RFC7231] 298 6. Normative References 300 [I-D.ietf-httpbis-client-hints] 301 Grigorik, I., "HTTP Client Hints", draft-ietf-httpbis- 302 client-hints-06 (work in progress), July 2018. 304 [I-D.ietf-httpbis-header-structure] 305 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 306 draft-ietf-httpbis-header-structure-08 (work in progress), 307 October 2018. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, . 314 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 315 Procedures for Message Header Fields", BCP 90, RFC 3864, 316 DOI 10.17487/RFC3864, September 2004, . 319 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 320 BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, 321 . 323 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 324 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 325 DOI 10.17487/RFC7231, June 2014, . 328 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 329 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 330 May 2017, . 332 Appendix A. Changes 334 A.1. draft-west-ua-client-hints-00 336 o This specification sprang, fully-formed, from the head of Zeus. 338 Author's Address 340 Mike West 341 Google 343 Email: mkwst@google.com