[webkit-dev] Intent to Ship: Add Save Data Client Hint

[Ari Chivukula]

Contact emails

ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org

Design Doc

https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit

Specification

https://wicg.github.io/savedata/

https://wicg.github.io/client-hints-infrastructure/

Summary

The Sec-CH-Save-Data client hint indicates whether the user agent intends to reduce data usage. It will be sent by default on all requests unless the permissions policy says otherwise.

 

For example, one could limit delegation of this hint via HTTP headers:

Permissions-Policy: ch-save-data=(self, https://bar.com/)

 

Or, one could limit delegation of this hint via an HTML meta tag:

<meta name="Accept-CH" content="sec-ch-save-data=(https://bar.com/)">

 

Example of new HTTP header when Data Saver is on:

Sec-CH-Save-Data: ?1

 

Example of new HTTP header when Data Saver is off:

Sec-CH-Save-Data: ?0

 

Explicitly requesting Sec-CH-Save-Data or modifying the CH-Save-Data permissions policy will prevent the old `Save-Data` header from being sent. Otherwise, the old header will not be affected.

 

Blink component

Blink>Network>ClientHints

 

Motivation

The current `Save-Data` header is sent when a browser or operating system data saver setting is on (e.g., Lite mode) for all first and third party requests, lives outside the client hints system, and is named improperly. `Sec-CH-Save-Data` will be a proper client hint and its delegation to third parties could be prevented via permissions policies.

TAG review

N/A (No new data is exposed that wasn't before)

Compatibility

The `Save-Data` header will not be removed, so adoption of `Sec-CH-Save-Data` is optional.

 

Interoperability

Gecko: Client Hints not yet implemented (considered non-harmful)

WebKit: Client Hints not yet implemented

Web developers: No feedback yet

Debuggability

N/A

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

Not yet, but it will be. `Save-Data` tests are here.

Tracking bug

https://crbug.com/1293443

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5645928215085056

[Ari Chivukula]

Fixing the subject prefix, apologies.

[Ari Chivukula]

Sorry for not including timeline info. The plan is:

M102 will include the new Sec-CH-Save-Data header.

No plan to remove the legacy Save-Data header at this moment.

[Mike West]

Hey Avi!

Two questions, one small, one large:

First, to reduce header bloat, the approach of not sending headers by default whose value is `?0` seems reasonable. Fetch Metadata's `Sec-Fetch-User` header is a good example of this. Can you help me understand why that's not the right thing to do here?

Second, and more fundamentally, if we're not planning to remove `Save-Data`, adding this header doesn't make much sense to me. We'll be adding this new header to every request alongside `Save-Data`, with the same value as `Save-Data`. That feels purely duplicative. Can you help me understand the value? (If integration with permission policy is valuable (and I can understand how it could be!), did you consider carving out a naming exception for this header, and applying the policy control to the `Save-Data` header? It seems like we'd have to do that anyway in order for the policy control to have any meaning.)

-mike

--
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/CAGpy5DLyhJURaZAKrogjcs0QEMV0-3JM0_onQOP-GjBVY2gkXQ%40mail.gmail.com.

[Ari Chivukula]

(1) Can we omit the header when the value would be `?0` (false)?

I'm fine with that, and it would be worth updating the existing client hint standard to allow the conflation of empty/missing values in cases where headers are sent by default. It's not worth the bytes to clarify the header is empty, especially when it's about saving data :-P

(2) Why add this new name if we have the existing header? Can't we just have the permission policy apply to the old name?

Chrome on Android is removing 'lite mode', which is the only case I'm aware of which causes `Save-Data: on` to be sent. We have a chance here to add the new name and policy, then follow up with a removal of the old name while it's not even being sent. The removal isn't a part of this intent, but in any case where `Sec-CH-Save-Data` is explicitly requested or the `CH-Save-Data` policy is touched the old `Save-Data` header wouldn't be sent at all under this intent.

~ Ari Chivukula (Their/There/They're)

[Mike West]

On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula <ari...@chromium.org> wrote:

(1) Can we omit the header when the value would be `?0` (false)?

I'm fine with that, and it would be worth updating the existing client hint standard to allow the conflation of empty/missing values in cases where headers are sent by default. It's not worth the bytes to clarify the header is empty, especially when it's about saving data :-P

SGTM. That seems like a reasonable pattern to document: I filed https://github.com/WICG/client-hints-infrastructure/issues/99.

(2) Why add this new name if we have the existing header? Can't we just have the permission policy apply to the old name?

Chrome on Android is removing 'lite mode', which is the only case I'm aware of which causes `Save-Data: on` to be sent. We have a chance here to add the new name and policy, then follow up with a removal of the old name while it's not even being sent. The removal isn't a part of this intent, but in any case where `Sec-CH-Save-Data` is explicitly requested or the `CH-Save-Data` policy is touched the old `Save-Data` header wouldn't be sent at all under this intent.

Hrm. This sounds quite different from what was in the original intent. :) Two followups, if you don't mind:

1.  Does this intent also introduce a new triggering mechanism which would cause the header to be sent? My assumption was that we'd be basing this on the user's "lite mode" choice. If we're removing that, what's left?

2.  If you're additionally planning to change `Save-Data`'s behavior to make it subject to the `CH-Save-Data` policy, then it seems like the only advantage of introducing a new header is naming consistency with other client hints. Have y'all done any analysis to determine how many sites rely upon the current spelling of the header to change user-facing behavior? It seems like there might be strong reliance interests here, given the header's long tenure.

-mike

[Ari Chivukula]

(1) There's a thought to pipe OS-level data saver settings into (Sec-CH-)Save-Data, but this work is not underway as far as I know.

(2) We're not making `Save-Data` subject to `Sec-CH-Save-Data`'s permissions policy (`CH-Save-Data`). What I'm saying is that "explicitly requesting Sec-CH-Save-Data or modifying the CH-Save-Data permissions policy will prevent the old `Save-Data` header from being sent."

~ Ari Chivukula (Their/There/They're)

[Ari Chivukula]

As for usage, it's hard to gauge because it's sent by default when Android Lite Mode is on. We're betting on the limited cases in which it's ever sent going to zero (with the removal of Android Lite Mode) to facilitate this.

~ Ari Chivukula (Their/There/They're)

[Ari Chivukula]

After discussion with @Mike West and @Mike Taylor the direction is being changed, and the new approach is:

(1) Keep the existing Save-Data header name

(2) Keep the existing Save-Data value (`on` instead of `?1`)

(3) Keep the existing Save-Data delegation by default to first and third parties

(4) Keep the existing omission of Save-Data when the value sent would be the empty string

(5) Add a new permissions policy, CH-Save-Data, which allows Save-Data delegation to be restricted if desired

https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit

https://github.com/WICG/savedata/pull/5

https://github.com/WICG/client-hints-infrastructure/pull/101

We can revisit re-naming in the future if desired, after this is launched.

~ Ari Chivukula (Their/There/They're)

[Mike West]

LGTM1.

This approach seems like a pretty reasonable compromise to me, thanks for iterating on it a bit.

-mike

[Chris Harrelson]

LGTM2. Save-Data is already shipped (for a long time), and this seems like a step in the right direction, without introducing a new header.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcMW3X-tvQsHZT73%2BA-GaP6ssCvmaB%3DyBX8dpdgY%2BFC2A%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

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

[Joe Medley]

Is this shipping in 102?

[Ari Chivukula]

I'm aiming to meet that deadline, yes.

https://chromium-review.googlesource.com/c/chromium/src/+/3575367

~ Ari Chivukula (Their/There/They're)