Re: My question about client hints

Both Kenji and Yoav hit on the key points already, so I'll try to keep it
brief.. :)

CH intro provides a high-level overview of the limitations of current
approaches:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05#section-1

The main limitations of cookie-based approaches are:

   - Doesn't work for dynamic variables. A few examples..
      - "Width" to communicate desired image width
      - "Viewport-Width" can change too: split screen views, browser resize
      on desktop, etc.
      - "ECT", "RTT", "Downlink" are based on recent observed mesurements
      - "Save-Data" is subject to user toggle / preference
      - ... etc., virtually every interesting hint requires cooperation
      from the browser / has dynamic values.
   - Cookies have a number of other limitations
      - Vary + Cookie.. good luck
      - It's a free-for all in terms of names an syntax: good luck on
      interop.
      - Doesn't work for 3P origins — e.g. if you're a CDN for static
      content, good luck getting the cookies set in the first place,
you now also
      need JS executing in 1P context.

CH address the above by defining a simple framework for how interoperable
hints should be specced, negotiated between client and origin, and
implemented by the browser (in upstream specs :)).

On Tue, Mar 20, 2018 at 10:53 AM, Yoav Weiss <yoav@yoav.ws> wrote:

>
> A few things that a cookie cannot cover:
> * On the first page load, CH would give you hints for all the subresources
> of the page, whereas a JS basde solution would be racy and is likely to
> miss many of the subresources which loading started before that JS actually
> ran. As Alex mentioned, all browsers have some form of a preloader, which
> is likely to discover and request those resources before the cookie is set.
> * Cookies cannot cover image specific `width` values, which CH can given
> that this information is available in HTML.
> * Cookies cannot cover 3rd party resources, which CH did support. This
> support was currently removed, but would be reinstated once Feature-Policy
> enables a mechanism for the 1st party to opt in to expose hints to specific
> 3rd parties.
>
>
> On Tue, Mar 20, 2018 at 6:32 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> At today's session I asked the following question:
>>
>> Given that you can only send client hints if the site could run JS and
>> set a cookie, then
>> why can't the site just run JS on first contact, extract this data, and
>> store it in a cookie,
>> at which point it is available on all previous contacts.
>>
>> As far as I can tell, the only difference here is on first contact. What
>> am I missing.
>>
>> -Ekr
>>
>>