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
<mailto:mk...@chromium.org> and @Mike Taylor
<mailto: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
<mailto:aric...@chromium.org>,
jadekess...@chromium.org
<mailto:jadekess...@chromium.org>,
miketa...@chromium.org
<mailto:miketa...@chromium.org>
Design Doc
https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit
<https://docs.google.com/document/d/1sRYGWL2H_qFQamffUbojBiQdbJ1uAmptr3F_jjx5VSI/edit>
Specification
https://wicg.github.io/savedata/
<https://wicg.github.io/savedata/>
https://wicg.github.io/client-hints-infrastructure/
<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/
<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 willprevent 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
<https://crbug.com/1293443>
Link to entry on the Chrome
Platform Status
https://chromestatus.com/feature/5645928215085056
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-DmDrYL_JuH5JPmQcwV8hSUOxH27HcFszP4kZ4tBzAQw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
