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

[Yoav Weiss <[e-mail]>]

On Fri, Nov 30, 2018 at 9:47 AM Mike West <[e-mail]> wrote:

> On Fri, Nov 30, 2018 at 1:30 AM Mark Nottingham <[e-mail]> wrote:
>
>> I, for one, welcome our new Client Hint overlords.
>>
>> Personally, I'd like to see these integrated into the current CH
>> document, rather than as separate drafts. CH still needs some work, so it's
>> not like we're going to get it out the door tomorrow.
>>
>
On my list, I want to remove the specific image-related features and move
them to their own specification, with a well defined browser processing
model.
Anything else that's needed to get CH infra "out the door tomorrow"? :)


>
> These hints seem pretty clearly separable from the infrastructure upon
> which they're built. I'd prefer to split them out into things-in-themselves
> that we can point developers towards independently, giving ourselves the
> opportunity to explain the rationale and background more coherently than I
> think we'll be able to if we bury these in a subsection of the larger
> document.
>

Similarly, I'd prefer clear distinctions between "CH as infrastructure" and
"Features that use the CH infrastructure".
We've had a lot of confusion and resistance to "CH the infrastructure" due
to some of the features that rely on it, and clearly separating the two
will enable implementations and user-agents to say "I support the CH
infrastructure, and certain features relying on it, but not feature X".

>From a procedural perspective, we wouldn't want every added feature to
delay "CH as infrastructure" to advance.


>
> I'll defer to the group as to how y'all would like to handle these, but
> I'd prefer several short and focused docs as a reader.
>
> -mike
>
> However, it seems like Ilya wants to go in a different direction, based
>> upon the notes we received for Bangkok.
>>
>> Ilya, your thoughts?
>>
>>
>>
>> > On 29 Nov 2018, at 9:22 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
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>