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:
Example of new HTTP header when Data Saver is off:
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.
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.
N/A (No new data is exposed that wasn't before)
The `Save-Data` header will not be removed, so adoption of `Sec-CH-Save-Data` is optional.
Gecko: Client Hints not yet implemented (considered non-harmful)
WebKit: Client Hints not yet implemented
Web developers: No feedback yet
Is this feature fully tested by web-platform-tests?
Not yet, but it will be. `Save-Data` tests are here.
Link to entry on the Chrome Platform Status
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.
(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.
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.
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.