search

WICG / netinfo

https://wicg.github.io/netinfo/
Other
95 stars 28 forks source link

Tighten network quality estimates for improved privacy #64

Open tarunban opened 6 years ago

tarunban commented 6 years ago

Three changes have been suggested in the network quality exposed via JS API. The goal here is to reduce the chances for cross-origin fingerprinting:

  1. Up to 10% random noise should be added to the network quality estimates before exposing it via Javascript API. The noise should be a function of the hostname, and the noise should remain constant for a given hostname.

  2. The current bucket size in the network quality estimates is 25 msec (for RTT) and 25 Kbps (for downlink). This means currently the estimate is rounded off to the nearest 25 msec or 25 kbps before exposing it via JS API. The bucket size can be updated to 50 msec / 50 kbps.

  3. The upper limit on the estimates should be added. For RTT, the upper limit can be 3000 msec, and for kbps it can be 10000 kbps.

Melatonin64 commented 6 years ago

I understand that there are security concerns with exposing these properties, but setting an upper limit on navigator.connection.downlink might be excessive. It renders that property useless for some use cases (or at least much less useful). An example of such a use case would be adaptive video streaming. Let's say I'm implementing a client-side DASH video player. Instead of starting playback with some default video quality and adjusting as we go, I could use the navigator.connection.downlink property to start with the most appropriate representation.

Nowadays, when gigabit internet connections are available to consumers, 4K video resolutions (and above) are gaining popularity and the NetworkInfo API is no longer only available on mobile devices, it makes little sense to limit this value to 10 Mbps.

Will imposing a lower limit on kbps instead help to improve privacy? Seems to me this would be analogous to the upper limit on RTT...

Please consider removing the upper kbps limit (or at least increasing its value to keep with the times).

jkarlin commented 6 years ago

Can you explain a bit more what you mean by cross-origin fingerprinting? Also, which hostname are you referring to in step 1? The hostname of the document making the NetInfo call?

tarunban commented 6 years ago

Can you explain a bit more what you mean by cross-origin fingerprinting?

The main concern was that two different origins may be able to correlate fetches from a single user (i.e., determine if the two fetches come from the same user). @msramek touched upon this a bit in this comment.

Also, which hostname are you referring to in step 1? The hostname of the document making the NetInfo call?

The hostname of the origin which is running the JavaScript.