New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 59 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Jul 2015
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Feature

Sign in to add a comment

Creating an option to directly control multiple routes for WebRTC

Reported by, Feb 11 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

Steps to reproduce the problem:
1. Visit or
2. See your real IP even though you may be behind VPN or other corporate security firewalls

What is the expected behavior?
I would expect to go into chrome settings and disable webrtc (any other plugins that come with chrome) so that there will be no ip leakage.

What went wrong?
I use my corporate VPN and I would like to continue using chrome; however, with this new webrtc thing, websites that use such script can see my real IP which is not secure for us. I would kindly ask the developers to give us options to disable such thing.

Did this work before? N/A 

Chrome version: <Copy from: 'about:version'>  Channel: stable
OS Version: 40
Flash Version: 

Copying from my forum post:

Due to my line of work (international exchanges), I have to use my corporate vpn and I don't want anyone to see our original IP to prevent any scans/attacks etc. However, with the latest chrome updates, it is impossible to block webrtc which reveals the real IP address!

The extension option: there is this webrtcblock extension for chrome but it does not work anymore (see Some people suggest using that scriptsafe extension but it's terrible. If you use that scriptsafe then it blocks all scripts from all sites and you end up "allow"ing or "trust"ing all the sites to see their basic content like catpcha modules - this totally negates what the extension was trying to do in the first place. With that extension, I can't even view the developer's own website!

Try another browser option: I do not want to use firefox or others. Tried it, done that, moved on.

The question is: are you (Google Chrome developers) working on an update that will allow people like me to disable webrtc?

Labels: Cr-Blink-Webrtc-Network
Status: Untriaged
Marking as 'Untriaged' as this is a 'New Feature' request.

Thank you!
I too have this problem. Using Toshiba Chromebook 2 With 41.0.2272.65 (Official Build) beta. Installed ZenMate VPN from web store. Also installed WebRTC block from web store. WebRTC still leaked ISP's IP address. Also disabled WebRTC flags and still leaked. I am a Chrome Help Forum support RS.
Status: fixed
This is a dup to 333752 which has been fixed in M42.  Please see that bug for details.
Mergedinto: 333752
Status: Duplicate
> This is a dup to 333752 which has been fixed in M42.  Please see that bug for details.

The OP's concern has not been addressed in 333752.

My understanding is that 333752 provided a custom option to force traffic through VPN. That doesn't address this issue for multiple reasons:

1. OP asked for a setting in "chrome settings", not an invisible option.
2. OP asked to be able to disable WebRTC. This has not been offered here or in 333752.

Please unmark this as "fixed" or "duplicate".
Is the goal here to block webrtc or to prevent IP leak? 

333752's solution will ensure the same IP you used for http traffic is also used for webrtc, so no more IP leak.

If the goal is to disable webrtc for the concern other than IP leak, could you explain what the concern is?

I understand changing the preference is not the easiest way to do and we have  to address that. Let me dig out more info and post it here.
> Is the goal here to block webrtc or to prevent IP leak? 

Excellent way to frame this. For me personally (and I suspect the same for OP), it's to prevent IP leak.

As you acknowledge, preventing the IP leak, even with the suggested preference addition from  Issue 333752 , is not something ordinary (or even slightly technically advanced) people can currently do.

Making it a simple toggle via the GUI would help.

However, it's still rather annoying in that you are pretty much guaranteed to leak IPs of some people who do not want their IPs leaked, because the default setting is to leak IPs, and almost nobody will know about this setting.

You are voluntarily choosing to harm your user's privacy by default, which for some, could have life threatening consequences.

That is shamelessly irresponsible, and IMO, those people would have totally legitimate damage claims against Google who:

1. Knows about the problem.
2. Knows how to fix it.
3. Is currently voluntarily choosing to not fix it.

Comment 9 by, Mar 3 2015

#8: maybe you want to use a different browser if your life depends on it? suggests this is can be modified from the extension API. So go ahead and make an extension. However, make sure you verify any claims you make, "webrtcblock" turned out to be both incomplete and unmaintained and... lifes might depend on you.
#9: I do use a different browser, thanks.

However, if you're going to make software that's being used by millions of people, you might as well do your best to take whatever *reasonable* steps you can to avoid harming them.

Fixing this issue isn't difficult. Throw up the same type of dialog that you already throw up for when a web page asks users for their location. You have the code to do this already.

It's about doing right by your users. It's about expectations. It's about avoiding harm to others.

Users on VPNs expect that their IPs are not revealed when they use Chrome. By default, Chrome reveals them. By default, Chrome reveals internal network topologies.

The behavior is unexpected. The bug can harm lives. The fix is simple.

If that's not reason enough to fix your software, what is?

Comment 11 by, Mar 3 2015

#10: the right place to discuss this is the w3c webrtc mailing list. I suppose answers it already though.
Status: Available
Summary: Creating an option to directly control multiple routes for WebRTC (was: Creating an option to block webrtc to prevent IP leakage)
Let's all take a deep breath.

We made a change for Chrome 42 so that we could give users *some* way of controlling this functionality (and were the first browser to do so). As mentioned in 333752, we are continuing to look at how we can simplify this solution.

Re-opening this bug until then.

Props to you #12. (Thank you!)
I have been looking for a solution for this on 333752.  and finally got one.  Am only posting here to say that the attitude that it is acceptable in anyway way to let this issue go 'drifting' on when you can stop it immediately is frankly disgusting, sickening and utterly irresponsible.
See #12. Chrome engineers are working hard on figuring out the right way to resolve this complex issue (which was opened less than a month ago!), and suggesting otherwise is counterproductive.
I did not suggest anything. 

I stated that you can and indeed have solved it for vpn users, but only if you look in forums like this and find hidden and obscure ways to do so. 

Leaking users IP addresses against there will, or knowledge is not a complex issue, it is negligence, when you could stop it now, for all VPN users, and give them other options.
Labels: M-43 WebrtcTriaged
Labels: -M-43 M-44 MovedFrom-43
Status: Assigned
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)

