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

[Martin Thomson <[e-mail]>]

I think maybe I was predisposed to not like this, but I do like it.
Not saying that I'm hugely enthusiastic about doing the CH part, but
the bit were User-Agent becomes fixed is really appealing.

One thing we might consider, if the timing works out, is having user
agents register their UA strings with us.  We can bake them into the
QPACK static table so that we can save bits.  I don't want to
privilege particular clients overly, so that only works if we have
broad acceptance of the plan.
On Thu, Nov 29, 2018 at 9:26 PM Mike West <[e-mail]> wrote:
>
> Hey folks,
>
> Section 9.7 of RFC7231 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