Overall I like this. Having this available at the network level seems great.

I do continue to be worried about the design of Client Hints overall; not having this information in the intial request hobbles what servers can reasonably do, inducing the to cookie users or create redirects for the purposes of just getting this information.

@slightlyoff "anything you should be able to see at the network level that is not security sensitive should be reflected back to page content - you should not have to go through round-trips. Same data is being sent through client hints header. This tells javascript code the same thing the server could have learned. So :+1:"

It's a little worrying that http://httpwg.org/http-extensions/client-hints.html#save-data and https://wicg.github.io/netinfo/#-dfn-savedata-dfn-attribute seem to be specifying the same material. (Or are they?) Seems like one spec should be canonical for each thing -- but if the save data features are split between two specs they should definitely point to each other clearly.

Some concerns from @cynthia on privacy considerations.

@dbaron we moved Save-Data header definition from IETF doc into NetInfo spec in recent update. New IETF draft hasn't been published yet, hence the duplication.. but that won't be the case soon.

Some discussion on this on today's call.

Agreed to discuss at f2f and hopefully we can get you on the phone for that discussion @igrigorik. Will be Jan 31 - Feb 2 (London).

Will this property be exposed to CSS media queries? I'd love to be able to do:

<picture>
    <source type="image/webp" srcset="/img-low-quality.webp" media="(save-data: on)">
    <source type="image/webp" srcset="/img.webp">
    <img src="/img.jpg">
</picture>

Discussed at London F2F day 3.

TAG review comments:

• Fingerprinting potential by correlating patterns of savedata status across multiple origins (ie I will exhibit the same pattern of moving from good to poor service areas on all websites I am visiting over the same period)
  • Meta-point: dynamic hint variables can provide trackable profiles when monitored over time.
  • -> Seems to be addressed in privacy section of the spec
• Not clear whether this is informed by exactly the same data source as the CH header, and we feel they should be the same spec if they are the same thing.
  • Seems it is now the same spec, see https://github.com/w3ctag/design-reviews/issues/204#issuecomment-349715274

TAG review conclusion:

• Fingerprinting issues are still a source of concern, even given the text in the spec. We note that the WebRTC vulnerability identified in the spec has been fixed following previous TAG feedback to that group.
• Some TAG members take the view that the considerations given to privacy are not adequate and that the group should consider further work on mitigating the fingerprinting potential, but we do not have consensus on this.

@davidmurdoch

Will this property be exposed to CSS media queries

There is a proposal in https://github.com/w3c/csswg-drafts/issues/2370.