add option to disable webrtc

[diracdeltas]

was reminded by electron/electron#4200

webrtc leaks private IP addresses, so tor browser disables it

[bbondy]

@BrendanEich need your call here

[diracdeltas]

either way, this is minor enough in the grand scheme of things to be 1.0 or later

[aakilfernandes]

@diracdeltas respectfully disagree. WebRTC is a major concern for anyone wishing to browse online without revealing their IP. This includes anyone accessing content banned in their country. Anyone who uses a vpn or tor proxy would not be able to use Brave safely.

[diracdeltas]

@aakilfernandes Yep, I'm well aware of that; by "minor" i mean compared to things like having a settings menu in the first place. Anyway, if electron/electron#4174 is resolved, I think this should be easy to do in 0.8 or 0.9.

[HLFH]

IMHO btw, uBlock Origin can prevent leakage of our non-internet-facing IP address without disabling WebRTC.

[weems]

Agreed, Settings Menu is much more important.

[diracdeltas]

I think this is mitigated by 35efd0e, which adds a permission prompt for the getting user media (deny by default). I'm not 100% sure this prevents internal IP leaks due to the way webrtc signaling works though.

[ghost]

The WebRTC case was not mitigated by 35efd0e (but the geolocation requests and everything else are, as expected).

Note that uBlock's WebRTC anti-leak is not perfect, most especially for browsers built around Chrome. Anyway, in the issues, some users are complaining about the fact it broke Firefox Hello or Hangouts and that they had to uncheck the option to be able to use it (and yes, you'll read things about "VPN-as-browser-extension" - wtf).

Maybe the whole WebRTC functionality should be disabled by default everywhere and prompting for permission on whitelisted domains (Hello, Hangouts...)? Or prompting for permission everywhere and allowing it on whitelisted domains?

[diracdeltas]

You're right, 35efd0e did not address this issue. Upstream electron/electron#4200 was closed because Electron added support for permission handlers, but webrtc does not trigger any permission requests yet, so this is still open.

[ghost]

I took a look and I can confirm that there is no PermissionType related to WebRTC (most especially STUN) in Chromium: I think the displayed popup asking for permission only spawns because WebRTC needs to use the micro and/or the webcam of the user. That's maybe why the issue on electron was closed.

One easy fix would be to create a checkbox in the settings (checked by default, I guess?) and use Ublock's method. A harder one would be to create this kind of permission inside libchromium. You choose :)

[diracdeltas]

