Re: Call for Adoption: draft-grigorik-http-client-hints

Hi Amos,

> On 25 Aug 2015, at 1:05 am, Amos Jeffries <> wrote:
> On 24/08/2015 6:13 p.m., Mark Nottingham wrote:
>> We discussed this document in Dallas, and also a bit in Prague:
>> <>
>> We'd talked about doing this at the same time as Key, but I think that can be decoupled (especially since we have an implementer for Client Hints without Key).
>> Based on the discussion so far, I believe that we should adopt this document as a WG product, with a target of Proposed Standard.
>> I've discussed it with our Area Director, who agrees that it's a reasonable thing for us to do.
>> Please comment on-list; we’ll make a decision about adoption this time next week.
> My personal opinion;
>  is that this seems like a fertile ground for filling the WG with more
> politick.
> In the past years its been interesting watching the opinions of those
> pushing for these tracking headers to exist formally compete with the
> anonymity crowd, the privacy crowd and the anti-surveillance crowd.
> Which kind of highlights that the main use-case, whether acknowledged
> or not; will be for enabling surveillance.
> If they are going to exist at all, I think a standard format will be a
> Good Thing. Much like Forwarded header sweeping away the custom cruft.

OK. FWIW, I'd like to see us consider recommending that this feature be HTTPS-only, and perhaps limiting the granularity of information available in things that have pixel counts. 

Some background reading:

> (with web developer hat on);
> I've always been a little mystified why these were even being asked for.
> The tools available for on-device decisions about display are pretty
> good, an coding frameworks make development for those easy.
> Looking at screen pixel-width I can think of two cases where it would be
> useful;
> 1) a browser fetching the main HTML of a page. Doing so lets the server
> elide segments of the HTML doing logic for other screen sizes.
> The purpose of having that in the page in the first place is/was so
> that the HTML part is portable between devices without re-downloading it
> on each one. The sub-resources downloaded as needed or portable where
> possible.
> Having non-portable versions makes the HTML itsef just an instance of
> case #2, below.
> 2) an app of game needing to fetch specific sized images or similar for
> display.
> Embedding img size details in the fetched URL, and fetching only the
> relevant one is just a far better way to go for latency, portability and
> cache friendliness. There is no difference in origin server processing
> load between where the detail is placed.
> (and with my Squid hat on);
> It is funny the draft should point out cache friendliness as a reason
> for avoiding alternative use cases. Yes this mechanism is better than
> them, but only by degrees.
> Realistically negotiated content means using Vary/Key which are also
> somewhat in the cache-unfriendly category. Because the logics needed to
> identify and cache variants are quite complex and can *double* (or even
> triple) the lookup latency for a cache, especially when optimized fast
> hashing is used.

We've talked about this offline some, and I think we can get to a place where Key can be at most a double-lookup.

> The URL-path with values in such places like filenames are just the
> optimal form in terms of reduced latency from faster cache aggregation
> and lookup. Actively increasing network latency by using negotiated
> features seems a daft approach when its unnecessary.
> I'm still waiting for someone to present an actual concrete use-case
> that proves there is a need for this latency loss just to relay teh
> Client-Hints details (and some of the Accept things too). All I'm seeing
> so far is that its better than some badly designed old/current systems
> who probably wont ever be upgraded to the new mechanism anyway.
> There are probably other use-cases on the table I'm not aware of yet.
> I'm all ears.

Any further thoughts after Ilya's mail?

At this point, I'm hearing a fair amount of enthusiasm from a few different quarters (taking into account the discussion at the meeting).


Mark Nottingham

Received on Monday, 31 August 2015 07:01:08 UTC