Initial release of WebRTC Network Limiter, a Chrome extension

[Justin Uberti]

We have released an official Chrome extension that, when installed, limits the IP addresses used by WebRTC. You can install in two clicks (the second click is to allow the extension to change the relevant preference in Chrome settings).

Most WebRTC applications will work fine with this extension, although as indicated below it may result in lower media quality. Due to current limitations within Chrome, certain apps will not work at all at present with the extension, namely:

a) apps that do not gather STUN/TURN candidates because they connect to a public peer

b) apps that do not provide a IPv6 STUN server, when the client is IPv6-only

c) demo pages that don't use a STUN or TURN server (e.g. https://webrtc.github.io/samples)

We are working on resolving all of these cases; the tracking bug is https://code.google.com/p/webrtc/issues/detail?id=4865. Once we have done so, we expect to make changes to the default behavior of Chrome as it relates to IP address gathering.

Full description of the extension below:

Disables the WebRTC multiple-routes option in Chrome's privacy settings.

★ What it does:
This configures WebRTC to not use certain IP addresses:
  -  IP addresses not visible to the public internet (e.g. addresses like 192.168.1.2)
  -  any public IP addresses associated with network interfaces that are not used for web traffic (e.g. an ISP-provided address, when browsing through a VPN)
 
Once the extension is installed, WebRTC will only use public IP addresses associated with the interface used for web traffic, typically the same addresses that are already provided to sites in browser HTTP requests.

★ Notes:
This extension may affect the performance of applications that use WebRTC for audio/video or real-time data communication. Because it limits the potential network paths, WebRTC may pick a path that results in significantly longer delay or lower quality (e.g. through a VPN). We are attempting to determine how common this is.

[Iñaki Baz Castillo]

While this is appreciable, it means that all those users who want WebRTC and don't want to leak their VPN addresses must use Chrome (and just Chrome browser) plus this plugin.

Any reason for promoting this feature as a browser vendor specific plugin instead of promoting it within the W3C WebRTC spec? In my mind any WebRTC capable browser should expose a "standardized" setting for this subject within its native user configuration.

If the solution to a problem involves a plugin then it is not the best solution.

[Serge Lachapelle]

It's a first step. One we believe is in the right direction.

As you know, we are quite active in the W3C and are having several discussions there. Sometimes, the best way to move discussions along is through concrete code and examples. 

We felt we had the opportunity to do something positive while those conversations are going on and perhaps help it along in a positive, constructive manner. We are also talking to other browser vendors quite actively.

This is not a plugin, it's an extension. It's a one line extension, which connects to a non negligible amount of work that went into the browser to provide the necessary hooks. (I know, semantics, but having worked hard on NPAPI plugin deprecation, an important semantic)  

Source code is here: https://github.com/webrtc/samples/tree/master/src/content/extensions/multipleroutes

Thanks for the feedback though... we know our work here is not done. This is just a first step.  Do let us know of any improvements you'd like to see to the extension by filing issues!

/Serge

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9fcb6580-9fda-4ed0-a444-39ad447eedca%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Serge Lachapelle |

PM Director |

ser...@google.com |

+46 732 01 22 32

[Martin Cigorraga]

Hi all,

On Chrome Version 45.0.2454.85 (64-bit) with this plugin enabled the IP is still leaked -- please see www.browserleaks.com/webrtc.

Also, why not include a button than can let the user easily enable/disable WebRTC - like Firefox's addons do?

While certainly one would want this bug-not-a-feature turned off most of the time, so is true that you need it for some RTC like Google Hangouts, BlueJeans, etc.

Btw, leaking the IP is one of the 'less important' issues, when WebRTC is enabled you're also sharing the unique ID of some of your computer's parts with the whole world! Totally hellish if you ask me because while my personal citizen ID is public I'm not shouting it wherever I go -- as WebRTC does with some sensible personal data.

While WebRTC is a good idea it is horribly wrong implemented, a privacy nightmare that seems made to spy on people.

Regards.

[Philipp Hancke]

On Tue, Sep 8, 2015 at 11:40 PM, Martin Cigorraga <martinc...@gmail.com> wrote:

Hi all,

On Chrome Version 45.0.2454.85 (64-bit) with this plugin enabled the IP is still leaked -- please see www.browserleaks.com/webrtc.

Also, why not include a button than can let the user easily enable/disable WebRTC - like Firefox's addons do?

While certainly one would want this bug-not-a-feature turned off most of the time, so is true that you need it for some RTC like Google Hangouts, BlueJeans, etc.

Btw, leaking the IP is one of the 'less important' issues, when WebRTC is enabled you're also sharing the unique ID of some of your computer's parts with the whole world! Totally hellish if you ask me because while my personal citizen ID is public I'm not shouting it wherever I go -- as WebRTC does with some sensible personal data.

Are you referring to the unique device ids for microphone and webcam? Then I'd recommend clearing your cookies and reading http://w3c.github.io/mediacapture-main/#privacy-and-security-considerations

Those are not IDs of some of your computer's parts...

[Guo-wei Shieh]

As part of the continuous effort to protect privacy for our users, we have updated the Chrome Network Limiter Extension (link to version 0.2.1.2) with more controls, which provide an easy way to customize WebRTC behavior.

What's in the updated extension?

The updated extension comes with an options page, which can be accessed from chrome://extensions. Once installed, it allows users to select one of three options for WebRTC traffic:

a) Give me the best media experience: This option allows Chrome to explore all network paths to find the best way to send and receive media, which may be different from normal web traffic.

b) Use only my default IP address: This option forces Chrome to use the same network path for media as for normal web traffic, except when a web proxy is present. To prevent degraded performance, Chrome will attempt to send media directly instead of using the proxy.

c) Use my proxy server (if present): This option forces Chrome to use the same network path for media as for normal web traffic, including use of a web proxy. Chrome will always attempt to send media through the proxy, which will typically hurt media performance and increase the load on the proxy; furthermore, this behavior may be incompatible with some applications.

By default, Chrome M47 operates at option (a). After the installation of the extension, the default behavior will be (b), just like the previous version of the extension. (c) is a new mode, supported in Chrome M47, which honors proxy settings.

We'd love to hear any feedback!