W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

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

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 31 Aug 2015 17:00:33 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <5C42CA78-C17F-4AD4-BA3B-943AC2178706@mnot.net>
To: Amos Jeffries <squid3@treenet.co.nz>
Hi Amos,

> On 25 Aug 2015, at 1:05 am, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 24/08/2015 6:13 p.m., Mark Nottingham wrote:
>> We discussed this document in Dallas, and also a bit in Prague:
>> <http://tools.ietf.org/html/draft-grigorik-http-client-hints-02>
>> 
>> 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:
  http://www.w3.org/2001/tag/doc/unsanctioned-tracking/
  https://w3c.github.io/fingerprinting-guidance/


> (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).

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Monday, 31 August 2015 07:01:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC