Network Information API reboot: request for early feedback
Hey WebKit folks, I have rebooted the Network Information API recently. This is all in a relatively early stage, but I thought now would be a good time to get your feedback on the proposal: - Motivational doc: https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQ... - Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md - Spec draft: https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html Here is the short version: ```js // Is the current network a metered network according to the OS-level setting // in, e.g., Android or Windows, i.e., _without_ the UA guesstimating it. The UA // may provide its own (override) setting, though: navigator.connection.metered; // false // What is the sustained connection speed, as measured on the OS-level (à la // `nettop`) for a sliding window and bucketed in buckets of exponentially // growing size in bit per second, e.g., 25,000,000 (25 Mbit/s), 50,000,000 // (50 Mbit/s). It's fine to report `Infinity` if the user agent doesn't want to // reveal more, or if the sustained speed isn't known yet. navigator.connection.metered; // 50000000 // Changes to either of the attributes are exposed via an event: navigator.connection.addEventListener("change", (event) => { console.log(event); }); ``` Each of the attributes is accompanied by a client hint header that reflects the attribute: ```bash Sec-CH-Metered-Connection: 1 Sec-CH-Sustained-Speed: 50000000 ``` Thanks in advance for your thoughts, here, or in the motivational document. Cheers, Tom
I don't think exposing the information about whether the connection is metered or not is acceptable from the privacy standpoint. Based on the IP address of a user & this metered status, a website may even be able to tell what kind of carrier plan a given user is in. - R. Niwa On Fri, Aug 20, 2021 at 7:51 AM Thomas Steiner via webkit-dev < webkit-dev@lists.webkit.org> wrote:
Hey WebKit folks,
I have rebooted the Network Information API recently. This is all in a relatively early stage, but I thought now would be a good time to get your feedback on the proposal:
- Motivational doc: https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQ... - Explainer: https://github.com/tomayac/netinfo/blob/relaunch/README.md - Spec draft: https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html
Here is the short version:
```js // Is the current network a metered network according to the OS-level setting // in, e.g., Android or Windows, i.e., _without_ the UA guesstimating it. The UA // may provide its own (override) setting, though: navigator.connection.metered; // false
// What is the sustained connection speed, as measured on the OS-level (à la // `nettop`) for a sliding window and bucketed in buckets of exponentially // growing size in bit per second, e.g., 25,000,000 (25 Mbit/s), 50,000,000 // (50 Mbit/s). It's fine to report `Infinity` if the user agent doesn't want to // reveal more, or if the sustained speed isn't known yet. navigator.connection.metered; // 50000000
// Changes to either of the attributes are exposed via an event: navigator.connection.addEventListener("change", (event) => { console.log(event); }); ```
Each of the attributes is accompanied by a client hint header that reflects the attribute:
```bash Sec-CH-Metered-Connection: 1 Sec-CH-Sustained-Speed: 50000000 ```
Thanks in advance for your thoughts, here, or in the motivational document.
Cheers, Tom _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
I don't think exposing the information about whether the connection is metered or not is acceptable from the privacy standpoint. Based on the IP address of a user & this metered status, a website may even be able to tell what kind of carrier plan a given user is in.
Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information.
On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner <tomac@google.com> wrote:
On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
I don't think exposing the information about whether the connection is metered or not is acceptable from the privacy standpoint. Based on the IP address of a user & this metered status, a website may even be able to tell what kind of carrier plan a given user is in.
Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information.
I don't think it's fair to characterize any given user telling the OS to reduce the data usage as a consent to be profiled by random websites. I would certainly not expect such information to be exposed to ad trackers and alike. You could make the same argument for turning on low power mode but battery level being low or having low power mode turned on may reveal the user's socioeconomic status or user's immediate need to take certain actions. It can lead to egregious consequences like this: https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery. I definitely would not want to be seeing ads promoting new SIM cards or ads for a cafe with free WiFi service nearby just because I requested my phone to reduce data usage. - R. Niwa
On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner <tomac@google.com> wrote:
On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
I don't think exposing the information about whether the connection is metered or not is acceptable from the privacy standpoint. Based on the IP address of a user & this metered status, a website may even be able to tell what kind of carrier plan a given user is in.
Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information.
I don't think it's fair to characterize any given user telling the OS to reduce the data usage as a consent to be profiled by random websites. I would certainly not expect such information to be exposed to ad trackers and alike.
Apple seems to see no issue in exposing this information to iOS/iPadOS apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.
You could make the same argument for turning on low power mode but battery level being low or having low power mode turned on may reveal the user's socioeconomic status or user's immediate need to take certain actions. It can lead to egregious consequences like this: https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery. I definitely would not want to be seeing ads promoting new SIM cards or ads for a cafe with free WiFi service nearby just because I requested my phone to reduce data usage.
Yes, bad things like that can happen, and the fact that companies like Uber make "evil" use of available information is no secret. At the same time, companies that make "good" use of information, like Algolia's example ( https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-clie...), hopefully outweigh the disadvantages. We don't prohibit hammers because they can be abused as a weapon. And again, the information is exposed to random native apps that can likewise profile you. I agree there is a difference between a random native app and a random website, but at the same time we have mitigations like third-party blocking (and ITP on Apple devices) that make such profiling harder and harder. Cheers, Tom
On Mon, Aug 30, 2021 at 2:58 AM Thomas Steiner <tomac@google.com> wrote:
On Mon, Aug 30, 2021 at 11:06 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
On Mon, Aug 30, 2021 at 1:17 AM Thomas Steiner <tomac@google.com> wrote:
On Sun, Aug 29, 2021 at 1:00 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
I don't think exposing the information about whether the connection is metered or not is acceptable from the privacy standpoint. Based on the IP address of a user & this metered status, a website may even be able to tell what kind of carrier plan a given user is in.
Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information.
I don't think it's fair to characterize any given user telling the OS to reduce the data usage as a consent to be profiled by random websites. I would certainly not expect such information to be exposed to ad trackers and alike.
Apple seems to see no issue in exposing this information to iOS/iPadOS apps: https://developer.apple.com/videos/play/wwdc2019/712/?time=959.
You could make the same argument for turning on low power mode but battery level being low or having low power mode turned on may reveal the user's socioeconomic status or user's immediate need to take certain actions. It can lead to egregious consequences like this: https://www.theverge.com/2016/5/20/11721890/uber-surge-pricing-low-battery. I definitely would not want to be seeing ads promoting new SIM cards or ads for a cafe with free WiFi service nearby just because I requested my phone to reduce data usage.
Yes, bad things like that can happen, and the fact that companies like Uber make "evil" use of available information is no secret. At the same time, companies that make "good" use of information, like Algolia's example ( https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-clie...), hopefully outweigh the disadvantages. We don't prohibit hammers because they can be abused as a weapon.
Please refer to https://www.w3.org/TR/design-principles/#safe-to-browse. It's not okay to add a new API which makes the web less safe & private for users just because the API can be used for good purposes. And again, the information is exposed to random native apps that can
likewise profile you. I agree there is a difference between a random native app and a random website, but at the same time we have mitigations like third-party blocking (and ITP on Apple devices) that make such profiling harder and harder.
The web and native apps have fundamentally different security & privacy models. We don't let websites access random files in your system without an explicit user consent. On Mon, Aug 30, 2021 at 6:54 AM Thomas Steiner <tomac@google.com> wrote:
None of this happens without the user voluntarily revealing the
information.
How would that possibly work? A new type of permission prompt? It's easy for users to decide whether a website should have geolocation or microphone access, but the risk here is just extra entropy, which is going to be real hard to explain to users.
The current thinking is that there would be no additional permission needed. Note that the proposal reduces the overall entropy compared to the current API, which exposes more information: https://wicg.github.io/netinfo/#networkinformation-interface (compared to https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinfor... ).
That's an API WebKit has never supported and never will for various privacy & security reasons. Also, I don't think the notion that this old API exposed more information is necessarily true. The user actively choosing to use low data mode is very much new information that websites couldn't necessarily infer from the old API. Overall, I don't think there is much left to discuss here. What you're proposing will introduce a serious privacy concern, and it's not acceptable. I'm going to stop replying to this thread going forward since I have other things to do but please note that my lack of future response does not, in any way, constitute a lack of signal or acceptance of an argument, idea, or amendment to the proposal. Apple's WebKit team is against this proposal like we were with the old API, and that's not going to change unless a substantial amendment is made to address all of the concerns we've raised thus far (as well as any new concerns we may raise in the future) for this proposal and the old API. - R. Niwa
I'm going to stop replying to this thread going forward since I have other things to do but please note that my lack of future response does not, in any way, constitute a lack of signal or acceptance of an argument, idea, or amendment to the proposal.
Apple's WebKit team is against this proposal like we were with the old API, and that's not going to change unless a substantial amendment is made to address all of the concerns we've raised thus far (as well as any new concerns we may raise in the future) for this proposal and the old API.
Thanks for the discussion and for taking a clear stance. I know you were going to stop replying, but so far you have only argued about the `metered` part of the proposal. Any word on the proposed `sustainedSpeed` attribute? One way a vendor could implement this API would be to always report `false` for `metered` (despite the actual value potentially being another) and still report connection speed data via `sustainedSpeed`. Cheers, Tom
(I noticed the spec preview link had gone stale. Please use https://raw.githack.com/tomayac/netinfo/relaunch/index.html instead.)
On Mon, Aug 30 2021 at 10:16:54 AM +0200, Thomas Steiner via webkit-dev <webkit-dev@lists.webkit.org> wrote:
Thanks for the reply, Ryosuke! Just to clarify, the `metered` attribute would be a manual user setting, not a browser heuristic. This means you could easily mark your all-data included WiFi at home as metered if you wanted to, or, on the opposite end, mark your roaming data plan you purchased for a ton of money at the airport as unmetered. None of this happens without the user voluntarily revealing the information.
Why would it be implemented as a manual setting in the browser, rather than a per-connection setting controlled by the OS? On Linux, NetworkManager already knows whether each network interface is metered or not. Users can override the choice in the unlikely event it guesses wrong. Why should a web browser offer a second level of override in addition to existing system settings? Are you planning to offer a browser-level override for every network interface separately, or just one single toggle that doesn't consider which network interface is in use? Michael
Why would it be implemented as a manual setting in the browser, rather than a per-connection setting controlled by the OS?
It’s exactly this, a per-connection setting controlled by the OS and reflected as is by the browser: https://github.com/tomayac/netinfo/blob/relaunch/README.md#metered-connectio... . Cheers, Tom -- Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac) Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.23 (GNU/Linux) iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. hTtPs://xKcd.cOm/1181/ -----END PGP SIGNATURE-----
OK, so you are using the existing OS-level network interface settings. At least on Linux, that is a heuristic-based per-interface setting with a manual override.
None of this happens without the user voluntarily revealing the information.
How would that possibly work? A new type of permission prompt? It's easy for users to decide whether a website should have geolocation or microphone access, but the risk here is just extra entropy, which is going to be real hard to explain to users. Michael
OK, so you are using the existing OS-level network interface settings. At least on Linux, that is a heuristic-based per-interface setting with a manual override.
That's great. It's an entirely manual setting on Android and Windows, but I imagine certain rules like "SSID is 'Android AP'" already would go a long way. The way this signal is obtained is not part of the proposal, the proposal barely focuses on reflecting what the OS provides. This does not mean browsers couldn't add an override, but it definitely does mean that the browser is in no way involved with guessing if the current network is metered or not.
None of this happens without the user voluntarily revealing the information.
How would that possibly work? A new type of permission prompt? It's easy for users to decide whether a website should have geolocation or microphone access, but the risk here is just extra entropy, which is going to be real hard to explain to users.
The current thinking is that there would be no additional permission needed. Note that the proposal reduces the overall entropy compared to the current API, which exposes more information: https://wicg.github.io/netinfo/#networkinformation-interface (compared to https://raw.githack.com/tomayac/netinfo/relaunch/index.html#the-networkinfor... ). Cheers, Tom
participants (3)
-
Michael Catanzaro
-
Ryosuke Niwa
-
Thomas Steiner