Intent to Implement and Ship: Save-Data hint

[Ben Greenstein]

Contact emails

m...@chromium.org, be...@chromium.org, igri...@chromium.org, si...@chromium.org

Spec

https://tools.ietf.org/html/draft-grigorik-http-client-hints-03#section-7

Summary

The “Save-Data” header field is a boolean that, in requests, indicates client’s explicit opt-in for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. When communicated to origins, it allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate "light mode" markup, etc.

(Note: this is a successor to RQ i2i [1] based on feedback from that and related threads)

Motivation

Users on very slow networks (e.g., 2G) sometimes must wait too long for high fidelity pages to load, and users on very expensive networks (e.g. roaming) sometimes must pay too much to retrieve high fidelity content. An origin or transcoding proxy that receives the Save-Data header can improve page load time and/or reduce costs by returning an alternate (“light”) version of the requested resource.

Today developers are forced to rely on variety of other unstable signals: past performance data, measured RTT, IP subnet masks, device fingerprinting, etc. By contrast, Save-Data provides a stable, user controlled, and more accurate signal to developers - e.g. a user may be on a fast connection but roaming (expensive) and wants to save data, and without Save-Data there is no easy or standard way to detect and adapt the experience to account for this.

Compatibility risk

Low. Origins and proxies that do not make use of Save-Data hint can safely ignore it.

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=485640#c9

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[1] https://groups.google.com/a/chromium.org/forum/#!msg/net-dev/gaNYM3vKNfY/j8iHsV9yHCAJ

[Yoav Weiss]

+1

A few questions:

* Any word from other browser vendors regarding that specific Client-Hint? Most of them have been receptive to the notion of Client-Hints in general, so there's no reason to think they'd object to the concept, but would be nice to get their feedback on this.

* In terms of UI, are we planning to expose an explicit user setting for this, or will it at first be flipped on when "data saver" is on? (Or something else entirely?)

* Is the plan to implement it as part of Blink (along with the other Client Hints at loader/FrameFetchContext)?

[Ilya Grigorik]

On Wed, Sep 30, 2015 at 2:13 PM, Yoav Weiss <yo...@yoav.ws> wrote:

+1

A few questions:

* Any word from other browser vendors regarding that specific Client-Hint? Most of them have been receptive to the notion of Client-Hints in general, so there's no reason to think they'd object to the concept, but would be nice to get their feedback on this.

