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.
On Wed, Mar 30, 2022 at 5:49 AM Mike West <mk...@chromium.org> wrote: > LGTM1. > > This approach seems like a pretty reasonable compromise to me, thanks for > iterating on it a bit. > > -mike > > > On Thu, Mar 24, 2022 at 8:59 PM Ari Chivukula <aric...@chromium.org> > wrote: > >> After discussion with @Mike West <mk...@chromium.org> and @Mike Taylor >> <miketa...@chromium.org> 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 <aric...@chromium.org> >> 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 <aric...@chromium.org> >>> 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 <mk...@chromium.org> wrote: >>>> >>>>> On Tue, Mar 15, 2022 at 7:57 PM Ari Chivukula <aric...@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 (Their/There/They're) >>>>>> >>>>>> >>>>>> On Tue, Mar 15, 2022 at 11:05 AM Mike West <mk...@chromium.org> >>>>>> 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 <aric...@chromium.org> >>>>>>> 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 <aric...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Fixing the subject prefix, apologies. >>>>>>>>> >>>>>>>>> On Mon, Mar 7, 2022 at 7:55 AM Ari Chivukula <aric...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Contact emails >>>>>>>>>> >>>>>>>>>> aric...@chromium.org, jadekess...@chromium.org, >>>>>>>>>> miketa...@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 >>>>>>>>>> <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 blink-dev+unsubscr...@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 >>>>>>>> <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 blink-dev+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcMW3X-tvQsHZT73%2BA-GaP6ssCvmaB%3DyBX8dpdgY%2BFC2A%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 blink-dev+unsubscr...@chromium.org. 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.
