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

I agree with Yoav on the direction to separate the infrastructure from the
features.

We started by integrating the two within one spec, but overtime realized
that it's hard to cleanly and crisply define many of the concepts without
pulling in and having to replicate a whole lot of existing concepts and
plumbing from HTML, Fetch, and other specs. This problem also only gets
harder when we want to spec browser implementation. Hence the reason why we
started pulling out individual hints (e.g. Downlink, RTT, ECT) into NetInfo
spec, where those concepts and implementations are defined — bonus,
everything is in one place for consistency — and I think it makes sense to
do the same for DPR and remaining hints in current spec.

+Mike West <mkwst@google.com> I like your proposal for User-Agent and
Accept-Language. Most of the CH plumbing is already in place (or close to)
in HTML spec, WDYT of defining those hints directly in the HTML spec?

On Fri, Nov 30, 2018 at 2:10 AM Yoav Weiss <yoav@yoav.ws> wrote:

>
>
> On Fri, Nov 30, 2018 at 9:47 AM Mike West <mkwst@google.com> wrote:
>
>> On Fri, Nov 30, 2018 at 1:30 AM Mark Nottingham <mnot@mnot.net> 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 <mkwst@google.com> 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/
>>>
>>>