Re: [webrtc-stats] Exposing RTCIceCandidateStats.networkType might trigger fingerprinting

> This is already exposed for http://wicg.github.io/netinfo/, we should make sure that the stats document references it.

http://wicg.github.io/netinfo/ acknowledges that this API causes fingerprinting issues.
And it refers to WebRTC to state that this is already leaking elsewhere.
There would be a circular reference if WebRTC stats would refer to this API.
And the netinfo API is not as widely implemented/endorsed as WebRTC.

User agents that want to prevent fingerprinting in WebRTC will probably also want to prevent fingerprinting in netinfo.

Note also that VPN is not an option in netinfo, and some efforts have been made to prevent VPN detection through WebRTC.

> We have found `networkType` to be very helpful for diagnostics. (during a call and also afterwards). At least in the case for diagnostics, knowing if the user was on a WiFi helps a lot.

For diagnostics, couldn't you infer this in most cases by looking at:
- Network metrics like packet loss
- IP addresses, including private IP addresses if getUserMedia is granted

In general, the more expensive a fingerprinting method, the less attractive and used it will be.
Network info API/WebRTC stats are making it cheap to get this information.

> Not having done any study, I cannot say if the additional information helps with fingerprinting. Because, in several enterprises/homes, the ethernet and wifi work in the same address range. There are also situations when the networkType is wrong, because someone is tethering (for example: LTE over WiFi).

If the info is wrong enough to prevent fingerprinting, it should probably not be exposed as it might prevent good diagnostics.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/374#issuecomment-425710719 using your GitHub account

Received on Sunday, 30 September 2018 10:27:34 UTC