Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighten network quality estimates for improved privacy #64

Open
tarunban opened this issue Aug 16, 2017 · 3 comments
Open

Tighten network quality estimates for improved privacy #64

tarunban opened this issue Aug 16, 2017 · 3 comments

Comments

@tarunban
Copy link
Collaborator

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
Copy link

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
Copy link

jkarlin commented Oct 26, 2017

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants