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

194 views
Skip to first unread message

Ari Chivukula

unread,
Mar 7, 2022, 10:56:09 AMMar 7
to blink-dev, Jade Kessler, Mike Taylor

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

unread,
Mar 7, 2022, 10:57:47 AMMar 7
to blink-dev, Jade Kessler, Mike Taylor
Fixing the subject prefix, apologies.

Ari Chivukula

unread,
Mar 9, 2022, 2:26:07 PMMar 9
to blink-dev, Jade Kessler, Mike Taylor
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

unread,
Mar 15, 2022, 2:05:53 PMMar 15
to Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor
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

unread,
Mar 15, 2022, 2:57:28 PMMar 15
to Mike West, blink-dev, Jade Kessler, Mike Taylor
(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

unread,
Mar 16, 2022, 4:29:18 AMMar 16
to Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor
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

unread,
Mar 16, 2022, 9:46:50 AMMar 16
to Mike West, blink-dev, Jade Kessler, Mike Taylor
(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

unread,
Mar 16, 2022, 9:49:50 AMMar 16
to Mike West, blink-dev, Jade Kessler, Mike Taylor
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

unread,
Mar 24, 2022, 3:59:48 PMMar 24
to Mike West, blink-dev, Jade Kessler, Mike Taylor
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


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

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

Mike West

unread,
Mar 30, 2022, 8:49:39 AMMar 30
to Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor
LGTM1.

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

-mike

Chris Harrelson

unread,
Mar 30, 2022, 12:03:19 PMMar 30
to Mike West, Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor
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.

Daniel Bratell

unread,
Apr 6, 2022, 11:17:09 AMApr 6
to Chris Harrelson, Mike West, Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor

Joe Medley

unread,
Apr 11, 2022, 1:30:32 PMApr 11
to blink-dev, Daniel Bratell, ari...@chromium.org, blink-dev, Jade Kessler, mike...@chromium.org, Chris Harrelson, mk...@chromium.org
Is this shipping in 102?

Ari Chivukula

unread,
Apr 11, 2022, 1:43:30 PMApr 11
to Joe Medley, blink-dev, Daniel Bratell, Jade Kessler, mike...@chromium.org, Chris Harrelson, mk...@chromium.org

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

Reply all
Reply to author
Forward
0 new messages