Is this shipping in 102? On Wednesday, April 6, 2022 at 8:17:09 AM UTC-7 Daniel Bratell wrote:
> LGTM3 > > /Daniel > On 2022-03-30 18:03, Chris Harrelson wrote: > > 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> After discussion with @Mike West and @Mike Taylor 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 >> >> <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 [email protected]. > > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-DmDrYL_JuH5JPmQcwV8hSUOxH27HcFszP4kZ4tBzAQw%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/dc035144-4339-4f87-974c-e27589114622n%40chromium.org.
