After discussion with @Mike West <[email protected]> and @Mike Taylor <[email protected]> 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) On Wed, Mar 16, 2022 at 6:48 AM Ari Chivukula <[email protected]> wrote: > 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) > > > On Wed, Mar 16, 2022 at 6:46 AM Ari Chivukula <[email protected]> > wrote: > >> (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/CAGpy5D%2Bu_xMVWKbjNGzLA1Jk8PH%2BY69TR8kr3ODH1qpNGy6Log%40mail.gmail.com.
