(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) On Wed, Mar 16, 2022 at 1:29 AM Mike West <[email protected]> wrote: > 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/CAGpy5DKdPf-N-dZvKZFd%2BGsRBaL_sFHqYG891FCZbpM0Eko2yA%40mail.gmail.com.
