Browser-laptop: add option to disable webrtc

[diracdeltas]

was reminded by https://github.com/atom/electron/issues/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 https://github.com/atom/electron/issues/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 35efd0ecdcaf98deee1d29c1a319fbbfe04a0c59, 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 https://github.com/atom/electron/issues/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.

[bbondy]

Moving to 0.10.1

[bbondy]

Seen about 8 requests for this in support.

[Szalacinski]

Any updates on this? This is the only thing that is keeping me from switching over to Brave as my full-time browser.

[diracdeltas]

Any updates on this? This is the only thing that is keeping me from switching over to Brave as my full-time browser.

if @bridiver thinks this is not going to be available by 0.10.5, i can probably stub webrtc in the fingerprinting block content script

[bridiver]

I should be able to get to it today when I finish the updating electron to 1.2.2

[bridiver]

support in electron added here: https://github.com/brave/electron/commit/2edb333e376b464d3cc7e4ec29a771f3067929c6

[feross]

Is the goal just to prevent users being fingerprinted by malicious websites? The thing is that the browser already contains hundreds of ways to do this -- and I don't think Brave plans to prevent them all -- listing all fonts, screen resolution, detecting number of cores, etc. etc.

I believe that Chromium has already fixed the issue where a VPN user's real IP address could be exposed. See this spec: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01

Here's the problem statement:

The information revealed falls into three categories:

(1) If the client is behind a NAT, the client's private IP
addresses, typically RFC 1918 addresses, can be learned.

(2) If the client tries to hide its physical location through a VPN,
and the VPN and local OS supports routing over multiple
interfaces, WebRTC will discover the public address associated
with both the VPN as well as the ISP public address over that
the VPN runs over.

(3) If the client is behind a proxy, but direct access to the
Internet is also supported, WebRTC's STUN checks will bypass the
proxy and reveal the public address of the client.

Of these three concerns, #2 is the most significant concern, since
for some users, the purpose of using a VPN is for anonymity.
However, different VPN users will have different needs, and some VPN
users (e.g. corporate VPN users) may in fact prefer WebRTC to send
media traffic directly, i.e. not through the VPN.

Here's the solution:

By default, WebRTC should follow the route for HTTP traffic, when
this is easy to determine (i.e. not considering proxies). This is
accomplished by binding local sockets to the "any" addresses
(0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route
WebRTC traffic the same way as normal HTTP traffic, and allows
only the 'typical' public addresses to be discovered.

Since the default route is used, the gathered IP address should be the same as the VPN route's. At least, that's how I understand it.

[feross]

From the same spec:

Based on these ideas, we define four modes of WebRTC behavior,
reflecting different privacy/media tradeoffs:

Mode 1 Enumerate all addresses: WebRTC will bind to all interfaces
individually and use them all to ping STUN servers or peers.
This will converge on the best media path, and is ideal when
media performance is the highest priority, but it discloses
the most information. As such, this should only be performed
when the user has explicitly given consent for local media
access, as indicated in design idea #3 above.

Mode 2 Default route + the single associated local address: By
binding solely to the "any" address, media packets will flow
through the same route as normal HTTP traffic. In addition,
the associated private address is discovered through
getsockname, as mentioned above. This ensures that direct
connections can still be established even when local media
access is not granted, e.g. for data channel applications.

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 NAT or fall back to the
application TURN server, with resulting quality implications.

Mode 4 Force TCP and proxy: This is disables any use of UDP and
forces use of TCP to connect to the TURN server or peer. If
a proxy server is configured, the TCP traffic will be sent
through the proxy, with resulting quality implications.

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.

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. For example, Chrome users can install the WebRTC
Network Limiter extension for this configuration.

It looks Mode 2 is the default for sites that are using WebRTC data channel (i.e. the user hasn't enabled webcam/mic access). But if the user does give webcam/mic access (which are considered more sensitive than IP address), then Mode 1 is used.

So, it seems there may be value for Brave users in ensuring that Mode 2 is always used -- or there's at least an option to enable that. That will let users use a webcam service over a VPN without revealing their real IP to the remote user.

[taoeffect]

OK, decided to dive down into this. Here's what I found.

Chrome 51.0.2704.63

VPN disabled:

VPN enabled:

Firefox 47

VPN disabled:

VPN enabled:

Conclusions:

• Both Firefox and Chrome do not seem to leak my public IP.
• Firefox leaks my local private IP

So I'm surprised that the problem seems to be (solved?) in Chrome, but then again I can't be 100% sure because:

• I may have tweaked some setting some time ago when I was investigating this
• One of my extensions may be "fixing" Chrome. I tried in Incognito mode where only (I think) HTTPS Everywhere and Ghostery were enabled.

[taoeffect]

Would be great if someone could try reproducing!

Here's the site I used: https://diafygi.github.io/webrtc-ips/

[diracdeltas]

Is the goal just to prevent users being fingerprinted by malicious websites? The thing is that the browser already contains hundreds of ways to do this -- and I don't think Brave plans to prevent them all -- listing all fonts, screen resolution, detecting number of cores, etc. etc.

Hi @feross, here's my writeup of Brave's fingerprinting defense goals: https://github.com/brave/browser-laptop/wiki/Fingerprinting-Protection-Mode

You're right that any modern browser's fingerprinting surface is already intractable and getting ever more complicated by new features. Therefore we prioritize the subset of fingerprinting attacks that have been detected in the wild, which does include webrtc fingerprinting. (Citation: http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf)

[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.