W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2017

NetInfo privacy considerations

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Fri, 29 Sep 2017 14:00:22 -0700
Message-Id: <E53AE403-9112-46DF-A236-BC32F184DD48@ischool.berkeley.edu>
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
I believe there are experimental versions of the NetInfo API being deployed in Chrome. This JavaScript API provides script access to the local type of network connection, and some details about bandwidth, as well as events whenever those properties change.

https://wicg.github.io/netinfo/#privacy-considerations <https://wicg.github.io/netinfo/#privacy-considerations>
"above considerations are not new, and sufficiently motivated attackers may already obtain such information using other technologies"

I am frustrated by how often this kind of text is cropping up.

First, in this case (as in many of these cases), it doesn't seem to be accurate. WebRTC use of STUN to identify a private local IP address is given as an example of an API that provides insight into the local network, but obtaining RFC1918 IP address is very distinct from learning the local connection type and speed and getting events whenever they change, even when the user is explicitly using a VPN, Tor or other anonymizing proxy to hide that information from the endpoint server.

Second, it conflates an attack being possible and an attack being easy. Sophisticated timing attacks can certainly be impressive in learning various details, but in some cases these are research papers describing the potential to obtain a distinction between certain examples and not a widespread conclusion that extremely high-confidence network information can be detected in all environments. Also, detailed timing attacks may both require effort from the attacker and be more readily observable (issuing dozens of network requests at different times), where a standardized API will require no effort and distinguishing between an attacker and any other user of the API seems implausible.

Third, this seems to be creeping between specifications. If NetInfo claims that WebRTC allows local network information, and so we can expand to connection type and speed, and then HTTP Client Hints claims that it's nothing new to expose connection details in HTTP headers because it's available in NetInfo, we could find ourselves going from theoretical timing attacks to trivial passive communication of local network information, each time with the claim that nothing new is being added. (Recall this discussion from December: https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0060.html <https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0060.html>)

There is an open issue regarding changing the granularity of values for privacy purposes: https://github.com/WICG/netinfo/issues/64 <https://github.com/WICG/netinfo/issues/64>
I'm not sure what the right cutoff for those is. An alternative might be more high-level approaches, like disclosing if the network is metered-or-not or whether the client wants to save data or not.
And past discussion regarding fingerprinting and local network information disclosure: https://github.com/WICG/netinfo/issues/26 <https://github.com/WICG/netinfo/issues/26>

—Nick


Received on Friday, 29 September 2017 21:00:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 September 2017 21:00:50 UTC