Intent to Ship: Device Memory Client Hint header

[Shubhie Panicker]

Contact emails

pani...@chromium.org, fme...@chromium.org

Spec

Link to explainer: https://github.com/spanicker/device-ram

Spec: https://github.com/WICG/device-ram/blob/master/device-memory.bs

Summary

Add HTTP Client Hint header to surface device capability for memory i.e. device RAM. This is to enable web apps to customize content depending on device RAM constraints.

Motivation

Developers need “device-class” signal for:

1. Serving “light” version of the site or specific components, for low-end devices:

• Serve Google "search lite" - a 10KB search results page used in EM.

• Serve a light version of video player in Facebook

• Serve lightweight tile images in Google Maps

2. Normalizing Metrics: analytics need to be able to normalize their metrics against the device-class. For instance, a 100ms long task on a Pixel is a more severe issue vs. on a low-end device.

Device memory is an especially useful signal for determining “device-class”. Low memory devices devices (under 512MB, 512MB - 1GB) are widely used in emerging markets.

(For details on why “Device Class” is not directly exposed, see here)

Privacy & Security

Restricting to a ceiling value (rounded to the two most significant bits - details here), as opposed to exact value, significantly mitigates fingerprinting.

As noted in Explainer device identification is already possible today based on UA string.

Requiring per-origin opt-in with Accept-CH restricts when the header is advertised.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement thread

WICG discourse link

Interoperability and Compatibility Risk

Compat risk is low. On browsers that don't support Client Hints, the header will not be sent, and developers are expected to serve the default content. The potential risk comes if developers assume the presence of this header, instead of providing graceful fallback. We've provided guidance in the explainer to help avoid this.

Interop risk: medium.

Edge: Positive signal (public-web-perf meeting agenda - doc comments)

Firefox: No signals

Safari: No signals

Web developers: Positive (positive signals from Facebook, Google Search, Google Maps, Youtube, Akamai, etc.)

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Layout tests not yet upstreamed

Chromium issue to upstream some existing tests

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=710702

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5741299856572416

Requesting approval to ship?

Yes

[Rick Byers]

