Intent to Ship: Device Memory JS API

[Shubhie Panicker]

Contact emails

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

Spec

Link to explainer: https://github.com/w3c/device-memory

Spec: https://rawgit.com/w3c/device-memory/master/device-memory.html#sec-device-memory-js-api

(bug for setting up spec publishing)

Summary

Add JS API to surface device capability for memory i.e. device RAM. This is to enable web apps to customize content depending on device memory constraints, and report to analytics.

NOTE: This is the API counterpart for the "Device Memory Client Hints Header" that shipped in M61 (link to Intent to Ship)

Motivation

Developers need “device-class” signal for:

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

• request / serve light version of video player in Facebook

• request / serve lightweight tile images in Google Maps

2. Analytics: analytics & Ads 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; Ad providers need to understand whether an Ad is generally not performant or only on certain low end devices. Also, app developers need to understand their users and their constraints, device class is an important signal for this.

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

The API is only available to secure HTTPS connections, based on feedback in I2S for counterpart header.

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

Link to “Intent to Implement” blink-dev discussion

Intent to Implement thread

Interoperability and Compatibility Risk

Compat risk is low. On browsers that don't support the API, it is not available, and can be feature detected.

Interop risk: medium.

Edge: Public support (link)

Firefox: No signals

Safari: No signals

Web developers: Positive (positive signals from Facebook, Google Search, Google Maps, Youtube, Akamai, Google Docs 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

[Shubhie Panicker]

[Yoav Weiss]

Non-owner LGTM! 

The analytics use case would be extremely useful to make developers aware of the impact the user's device class has on their site's performance metrics. The "light version" use case will enable developers to stop using API support as a proxy to determine capabilities.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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/CAK7ODi-885YZANPmJwJ%3D3UgS%2BD%2B77qvKTo3vd0%3DuoWX_mZuk6g%40mail.gmail.com.

[Rick Byers]

LGTM1.

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/CAK7ODi-885YZANPmJwJ%3D3UgS%2BD%2B77qvKTo3vd0%3DuoWX_mZuk6g%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/CACj%3DBEj3J4SggRTAhjxgoR8n%2B%2BAEyMGsC5h-hmzUb_DPQ49%3DJA%40mail.gmail.com.

[Chris Harrelson]

LGTM2.

FYI a TAG review was also filed today.

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

[Dimitri Glazkov]

LGTM3

LGTM1.

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/CAK7ODi-885YZANPmJwJ%3D3UgS%2BD%2B77qvKTo3vd0%3DuoWX_mZuk6g%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/CACj%3DBEj3J4SggRTAhjxgoR8n%2B%2BAEyMGsC5h-hmzUb_DPQ49%3DJA%40mail.gmail.com.

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

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/CAFUtAY-pS2vRX5a-43PWzGZu7tvJG9fGfcJmisgYtBi_S%2BOzrQ%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%2Bw_bbJbD%3D%3D_ParmHRc10Q52de5rOa4tOdc18Ra9ynwjQZA%40mail.gmail.com.

[Boris Zbarsky]

On 8/24/17 6:07 PM, 'Shubhie Panicker' via blink-dev wrote:
> Spec:
> https://rawgit.com/w3c/device-memory/master/device-memory.html#sec-device-memory-js-api

Shubhie,

Are there plans to actually advance this on a standards track? The
document currently says that there are not.

> Firefox: No signals

I'd have to check with the people involved in the fingerprinting work,
but I don't think there's a significant fingerprinting mitigation here
by limiting to only two significant digits, for what it's worth. As the
spec draft points out, this still allows the following values (in GB):

0.25, 0.5, 0.75, 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128

and I believe in practice that covers all the values users would have on
current devices.

This is likely to make this API fairly problematic from Mozilla's point
of view.

-Boris

[Shubhie Panicker]

Hey Boris,

The big change we've made based on last I2S thread is restricting to secure HTTP connections.

We'd be open to your suggestions here if that helps FF get behind this API.

For instance it would be fairly easy to restrict to less than 4G devices, and still be a useful API.

Thoughts?

[Boris Zbarsky]

On 8/30/17 1:31 PM, Shubhie Panicker wrote:
> We'd be open to your suggestions here if that helps FF get behind this API.
> For instance it would be fairly easy to restrict to less than 4G
> devices, and still be a useful API.
> Thoughts?

I don't have concrete thoughts offhand; it would be better to bring this
up with people who've been thinking about these problems and Mozilla's
approach to them. Posting to dev-pl...@lists.mozilla.org might work
to get people's attention, maybe....

Sorry to not offer more here,
Boris

[Shubhie Panicker]

Ok I'll start a thread there, thanks.

[Jochen Eisinger]

Shubhie, can you post a link to this thread please?

--
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/CAK7ODi9fzHWpbmp1yPqNvd3fnuZcNJZrEuP4bex6%2Be%3De_bm35Q%40mail.gmail.com.

[Shubhie Panicker]

Will do.

(awaiting moderator approval at the moment)

[Shubhie Panicker]

Here's the link from the discussion:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/cfydu35XdnY

As dev-pl...@lists.mozilla.org is a discussion list there's no conclusion per se, though I learned the following:

- Dan Veditz and Martin Thompson suggested that FF could expose a smaller set of values, and maybe we should not standardize the exact values -- this seems the most plausible outcome and I'll follow up to see how we could word the spec to allow this

- Martin mentioned concerns with underlying Client Hints 

- Tom Ritter suggested a binary opinionated signal (here's why we don't take that approach)

- couple other folks expressed concerns with the premise of the API (and Client Hints in general) and weren't convinced of the validity of the use-cases (so the thread is not converging at this point)

[Shubhie Panicker]

[Shubhie Panicker]

To follow up on this, we updated the spec with following changes:

- recommended upper and lower limit for the exposed memory values (and indicated that implementors can decide what their limits are)

- determine reported value using most significant bit (vs 2 most significant bits)

Updated spec link:

https://w3c.github.io/device-memory/#computing-device-memory-value