On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula <[email protected]> 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 (Their/There/They're) > > > On Tue, Mar 15, 2022 at 11:05 AM Mike West <[email protected]> wrote: > >> 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 <https://www.w3.org/TR/fetch-metadata/#abstract-opdef-set-user> >> 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 >> >> >> On Wed, Mar 9, 2022 at 8:26 PM Ari Chivukula <[email protected]> >> wrote: >> >>> 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. >>> >>> >>> On Mon, Mar 7, 2022 at 7:57 AM Ari Chivukula <[email protected]> >>> wrote: >>> >>>> Fixing the subject prefix, apologies. >>>> >>>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula <[email protected]> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected] >>>>> >>>>> 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 >>>>> <https://wicg.github.io/client-hints-infrastructure/> 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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints> >>>>> >>>>> >>>>> >>>>> Motivation >>>>> >>>>> The current `Save-Data` header is sent when a browser or operating >>>>> system data saver setting is on (e.g., Lite mode >>>>> <https://support.google.com/chrome/answer/2392284?hl=en&co=GENIE.Platform%3DAndroid>) >>>>> for all first and third party requests, lives outside the client >>>>> hints system <https://wicg.github.io/client-hints-infrastructure/>, >>>>> and is named improperly >>>>> <https://docs.google.com/document/u/1/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit>. >>>>> `Sec-CH-Save-Data` will be a proper client hint and its delegation to >>>>> third >>>>> parties could be prevented via permissions policies >>>>> <https://wicg.github.io/client-hints-infrastructure/#policy-controlled-features> >>>>> . >>>>> >>>>> 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 >>>>> <https://mozilla.github.io/standards-positions/#http-client-hints>) >>>>> >>>>> 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 >>>>> <https://github.com/web-platform-tests/wpt/search?q=save-data>. >>>>> >>>>> Tracking bug >>>>> >>>>> https://crbug.com/1293443 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5645928215085056 >>>>> >>>>> -- >>> 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 [email protected]. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLyhJURaZAKrogjcs0QEMV0-3JM0_onQOP-GjBVY2gkXQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdV7cAr7%2BufafeBZzKEw9b4NCWSHv%2BCrmvz7CJCk7bjhQ%40mail.gmail.com.
