Subject: My question about client hints

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 17:22:30 +0000

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

---

From: Kenji Baheux <[email-masked]>
Date: Tue, 20 Mar 2018 17:54:24 +0000

It seems that the JS+cookie approach wouldn't work well for client hints
that might change in between accesses.
Resources that are sent up to the point JS can run and update its
understanding of a client's preferences will be inadequate in various ways.

In particular, this seems concerning for the save-data hint as it might be:

   - OFF initially because the user was on WiFi, or in their home country
   - ON for a subsequent navigation because the user is now on their mobile
   connection, or roaming abroad.

resulting in less than ideal bandwidth usage.

On Tue, Mar 20, 2018 at 5:33 PM Eric Rescorla <[email-masked]> wrote:

> As far as I can tell, the only difference here is on first contact. What
> am I missing.
>
> -Ekr
>
>

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 20 Mar 2018 17:53:43 +0000

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.

---

From: Ilya Grigorik <[email-masked]>
Date: Mon, 26 Mar 2018 22:04:26 -0700

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 <[email-masked]> wrote:

>> Given that you can only send client hints if the site could run JS and
>> set a cookie, then