Need alternative WebRTC Block no longer works...

Is WebRTC persistent in Chromium as well like it is for Chrome? Just wondering if anyone can confirm.

 

I see options to turn off WebRTC in About://Flags. However Google has now disabled ALL of these options.

I'm not paranoid.. But...

 

Google doesn't like adblocking or addons that disable their tracking. It is an ongoing battle. WebRTC was developed as a way to get around some of the addons that are cutting into Google and other corporation's bottom line. There is some extreme sentiment about adblocking out there:

http://james.cridland.net/blog/piracy-and-ad-blockers-are-both-theft/

I just laugh at this sort of nonsense. Chrome is the one browser I won't use. I use Firefox with Noscript and Adblock for a limited number of websites where I really don't care about tracking. All my casual surfing is done with outdated Opera Presto with script, tracking and ad blocking and no WebRTC to bypass the blockers. I use MVPS hosts files for adblocking at a deeper level than browser addons and am trying to get it implemented at the router level so I don't have my time and bandwidth wasted by advertising. The web experience I want is not the web experience being pushed by Google or a lot of the web development community.

 

Can't this be blocked by a firewall type application, or Adguard??

I don't really understand the technique behind it, but we need to find something to block this. I will hire a programmer if we need something done but I have a sense of urgency at removing this. Remember, this negatives Incognito, VPN, and effectively is a NAT traverse of your internal IP structure.

I'm very concerned, and I want a solution. (that isn't firefox LOL) Firefox is just too slow for me, and has other things I dislike...

 

Using a VPN at the router level is one way of blocking it.

 

Implementing at router level with DNSMasq here has saved me a lot of time and made more efficient. Blocking ads on iPhones on network as well which is usually difficult since Apple restricts adblocking significantly. Easier to manage DNS server then Hosts file as well since TLD covers all subdomains as well.

I'm going to look into the specs for WebRTC now because I am curious although I am sure that it's implementation varies between browsers.

 

I found something but i don't know how to add the preference and don't know if it's work, maybe someone could help :

I edit the master_preferences files of Chrome located : C:\Program Files (x86)\Google\Chrome\Application

I want to add the following preference : webrtc": {"multiple_routes_enabled": false},



Thanks.

 

I tried your suggestion but the demo was still able to grab IP. Here is what I tried following your suggestion:

Code:

      {
        "webrtc": {
          "multiple_routes_enabled": false
        }
      }
    

EDIT:

Looking into more details here: chrome://webrtc-internals/ and chrome://webrtc-logs/

 

@WildByDesign

Thanks, unfortunately it doesn't work, well well, well, no luck yet

Rules.

 

Also found this : but still

https://codereview.chromium.org/940893003/

Rules.

 

WebRTC is sounding more nefarious by the day. Apparently it can use any port it wants, so you can't port block it. If it detects a blocked port it will try a wide range, and if you block that wide range you cripple your entire network. Also WebRTC will use UDP or TCP depending on what it decides it needs to work. So at the network level, I can't think of a way to block it right now.

Try this in Chrome; chrome://webrtc-internals

That will give you the internal details of it. I think what we need to focus on is blocking/disabling the functionality of STUN. This is what causes the NAT Traverse of the internal IP structure of a network. The potential for abuse of this is so ridiculous if I can't find a work around I will be forced to purge Chrome, but I really need Spartan to do that as Firefox and Opera won't work for me.

 

@Mayahana

Great, thanks for your inputs.

Rules.

PS : And do you have any infos for Spartan, will it work on W7 ?

 

Spartan will not work with anything other than Windows 10 apparently. IE will be left in for compatibility reasons but IE won't see any further releases other than security patches from what I read.

 

Thanks

http://www.pcworld.com/article/2876...r-planned-but-microsofts-watching-demand.html

http://www.theregister.co.uk/2015/01/28/spartan_details/


Rules

 

Thank you for shedding some more light on this. It sounds quite intelligent and that is going to make it difficult to block. We would likely need some sort of protocol sniffing filter to fingerprint on L7 similar to how they are able to define/control/throttle P2P type of traffic. But surely Google/WebRTC/etc would find ways around that anyway and would be a cat and mouse game.

What I wonder is why have they made this so difficult to block or give us an option to disable. It seems that there may be much more to it that we don't understand yet.

 

