Re: Migrating some high-entropy HTTP headers to Client Hints.

[Thomas Peterson <[e-mail]>]

I would propose that all Accept* headers are included in Client Hints as 
all can be used for some level of fingerprinting, e.g. Accept can used 
to distinguish between desktop browsers (which typically have html/xml 
MIME types) and cURL/wget which by default have '*/*'. Many user agents 
also do their own guess work on response bodies anyway (such as looking 
at the magic number) to determine content type or encoding, so the 
impact of a "failed negotiation" of content can be limited.

Also, Is there a particular reason why Sec-CH-Lang omits Quality Values?


Regards


On 29/11/2018 10:22, Mike West wrote:
> Hey folks,
>
> Section 9.7 of RFC7231 
> <https://tools.ietf.org/html/rfc7231#section-9.7> rightly notes that 
> some of the content negotiation headers user agents deliver in HTTP 
> requests create substantial fingerprinting surface. I think it would 
> be beneficial if we took steps to reduce their prevalence on the wire, 
> and Client Hints looks like a reasonable infrastructure on top of 
> which to build.
>
> `User-Agent` and `Accept-Language` seem like particularly tasty and 
> low-hanging fruit, and I've sketched out two proposals as proofs of 
> concept:
>
> *   `User-Agent` could be represented as ~four distinct hints: `UA`, 
> `Model`, `Platform`, and `Arch`: 
> https://github.com/mikewest/ua-client-hints is a high-level explainer, 
> and https://tools.ietf.org/html/draft-west-ua-client-hints a sketchy 
> ID for the new headers.
>
> *   `Accept-Language` could be represented as a `Lang` hint: 
> https://github.com/mikewest/lang-client-hint is a high-level 
> explainer, https://tools.ietf.org/html/draft-west-lang-client-hint an 
> equally sketchy ID for the new header.
>
> I'd appreciate y'all's feedback. Thanks!
>
> -mike