1126187 - Fingerprinting via IP address

Status: RESOLVED DUPLICATE of bug 959893

(Core :: WebRTC: Networking, defect)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

Not sure what we can do about this, but figured I'd drop it somewhere those with more know how could find:

"Firefox and Chrome have implemented WebRTC that allow requests to STUN servers be made that will return the local and public IP addresses for the user. These request results are available to javascript, so you can now obtain a users local and public IP addresses in javascript. This demo is an example implementation of that.

Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery. _____This makes these types of requests available for online tracking if an advertiser sets up a STUN server with a wildcard domain._____"

[0] https://github.com/diafygi/webrtc-ips#what-this-does

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Browser extensions for enhancing privacy for those that want (especially VPN users) are certainly welcome (and I imagine are in Chrome as well).

Comment 2

[Eric Rescorla (:ekr)]

This is a good point about STUN (and you could do other stuff with TURN).

CCing MMC so she has context for tracking protection.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

We could reopen and cleanly target this at just the STUN plugin/console/etc issue

Comment 4

[[:mmc] Monica Chew (no longer reading bugmail)]

What would it take for STUN requests to respect nsIContentPolicy.shouldLoad, which is what ABP, etc. use for blocking connections? Seems like if an ad network wants to set up a stun server to abuse this API, we should provide a way to block it.

The console issue seems like an obvious feature request -- but mostly for warning webrtc developers when requests aren't reaching the right endpoint.

Comment 5

[Eric Rescorla (:ekr)]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #4)
> What would it take for STUN requests to respect nsIContentPolicy.shouldLoad,
> which is what ABP, etc. use for blocking connections? Seems like if an ad
> network wants to set up a stun server to abuse this API, we should provide a
> way to block it.


I agree. Are the entries there IP addresses, domain names, or both?



> The console issue seems like an obvious feature request -- but mostly for
> warning webrtc developers when requests aren't reaching the right endpoint.