I'm aiming to meet that deadline, yes. https://chromium-review.googlesource.com/c/chromium/src/+/3575367
~ Ari Chivukula (Their/There/They're) On Mon, Apr 11, 2022 at 10:30 AM Joe Medley <[email protected]> wrote: > 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/CAGpy5D%2BNTis6r3tak6M9oSg-8EucL%3DtkZB9GX7hFj-arF1uBLQ%40mail.gmail.com.