Well I got Punted. Go for the Short Kick? What's your solution?
It shouldn't be that hard to do something.
At least add an extra check box in advanced settings that controls this so that VPN users can be pointed there to easily make the necessary change. Right now you have to instruct users on how to find and edit their Chrome preference files without breaking anything.
It is ridiculous that this issue is still ongoing, I am surprised that the press is not hounding you for details of this sadly lacking approach to user security.
We're still evaluating all the options here. The issue here is that we can't make this behavior as the default since it'll prevent direct calls b/w 2 endpoints behind the same NAT, instead, it'll become a call very likely with TURN involved and hurts the audio quality with longer latency.

Rest assured that this is still one of the important issues that we are working on.
The other point that I missed is that it's also not trivial to have an UX option to convey the tradeoff here without possibly creating confusion. So basically, the directions we're looking at are
1) have some sort of UX to help user to understand the tradeoff
2) have a better default behavior which makes a reasonable tradeoff b/w privacy and audio quality.
I understand your concerns: poor audio quality if the default is changed, and user confusion if there is an extra option in settings.

However, what if you added an extra flag in from chrome://flags, called "Disable WebRTC Multiple Routes", with a description such as "Prevent WebRTC from returning local IP addresses, which helps prevent IP leakage but may reduce audio quality and increase latency."

This way, regular users who don't go to chrome://flags will not get confused, and VPN providers can point users there to enable the flag. This is not a permanent solution, but I am sure this is better than the current state, where users have to find and edit their preferences file.
appreciate the suggestion but chrome://flags, as I just learned it, is only for developer, not end users. 

The idea was not to ask user to modify the preference. In fact, we expose that preference through extension api. All we need is a published extension which does this before we find a better solution.
This topic seems to have dried out. Firefox doesn't have any problem by allowing their users the ability to enable/disable the WebRTC feature.
Come on Chrome what's the problem with you people? Too big to bother with the puny mortals?
Until a fix comes, changing "WebRTC" to something else in the code files will do.
I'm just an average Joe Bloke, this information does nothing for me. I haven't got a clue where to find or change code files.

Comment 29 by, May 21 2015

This is geting ridiculous. Is Google becoming Apple? Does it not care about
privacy anymore? Why can't we disable WebRTC through the UI as with other
Labels: -M-44 MovedFrom-44
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 31 by Deleted ...@, May 21 2015

I'm not a developer, I'm not getting a straight answer here so I guess I shouldn't be in this forum. But just before quitting: on the few links provided to me, from my query, I surely can't work out even the slight hint on how to do the changes Chomium supposedly provide. Where are the changes instruction, but go into the code files? 
I guess I got to drop using Chrome till that time the fix become available and intelligible for a regular bloke like me (it should not be so difficult, after all us Joe Blokes are not completely idiots)
I agree, this is getting ridiculous. How hard is it to give users an option? I understand chrome://flags is intended for developers only, but if you can't decide on how to present the choice to the user in regular settings, isn't it better to have the option in flags than to make people change their preferences files? Or chrome://plugins/ would work as well. Firefox has this option.

