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 <[email protected]> wrote: > 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/CAKXHy%3DcMW3X-tvQsHZT73%2BA-GaP6ssCvmaB%3DyBX8dpdgY%2BFC2A%40mail.gmail.com.