Opera folks are on-board (cc'ed). I'm hoping other proxy-browsers will follow as well.

 

* In terms of UI, are we planning to expose an explicit user setting for this, or will it at first be flipped on when "data saver" is on?

For Chrome, the latter. The hint will be sent as long as user has "Data Saver" feature enabled in Chrome.

  

* Is the plan to implement it as part of Blink (along with the other Client Hints at loader/FrameFetchContext)?

I'll defer to Ben on this one :)

[Matt Menke]

On Wed, Sep 30, 2015 at 5:16 PM, 'Ilya Grigorik' via net-dev <net...@chromium.org> wrote:

On Wed, Sep 30, 2015 at 2:13 PM, Yoav Weiss <yo...@yoav.ws> wrote:

+1

A few questions:

* Any word from other browser vendors regarding that specific Client-Hint? Most of them have been receptive to the notion of Client-Hints in general, so there's no reason to think they'd object to the concept, but would be nice to get their feedback on this.

Opera folks are on-board (cc'ed). I'm hoping other proxy-browsers will follow as well.

 

* In terms of UI, are we planning to expose an explicit user setting for this, or will it at first be flipped on when "data saver" is on?

For Chrome, the latter. The hint will be sent as long as user has "Data Saver" feature enabled in Chrome.

  

* Is the plan to implement it as part of Blink (along with the other Client Hints at loader/FrameFetchContext)?

I'll defer to Ben on this one :)

Here's the initial CL to wire the flag up:  https://chromiumcodereview.appspot.com/1310743003/.

Quick description of the CL:  A flag will live in content/, and be associated with each navigation.  All resources for a single navigation will use the same lo-fi mode setting (favicons presumably shouldn't, because we don't want to remember low quality icons them - that needs to be looked into).  The flag will be attached by content, so there will be no Blink changes.  In the CL, a header is attached by the data saver code, but we'll want to add the hint header in content, of course.

I don't know the long term UI plans, but I assume there will be some way to force a full fidelity page load.

 

 

On Wed, Sep 30, 2015 at 8:47 PM, Ben Greenstein <be...@chromium.org> wrote:

Contact emails

m...@chromium.org, be...@chromium.org, igri...@chromium.org, si...@chromium.org

Spec

https://tools.ietf.org/html/draft-grigorik-http-client-hints-03#section-7

Summary

The “Save-Data” header field is a boolean that, in requests, indicates client’s explicit opt-in for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. When communicated to origins, it allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate "light mode" markup, etc.

(Note: this is a successor to RQ i2i [1] based on feedback from that and related threads)

Motivation

Users on very slow networks (e.g., 2G) sometimes must wait too long for high fidelity pages to load, and users on very expensive networks (e.g. roaming) sometimes must pay too much to retrieve high fidelity content. An origin or transcoding proxy that receives the Save-Data header can improve page load time and/or reduce costs by returning an alternate (“light”) version of the requested resource.

Today developers are forced to rely on variety of other unstable signals: past performance data, measured RTT, IP subnet masks, device fingerprinting, etc. By contrast, Save-Data provides a stable, user controlled, and more accurate signal to developers - e.g. a user may be on a fast connection but roaming (expensive) and wants to save data, and without Save-Data there is no easy or standard way to detect and adapt the experience to account for this.

Compatibility risk

Low. Origins and proxies that do not make use of Save-Data hint can safely ignore it.

Ongoing technical constraints

None.

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

Yes.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=485640#c9

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[1] https://groups.google.com/a/chromium.org/forum/#!msg/net-dev/gaNYM3vKNfY/j8iHsV9yHCAJ

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADXXVKrDam1Ar2u_UVfHu16S_uyFfiqtwcK%3DGbSsv2A49djk_w%40mail.gmail.com.

[Yoav Weiss]

On Wed, Sep 30, 2015 at 11:21 PM, Matt Menke <mme...@chromium.org> wrote:

On Wed, Sep 30, 2015 at 5:16 PM, 'Ilya Grigorik' via net-dev <net...@chromium.org> wrote:

On Wed, Sep 30, 2015 at 2:13 PM, Yoav Weiss <yo...@yoav.ws> wrote:

+1

A few questions:

* Any word from other browser vendors regarding that specific Client-Hint? Most of them have been receptive to the notion of Client-Hints in general, so there's no reason to think they'd object to the concept, but would be nice to get their feedback on this.

Opera folks are on-board (cc'ed). I'm hoping other proxy-browsers will follow as well.

 

* In terms of UI, are we planning to expose an explicit user setting for this, or will it at first be flipped on when "data saver" is on?

For Chrome, the latter. The hint will be sent as long as user has "Data Saver" feature enabled in Chrome.

  

* Is the plan to implement it as part of Blink (along with the other Client Hints at loader/FrameFetchContext)?

I'll defer to Ben on this one :)

Here's the initial CL to wire the flag up:  https://chromiumcodereview.appspot.com/1310743003/.

Quick description of the CL:  A flag will live in content/, and be associated with each navigation.  All resources for a single navigation will use the same lo-fi mode setting (favicons presumably shouldn't, because we don't want to remember low quality icons them - that needs to be looked into).  The flag will be attached by content, so there will be no Blink changes.  In the CL, a header is attached by the data saver code, but we'll want to add the hint header in content, of course.

Thanks! :) IIUC, the LoFi flag maps directly to "Save-Data: 1". Is that correct?

I remember that at an earlier stage, there were discussions about a "placeholder" state, as well as "compressed" and "original". How comfortable are we with a boolean Save-Data in the long run?

[Ben Greenstein]

On Wed, Sep 30, 2015 at 3:03 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Sep 30, 2015 at 11:21 PM, Matt Menke <mme...@chromium.org> wrote:

On Wed, Sep 30, 2015 at 5:16 PM, 'Ilya Grigorik' via net-dev <net...@chromium.org> wrote:

On Wed, Sep 30, 2015 at 2:13 PM, Yoav Weiss <yo...@yoav.ws> wrote:

+1

A few questions:

* Any word from other browser vendors regarding that specific Client-Hint? Most of them have been receptive to the notion of Client-Hints in general, so there's no reason to think they'd object to the concept, but would be nice to get their feedback on this.

Opera folks are on-board (cc'ed). I'm hoping other proxy-browsers will follow as well.

 

* In terms of UI, are we planning to expose an explicit user setting for this, or will it at first be flipped on when "data saver" is on?

For Chrome, the latter. The hint will be sent as long as user has "Data Saver" feature enabled in Chrome.

  

* Is the plan to implement it as part of Blink (along with the other Client Hints at loader/FrameFetchContext)?

Not clear yet, but that was my initial thinking. I'm happy to share a design when it's fleshed out.

 

I'll defer to Ben on this one :)

Here's the initial CL to wire the flag up:  https://chromiumcodereview.appspot.com/1310743003/.

Quick description of the CL:  A flag will live in content/, and be associated with each navigation.  All resources for a single navigation will use the same lo-fi mode setting (favicons presumably shouldn't, because we don't want to remember low quality icons them - that needs to be looked into).  The flag will be attached by content, so there will be no Blink changes.  In the CL, a header is attached by the data saver code, but we'll want to add the hint header in content, of course.

Thanks! :) IIUC, the LoFi flag maps directly to "Save-Data: 1". Is that correct?

Sorry, so that isn't correct. LoFi is triggered automatically off a network quality estimator. The Save-Data header is about communicating user preference. 

I remember that at an earlier stage, there were discussions about a "placeholder" state, as well as "compressed" and "original". How comfortable are we with a boolean Save-Data in the long run?

This is a hard question. I think it's worth discussing whether there's a need to go beyond a boolean so that the user can express degrees of desire to save data at the increasing cost to page fidelity. And I can imagine good arguments for three values ("don't save"; "save, but don't change the content obviously"; and "do what ever it takes to save as much data as possible"). But even at three values, it becomes unwieldy, and handling the header gets significantly complicated beyond three values.

[Yoav Weiss]

I agree it's a hard question. I also agree we should discuss it further, or think of how we could extend 'Save-Data' in the future.

I think that the part that gets unwieldy beyond three values is actually getting the user's preference and making sure that they understand what they are choosing.

But I can definitely see a future where "Save-Data: preview" provides Facebook-like 200 bytes preview images, "Save-Data: compress" provides the equivalent of what the Data-Saver proxy is doing, and "Save-Data: no/original" provides a preference of the user to receive high-quality images (contrary to lack of "Save-Data" that may indicate a lack of preference).

Related: Firefox seems to have added a new "click-to-play images" preference on Firefox for Android, which makes me think they may be favorable of a Save-Data preference.

[Ilya Grigorik]

The issue that we ran into with RQ was that it quickly became unwieldy as we tried to re-use the same mechanism to communicate preferences for image compression settings/quality, video quality, etc. It was hard to reason about from spec and cross-browser implementation standpoint, and even harder from cache perspective.

FWIW, the intent behind Save-Data is to separate out the common intent from the "how". That is, there are many different mechanisms to deliver data reduction, and opt-in any one them is what Save-Data is all about... which is why it was proposed as a boolean. That said, I could be convinced that perhaps we should change it to a keyword (e.g. "on"), such that it can be extended (as a list) in the future.. For now, it would be:

- (no Save-Data header) -- user has not enabled any form of data savings mechanisms.

- Save-Data: on -- user has enabled some/any form of data savings mechanism.

If and when there is an explicit opt-out user preference for such features we could extend the above to include "off" state as well. Yay/nay?

Finally, as far as specific strategies for delivering data reduction.. I think these ought to be communicated as separate signals, which allows them to be content-specific and more cache friendly - e.g. a separate header for communicating image quality or video preference, etc.

ig

[Yoav Weiss]

On Thu, Oct 1, 2015 at 8:34 PM, Ilya Grigorik <igri...@google.com> wrote:

The issue that we ran into with RQ was that it quickly became unwieldy as we tried to re-use the same mechanism to communicate preferences for image compression settings/quality, video quality, etc. It was hard to reason about from spec and cross-browser implementation standpoint, and even harder from cache perspective.

FWIW, the intent behind Save-Data is to separate out the common intent from the "how". That is, there are many different mechanisms to deliver data reduction, and opt-in any one them is what Save-Data is all about... which is why it was proposed as a boolean. That said, I could be convinced that perhaps we should change it to a keyword (e.g. "on"), such that it can be extended (as a list) in the future.. For now, it would be:

- (no Save-Data header) -- user has not enabled any form of data savings mechanisms.

- Save-Data: on -- user has enabled some/any form of data savings mechanism.

If and when there is an explicit opt-out user preference for such features we could extend the above to include "off" state as well. Yay/nay?

SGTM. That way we're not trying to predict the future, nor blocking the signal's evolution.

[Ben Greenstein]

SGTM.

[Ilya Grigorik]

Spec update to switch Save-Data to token: https://github.com/igrigorik/http-client-hints/pull/63 - should be simple enough, but please sanity check.

[Chris Harrelson]

Is there any signal from other user agents about this feature?

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

[Ilya Grigorik]

On Fri, Oct 2, 2015 at 5:24 PM, Chris Harrelson <chri...@chromium.org> wrote:

Is there any signal from other user agents about this feature?

Yes, Opera is on board, which gives us coverage of two major proxy browsers. No signals from others.

[Ilya Grigorik]

Updated spec with "on" token instead of the boolean: http://igrigorik.github.io/http-client-hints/#the-save-data-hint

Any other feedback, or questions? Owners, what say ye? ;-)

[Philip Jägenstedt]

LGTM1! This isn't my area of expertise, but Jonny has confirmed that we (Opera) support this.

[Chris Harrelson]

LGTM2.

[Dimitri Glazkov]

LGTM3.

:DG<