Even on the more advanced level, ADP wouldn't stop it, because the A is Chrome. Application Filtering wouldn't work, since the application being filtered(blocked) is Chrome. On a more paranoid side, this essentially allows a NAT traversed proxy to be opened on your computer without any real interaction from you, which gives up your NAT masked IP address to anyone that would like to get it. Layer 7 methods I have examined so far won't provide a solution. STUN can be disabled on various devices like IP phones where sometimes you need to disable ALG,SIP or RTC. However Google has implemented a 'smart' RTC into Chrome where it will tunnel through using ports ranging from 1025-65000 range if I am not mistaken. Unless we can identify 'traits' of RTC within Chrome, and then pick out traits to block, and perhaps create an IPS rule for it, then we're simply out of luck.

Frankly, I do not see many options at this point other than to drop Chrome, and that's not really viable. Firefox is a joke, nothing works intuitively on it, the speed dial is pathetic, and it is SLOOOOOW on some web pages. I've tried Chromium, and incarnations of Chrome (SRWARE, Dragon, EPIC, etc). All have RTC tunneling. One thought, can we find OLDER versions of Chrome prior to them breaking WebRTC? I haven't found a download repository with older versions of Chrome. Google has made sure you can't step back. I'd be willing to use Chrome 40 if I could find it, then disabling auto-updates, and tossing an exploit blocker on to secure it.

So two options I can see at this second;

1) Let's find a repository of older chrome/chromium versions.
2) Spartan, rely on Microsoft to fix this mess? (longshot, I know)

Until then, I can't think of anything on the network level to fix it. Unless a programmer or AV developer or something can create a workaround.

 

Here is the bug report for Chrome: https://code.google.com/p/chromium/issues/detail?id=457492&thanks=457492&ts=1423615660

Still "Untriaged" since February 10th. Doesn't seem to be any sense of urgency from Google devs. They are referring to it as a Feature Request hence the delay. I think of it as more of a bug then a feature request.

 

http://www.oldversion.com/windows/google-chrome/

 

Those all link to the downloader, which updates to latest.

I found a FTP repository of all versions of Chromium ever released. (I will post it tonight) But I have some confusing news.. When I installed the older versions I was still unable to disable RTC properly. I have a nagging(but potentially incorrect) suspicion Google is running STUN servers, and keeping the RTC pipe open on their end when Chrome loads, regardless of version. How else can this be explained? I was using 'localized' and 'portable' versions of Chromium, and each time I opened them RTC was functioning again. This is giving me some anxiety about privacy as this essentially violates the sanctity of NAT, and creates an instant traverse of the WAN into the LAN. In fact, this is a gross security violation.

Imagine running ChromeOS device? This stuff is going to cause loss of sleep... A few people around here were aggressively promoting ChromeOS laptops..

 

Installed version 28.0.1500.71 m, i'm able to pass https://diafygi.github.io/webrtc-ips/, but like as you said i think RTC still doing request, how? i don't know, maybe via DNS request or Webkit (may i wrong).

Maybe 22 versions and older did the trick
http://caniuse.com/#feat=rtcpeerconnection

However, using old versions of chrome make me uncomfortable.

Rules.

 

That's going back too far, and I agree - uncomfortable, not to mention breaking extensions and pages.

 

That's the only way for keeping an updated version.

Or an Abracadabra by Chrome's developper.

 

You are quite likely right. If that is the case, do you have any way to figure out the STUN server IP or domain name?

 

Microsoft and Google have been coming down on these older version sites lately. First it was older versions of Skype and now Chrome. The forced upgrade mentality is getting absurd. Firefox has older versions available with a warning while any easily available links to older versions of Chrome are suppressed. Yet another, unexpected, example of web censorship. I can see why I've completely avoided Chrome since the beginning. When Chrome first came out, I decided not to use it just because Google so dominated the server side of the web that I wanted to use browsers from other sources and not have my whole web experience be dominated by one corporation. Better to be slow and safe with Firefox.

I did some reading of old posts on WebRTC and found this site which does a little more extensive testing than just a Stun server request:

https://www.browserleaks.com/webrtc

There are tests for every kind of browser leak. So far, it looks like default disabling of javascript with whitelisting is working well. Without javascript, WebRTC is dead in its tracks. The Firefox fix works when I enable javascript. Chrome is the only problematical browser.

 

It appears that this leak is fixed in M-42. I will report back.

EDIT: After reading these bug reports along with some others, I am less confident in this now. More confused, and less confident. I just wish there was a way to completely Disable WebRTC for those that wish to do so.

https://code.google.com/p/chromium/issues/detail?id=333752
This bug report allows users to force WebRTC traffic through VPN.
* this one is fixed targeting M42 dev

https://code.google.com/p/chromium/issues/detail?id=462056
WebRTC STUN requests do not use system proxy - leaks real ip
* this one is Assigned but not fixed yet