WebRTC leaks internal addresses even when camera/mic permissions are not granted
Categories
(Core :: WebRTC: Networking, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox62 | --- | affected |
People
(Reporter: gcp, Unassigned, NeedInfo)
References
Details
(Whiteboard: [fingerprinting][fp-triaged])
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
Reporter | ||
Comment 3•6 years ago
|
||
Reporter | ||
Comment 4•6 years ago
|
||
Reporter | ||
Comment 5•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 6•5 years ago
|
||
Is there a way to make the mode selected, operate like any other normal permission dialog (Location, Notifications, Autoplay, etc)?
To me this seems like a pretty high-level question that users should understand:
"The website <xxx.yyy.zzz> is requesting access to private network devices. Would you like to grant it access?"
[ ] Remember my decision every time i visit this site.
Yes | No
Once they press 'Yes', do something like reload the page, or if possible, provide the delta between whichever modes you're switching between via the Javascript API (akin to a user plugging/unplugging network interfaces, from Javascript's standpoint). "Network" could then be one of the normal permissions that each website is allowed to get access to by using, just like Location, Notification, etc.
That way at least people can be made aware of all the abuse that WebRTC is probably getting in the wild for fingerprinting, but also provides an education path for the kind of physical access it opens up.
Even with an approach like this, Mozilla can pick whatever defaults it needs to comply with spec for such a "Network" permission (e.g. "always enable") -- and should default to whatever provides the least tension for any kind of express route that majority of users will fall into, while balancing those needs against more privacy-conscious folks.
Another place for inspiration: Autoplay permissions has a "Default for all sites" drop-down in their permissions section for sites that the user has not added exceptions, with 3 separate options in it. This seems like the kind of place to put Mozilla's choices for defaults on "Network Access" for selecting outcomes that line up with Mode 1, Mode 2, and Mode 3. They shouldn't make such an option implied via Mic/Video confirmations if it's doing MORE than just granting access to Mic/Video, and Firefox really should not be interpreting other permissions like Mic/Video to literally mean "Network Access", when there is nothing about that implied! (That is, unless you'd be doing Mic/Video permissions checks in addition to network permissions checks).
I think the concerns of privacy advocates is that, from a fingerprinting standpoint , the lack of even being able to express such a per-site configuration makes working with WebRTC a nightmare, because the privacy advocates are always forced to enable/disable webrtc for the entire browser in about:config
to avoid leaking private IPs -- even if there are individual sites (like sharedrop) that they've elected to trust. Or other privacy folks are outright confused, and they're turning to addons like uBlock because we've done a poor job disambiguating these.
WebRTC spec mentions UA prompts, but doesn't really elaborate on how you can turn what seems like an obvious bug that caused a fair bit of outrage some years ago into a really elegant feature.
Comment 7•5 years ago
|
||
A couple terms to clear this up. I believe this is everything the public would see (please correct me if I'm wrong)...
"Default for all websites:"
Mode | JS API | Phrasing |
---|---|---|
1 | "all" | Enable Network Access |
2 | "public" | Enable Network Access on Default Connections only |
3 | "relay" | Disable Network Access |
(The effect of mode 3 quite genuinely seems to mean 'private network access is disabled', because as far as I understand, only relay servers will work in that mode, so no fingerprinting or private network access occurs)
Combinations:
Default Mode | New Website requests Permission | Popup |
---|---|---|
1 | 1 | No |
1 | 2 | No |
1 | 3 | No |
2 | 1 | Yes |
2 | 2 | No |
2 | 3 | No |
3 | 1 | Yes |
3 | 2 | Yes |
3 | 3 | No |
My anticipation is that Mozilla would pick Default Mode = 2
, because that's consistent with what they're trying to get to.
Effect of such a default with no exception would be:
-Websites that intentionally specify Mode 1 (aka "all") will see a popup.
-Websites that intentionally specify Mode 2 (aka "public") will not see a popup.
-Websites that intentionally specify Mode 3 (aka "relay") will not see a popup.
-Websites that accidentally don't specify a mode in their WebRTC usage will still see a popup, because JS defines default to "all".
The combination of Mode 2 as a browser default, and the JS api (when unspecified) left as Mode 1, would cause more popups is precisely what makes this awkward, but it seems to suggest that we would need either a "learning phase" for the Internet to adjust the privacy mess they've made, or another option to help the browser disambiguate what "all" means:
all The ICE agent may use any type of candidates when this value is specified.
^^ The wording here does not seem to say that "all are required", but more that "all are unspecified".
If we add "Block new requests for website access requests" in the Network Tab, and set it to checked by default, does that mean we can block ALL popups by default, AND have the default max mode, and just lock everything to mode max mode 2?
Alternatively you'd probably have to improvise some kind of new option, like a "Block new requests for website access requests meeting criteria ______".
Comment 8•3 years ago
|
||
Is the initial or any remaining issue still present? Initially I planned to reply to bug #959893 comment #161 but the ticket is restricted and this referenced ticket seems to be suitable too to evaluate the current state. Around 2.5 years ago when I tested if my local IPv4 address can be leaked on websites for fingerprinting it succeeded which caused me to disable WebRTC via media.peerconnection.enabled=false to avoid the leakage. Yesterday I created a new firefox profile and evaluated all settings especially in terms of privacy/security and not a single website I did tests on was able to detect my local IPv4 address anymore when WebRTC was enabled thus making this issue seemingly not a threat at all anymore.
The question is now: Is that really true? It would be quite nice if one has not to bother anymore to disable WebRTC for maximum privacy or are there still edge-cases that could leak something unwanted and thus disabling WebRTC could be still an option? Or did all issues just resolve over time and this ticket (and eventually bug #959893 ) can be closed?
Comment 9•3 years ago
|
||
I guess it is worth throwing a NI here for comment #8 as things seems to be unclear here and in the referenced ticket.
For bug #959893 it depends on the meta-ticket bug #1189167 which has as only open dependency bug #1189036 with no activity for ~6 years. Is this last ticket still relevant for the term "Internal IP Address Leakage" today or is this topic now mainly handled and if so does it solve this ticket here as well?
Updated•2 years ago
|
Description
•