By the way, here's what you have to do to prevent WebRTC IP leaks in Chrome right now:

1) Go to your Chrome user preference file.
 Windows Vista / 7 / 8 / 8.1:
  C:\Users\(your username)\AppData\Local\Google\Chrome\User Data\Default\Preferences
 Mac OS X:
  ~/Library/Application Support/Google/Chrome/Default

2) Exit Chrome and save a backup copy of the file somewhere else. Make sure Chrome is not running in the background.

3) Open the Preferences file in a text editor of your choice. (i.e. Notepad, Text Edit, Sublime Text)

4) Add these lines to the bottom of the file, paying attention to the format. (Just follow the format of the other lines, adding a comma if necessary.)

"webrtc": { 
    "multiple_routes_enabled": false 

If your accidentally made an error and Chrome won't start anymore, you can replace the Preferences file with the backup copy you saved earlier.

Comment 33 by, May 21 2015

The preference file edit was never intended to be a final solution. We are working on a way to address this problem without requiring users to edit prefs or dig through obscure options.

Labels: -Pri-2 -MovedFrom-43 -MovedFrom-44 Pri-1 M-45

Comment 36 by Deleted ...@, Jun 1 2015

You can use Hide ALl IP ( ) to let WebRTC only show your private IP or block it. I test with it, it works.
Hi gents, how about chromebooks? any way around this? I'm on beta channel and just got 44 in. I appreciate any tips. A free rant is on offer:

on such a bothersome serious matter google is acting like my grandma. I mean once this is your attitude, and add to it blatant privacy violations becoming a core of the business model, with no apology even, and you risk losing  early adopter and activist users for good. Small a number as they are but no doubt they are the reason a piece of tech takes off instead of another. Trust erosion is insidious and when you reach the "distrust" tipping point you probably ain't gonna recover. Trust is my business, so trust me google will ya?

because of this issue I've already opted out of chrome on my windows machine months ago. This is after years with chrome. I'm back to my good old trusty firefox and most probably not returning. On linux I'm so firefox already and just weeks ago on android. Next step is dropping android itself I kid you not. Fixing the webrtc exploit as a decent tech company instead of being driven by marketing and business strategy greed would have avoided the cascade.

Comment 38 by, Jun 12 2015

As pointed out by #33, manual modifying the preferences file is not an intended solution.

We could start with a chrome extension which, once installed, will disable the enable_multiple_routes for anyone who is concerned with this issue.

Does this sound like a reasonable solution to address this problem?
guow, this problem is old by internet time. And if it is adjusted for inflation (i.e.simplicity of a solution to at least reduce harm), this bug is a SSL-heartbleed category violation. The only difference is that heartbleed wasn't known, and was instantly fixed once it was. Do you get that?

any solution to the bug is welcome to save the unassuming victims on chrome, but that ain't gonna sooth what has become a grudge by now. I'm personally past chrome, and there is no return. 
oh, and for #12: don't talk to me about the love that once was between us. You betrayed me and this baby is not mine!
#38 Guow: I think creating a chrome extension and linking to it would be a very reasonable solution to address this problem for now. Thank you!
For anyone interested, I've made a Chrome extension that sets the WebRTC Multiple Routes option to false.

It's just a single line of code.
Many thanks Aghor.
Just tested and it works fine.
Errata corrige:

It works with full VPN. Not with browser VPNs addons like ZenMate.
Thanks #42 Aghor!

Comment 47 by Deleted ...@, Jul 3 2015

Thank you so much Aghor!
Many Thanks, works perfectly :D yay
Status: Fixed
We have now released an official Chrome extension to control this behavior. We believe this is better than a checkbox in preferences, since it can be directly linked to, and we can provide a more detailed explanation of what it does.


There are certain apps that don't work properly with this extension right now (e.g. We are working on addressing these issues.
We are also working on a related issue, specific to proxies,  bug 497040 .
IP still leak when using Browser VPN's add ons, like Browsec. I suspect that it may work with a full desktop VPN.
So when will you guys give us something that works with everything, like Firefox fix?
#51: IIUC, Browsec is a proxy, not a VPN, and falls under  bug 497040 . Being worked on.

Components: Privacy
Glad we have a solution for desktop platforms (Windows, Mac, Linux, Chrome OS). Android on the other hand is the only remaining platform having this issue, since extension doesn't exist there. Should we track this separately in a new bug?

Sign in to add a comment