/cc Todd on the Edge team who said: "We are supportive of this proposal" (just to ensure he's aware of the intent).

Here's a working spec link: https://rawgit.com/WICG/device-ram/master/device-memory.html  (filed a bug)

This is just about the header, not the JS API - right?  Is there a reason to want to ship the header first ahead of having a JS API?  IIRC all other Client-Hints are for things that can also be determined by JavaScript (which is why they are "hints", not just brand new APIs)?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi_Z0fovkLAAgG-on8GgxBuecdNEVtcvi6QaEQ69HEvu0g%40mail.gmail.com.

[Shubhie Panicker]

On Fri, Jul 14, 2017 at 10:39 AM, Rick Byers <rby...@chromium.org> wrote:

/cc Todd on the Edge team who said: "We are supportive of this proposal" (just to ensure he's aware of the intent).

Here's a working spec link: https://rawgit.com/WICG/device-ram/master/device-memory.html  (filed a bug)

This is just about the header, not the JS API - right?  Is there a reason to want to ship the header first ahead of having a JS API?  IIRC all other Client-Hints are for things that can also be determined by JavaScript (which is why they are "hints", not just brand new APIs)?

 

We plan to do a separate I2S for JS API. The header is critical functionality and more urgently needed by PWAs on low end devices. The primary use-case is serving different content (eg. Maps "light") based on the header value on initial request. 

However this feature is dependent on Accept-CH Lifetime, my understanding was that we are shipping both, but haven't heard the latest update there. If Accept-CH Lifetime is not shipping any time soon, then there's no urgency here.

Ilya, could you chime in on whether Client Hints has a requirement for JS API, I thought these were fairly independent.

[Shubhie Panicker]

On Fri, Jul 14, 2017 at 4:00 PM, Shubhie Panicker <pani...@google.com> wrote:

On Fri, Jul 14, 2017 at 10:39 AM, Rick Byers <rby...@chromium.org> wrote:

/cc Todd on the Edge team who said: "We are supportive of this proposal" (just to ensure he's aware of the intent).

Here's a working spec link: https://rawgit.com/WICG/device-ram/master/device-memory.html  (filed a bug)

Thanks for the bug, plh@ is helping with automated push to gh-pages.

[Ilya Grigorik]

On Fri, Jul 14, 2017 at 4:00 PM, Shubhie Panicker <pani...@google.com> wrote:

Ilya, could you chime in on whether Client Hints has a requirement for JS API, I thought these were fairly independent.

They're independent. Generally speaking, I think it's a best practice to expose both (and ideally at the same time), but it sounds like we're planning to followup with the JS implementation in the next release.. So, no objections from me here.

As an aside, perhaps we should update the spec to reflect that we're also planning to expose this data to JS?

[Shubhie Panicker]

On Fri, Jul 14, 2017 at 7:57 PM, Ilya Grigorik <igri...@google.com> wrote:

On Fri, Jul 14, 2017 at 4:00 PM, Shubhie Panicker <pani...@google.com> wrote:

Ilya, could you chime in on whether Client Hints has a requirement for JS API, I thought these were fairly independent.

They're independent. Generally speaking, I think it's a best practice to expose both (and ideally at the same time), but it sounds like we're planning to followup with the JS implementation in the next release.. So, no objections from me here.

As an aside, perhaps we should update the spec to reflect that we're also planning to expose this data to JS?

Done. 

[Rick Byers]

Ok, thanks Shubhie.  Sounds reasonable to me - LGTM1

[Todd Reifsteck]

Thanks for CCing me, Rick!

 

I am generally supportive of investment in this area.

 

-Todd

[Dimitri Glazkov]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MWHPR21MB0158E761715EC2CC1E5333BCC2A60%40MWHPR21MB0158.namprd21.prod.outlook.com.

[Chris Harrelson]

Hi,

Has a TAG review been filed for this feature? That would be useful.

Otherwise, LGTM3.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx6g-uqQ4dKfPf2vmRctJ%2BrTuQ3XKiKVSpg%3DYM%2BpWw3AKA%40mail.gmail.com.

[Jochen Eisinger]

would it make sense to restrict this feature to secure connections?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx6g-uqQ4dKfPf2vmRctJ%2BrTuQ3XKiKVSpg%3DYM%2BpWw3AKA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9HgbUKMH0On3nyKw_9hoTH0JEOMM8JTEO4k8DZntmS6g%40mail.gmail.com.

[Shubhie Panicker]

On Fri, Jul 21, 2017 at 2:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

would it make sense to restrict this feature to secure connections?

Yes this totally makes sense to me for Client Hints. (It would be too confusing if this is Device Memory only, but not any other Client Hints)

Per Ilya, the breakage for existing Client Hints should be relatively low. Can we ship a change now to update Client Hints to trigger for HTTPS-only? What's the recommended process?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx6g-uqQ4dKfPf2vmRctJ%2BrTuQ3XKiKVSpg%3DYM%2BpWw3AKA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Ilya Grigorik]

On Fri, Jul 21, 2017 at 9:53 AM, Shubhie Panicker <pani...@google.com> wrote:

On Fri, Jul 21, 2017 at 2:05 AM, Jochen Eisinger <joc...@chromium.org> wrote:

would it make sense to restrict this feature to secure connections?

Yes this totally makes sense to me for Client Hints. (It would be too confusing if this is Device Memory only, but not any other Client Hints)

Per Ilya, the breakage for existing Client Hints should be relatively low. Can we ship a change now to update Client Hints to trigger for HTTPS-only? What's the recommended process?

To connect a few separate threads here..

a) Tarun is working [1] on Accept-CH-Lifetime (ACL) and HTTPS requirement came up there

b) Artur flagged some ACL related issues [2], which are taking us down origin-scoped opt-in route

Assuming we follow through with (b), I think it also makes sense to explore making ACL HTTPS-only and extend that as a requirement to all hints as well -- for one, consistency is a plus, but more importantly it doesn't make sense to have some hints available over HTTP if ACL is HTTPS-only.

On compatibility front, I think now is the time to make this change.. Virtually every developer and organization I've spoken to about their experience with existing CH model (without ACL) has asked for ACL as a requirement, because they want (read, need) these hints on navigation requests in addition to subresource requests, and current usage [3] without ACL is low enough to make the change with minimal pain.

Assuming the above is reasonable, I'd propose:

1. Hash out the opt-in + HTTPS details in [2] and land the spec update
2. Ship HTTPS-only as part of Accept-CH-Lifetime i2s

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/QHI3sio6--Q/v_zWX1O6AAAJ

[2] https://github.com/httpwg/http-extensions/issues/372

[3] https://www.chromestatus.com/metrics/feature/timeline/popularity/904

[Jochen Eisinger]

sgtm, thx!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx6g-uqQ4dKfPf2vmRctJ%2BrTuQ3XKiKVSpg%3DYM%2BpWw3AKA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Shubhie Panicker]

SGTM. 

Ilya - could you file relevant spec & crbugs? Thanks.

sgtm, thx!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOtFfx6g-uqQ4dKfPf2vmRctJ%2BrTuQ3XKiKVSpg%3DYM%2BpWw3AKA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Ilya Grigorik]

On Mon, Jul 24, 2017 at 8:03 AM, Shubhie Panicker <pani...@google.com> wrote:

SGTM. 

Ilya - could you file relevant spec & crbugs? Thanks.

We have https://github.com/httpwg/http-extensions/issues/372.. Let's tackle it there.