@Nashe we can't use ublock's method directly, because they are just flipping a chrome-specific setting (https://developer.chrome.com/extensions/privacy#property-network webRTCIPHandlingPolicy ) which Electron doesn't support. if you figure out a way to expose that setting or equivalent in Brave, we can add it to the preferences page.

[diracdeltas]

discussed on slack. @bridiver to expose access to webrtc_ip_handling_policy in our Electron fork, and then I'll add a pref for this in Brave.

[bridiver]

what release is this scheduled for?

[diracdeltas]

@bridiver Currently unscheduled, but I see about one request for this per week on Twitter/Github. Is 0.9.3 feasible?

[bridiver]

sure

[IVXCVI]

Yes! Thanks everyone. Looking forward to the fix.

[taoeffect]

Brave 0.10.3

VPN off:

VPN on:

VPN switch:

Conclusions:

• Brave is the same as Firefox when VPN is on
• This time I noticed that when I switched on the VPN while staying on the page, it updated itself, almost as though "sorta refreshing", but still saw my real public IP, while also getting my VPN's local IP. I did not attempt to see if the other browsers had this behavior. A refresh of the page is what is shown in the "VPN enabled" screenshot.

I should add that both Brave and Chrome will, when not behind a firewall VPN, generate an outgoing connection on port 3478:

[diracdeltas]

@taoeffect without a VPN or any extensions, https://diafygi.github.io/webrtc-ips/ correctly identified both my public and local IP on both chrome stable and brave stable, which is what I was expecting. my goal is to fix this in the next release at least when fingerprinting protection is turned on.

[taoeffect]

@taoeffect without a VPN or any extensions, https://diafygi.github.io/webrtc-ips/ correctly identified both my public and local IP on both chrome stable and brave stable, which is what I was expecting. my goal is to fix this in the next release at least when fingerprinting protection is turned on.

Awesome! ??

Another thing possibly worth considering is to have it disabled by default, but prompt the user when a page uses WebRTC, similar to how browsers request permission for camera or location.

Also, apologies for the gigantic screenshots, that's OS X making them huge because of the retina display. It really should downsize them...

[--- Commented from Asana.com
#commenter brad richter
---[aa]

[fippo]

@taoeffect i've shown that a prompt is feasible on mozhacks last year -- and yet I could not get anyone (including myself) in the IETF WG to agree this solves the problem in any way.

@diracdeltas the paper you're quoting fails to acknowledge unlike when webrtc was first used for tracking the number of ip addresses returned has been somewhat reduced. The lack of a reference to the ip handling draft made me wonder if the authors are aware of this even (just look at this thread: the draft is highly relevant and wasn't part of the discussion until a few hours ago -- thanks @feross).
Given that most of the trackers seem to be copying the same crappy piece of code without understanding it I hope they haven't noticed it is broken.

If you want to stub things in a content script you might find this useful. Also for exposing sites that try to use WebRTC hoping you don't notice.

[diracdeltas]

@fippo Based on the tests that @taoeffect and I did above, combined with the fact that most people don't use VPNs/proxies regularly, I think the effectiveness of IP tracking methods has not significantly diminished. The paper is relevant (thanks @feross for pointing it out) but it explicitly doesn't consider non-proxy/VPN local IP leakage from behind a NAT to be a great concern; it does suggest user approval via a prompt but the major browsers haven't implemented this yet.

Thanks for the pointer to https://github.com/webrtcHacks/webrtcnotify, but I think we are going with the ublock method for now. Also if you want to stub out https://github.com/diafygi/webrtc-ips/pull/8/files, something like https://github.com/brave/browser-laptop/blob/master/app/extensions/brave/content/scripts/blockCanvasFingerprinting.js#L156 may work.

[feross]

@diracdeltas it does suggest user approval via a prompt but the major browsers haven't implemented this yet.

Are you referring to this quote from the spec? "Future versions of browsers may present an indicator to signify that the page is using WebRTC to set up a peer-to-peer connection."

I don't think any major browsers plan to implement user approval via an actual prompt. The spec refers to an indicator (like an icon) to show that webrtc is active. Since there is already user approval for webcam/mic access, a separate prompt for webrtc access would probably confuse most users.

@diracdeltas I think we are going with the ublock method for now

Am I right in interpreting this as "Mode 3" from draft-ietf-rtcweb-ip-handling-01?

Mode 3: Default route only: This is the the same as Mode 2, except
that the associated private address is not provided, which
may cause traffic to hairpin through a NAT, fall back to the
application TURN server, or fail altogether, with resulting
quality implications.

[diracdeltas]

Are you referring to this quote from the spec?

@feross I was referring to:

   When used with audio and video devices, WebRTC requires explicit
   user permission to access those devices.  We propose that this
   permission grant be expanded to include consent to allow WebRTC
   to access all IP addresses associated with the user agent, for
   the purpose of finding the absolute best route for media traffic.

Explicit user permission for audio/video devices in Chrome and Brave right now is granted via a non-modal notification prompt; I was imagining the same for IP access.

Am I right in interpreting this as "Mode 3" from draft-ietf-rtcweb-ip-handling-01?

I believe so. As mentioned above though, it'll be off by default to start and only enabled if the 'Fingerprinting Protection Mode' is on.

[feross]

@diracdeltas Thanks for explaining. That sounds very reasonable.

Just to clarify one last point: I'm pretty sure that "We propose that this permission grant be expanded to include consent to allow WebRTC to access all IP addresses associated with the user agent" just refers to re-wording the webcam/mic prompt to mention IP addresses. I don't believe there are plans to prompt for local IP addresses when WebRTC data channel is used, for instance.

The spec says:

We recommend Mode 1 as the default behavior only if cam/mic permission has been granted, or Mode 2 if this is not the case.

I believe this is what Chrome and Firefox currently do.

[juberti]

Yes, Chrome has Mode 2 on by default, and uses Mode 1 when gUM permission is granted.

As @feross mentions, the study was done before this change was made, and I believe that Mode 2 makes a significant difference in reducing the fingerprinting surface, which should reduce the frequency of this technique in the wild.

Regardless, Mode 3 seems like a reasonable approach for the special minimal fingerprinting mode, as discussed in rtcweb-ip-handling:

Users who prefer Mode 3 or 4 should be able to select a preference or
install an extension to force their browser to operate in the
specified mode.

[diracdeltas]

I did some testing and it appears that with Tor as my system SOCKS proxy on OS X, both Brave and Chrome 51.0.2704.103 leak true public/private IP address on https://diafygi.github.io/webrtc-ips/. So I am going to tie fingerprinting protection to the disable_non_proxied_udp setting, since default_public_interface_only apparently reveals the true public IP.

[juberti]

Sure. There is a performance penalty for disable_non_proxied_udp, so one could imagine a future hybrid setting that was Mode 4 by default, but a less restrictive mode if gUM permission is granted.

[luixxiul]

Does this mean that WebRTC is not blocked? Tested on 0.11.0.

[diracdeltas]

@luixxiul good catch, looks like webrtc blocking is broken in the 0.11.0 release but works on master. cc @bbondy @bridiver

[diracdeltas]

turns out webrtc fingerprinting was accidentally never merged into the release branch. added it to the manual tests so it will definitely be in the next release.