Remove WebRTC leak prevention

[andrewmd5]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

A large amount of users still enable "Prevent WebRTC from leaking local IP addresses" which breaks WebRTC application even though browsers no longer leak local IP address information by masking local candidates with mDNS.

This option if not removed should at a minimum be hidden behind advance settings (defaulted to off)

A specific URL where the issue occurs

https://browserleaks.com/webrtc

Steps to Reproduce

1. Enable "Prevent WebRTC from leaking local IP addresses"
2. Try and establish a PeerConnection

Expected behavior

WebRTC applications should continue to work as they will never produce local IP addresses

Actual behavior

WebRTC applications break

uBlock Origin version

1.37.2

Browser name and version

Edge Version 94.0.992.19

Operating System and version

Windows 10

[uBlock-user]

This option if not removed should at a minimum be hidden behind advance settings (defaulted to off)

It is defaulted to off.

Breakage notice has already been added in the wiki, so whoever enables it is expected to know that.

[andrewmd5]

Why keep it around if the very thing is was meant to fix is no longer an issue?

[uBlock-user]

Leakage still occurs at https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

[uBlock-user]

Why keep it around if the very thing is was meant to fix is no longer an issue?

Just because the website you tested isn't showing leaked IP addresses, doesn't mean the exploit no longer exists.

[andrewmd5]

Why keep it around if the very thing is was meant to fix is no longer an issue?

Just because the website you tested isn't showing leaked IP addresses, doesn't mean the exploit no longer exists.

Calling it an exploit is a stretch. More importantly, the reason you see unmasked candidates (the local IP address) is because you're likely using the beta version of Edge or Chrome Canary where mDNS is disabled unless explicitly set via a command-line flag.

These browsers are not meant to be used by consumers as daily drivers, they are for developers to test new browser features. Breaking applications running in the production version of a Chromium browser to prevent IP leaking that only occurs in a pre-release version of the same browser doesn't make sense.

[uBlock-user]

More importantly, the reason you see unmasked candidates (the local IP address) is because you're likely using the beta version of Edge or Chrome Canary where mDNS is disabled unless explicitly set via a command-line flag.

I don't use Edge, you are making leap worthy assumptions here that are not true.

[uBlock-user]

The whole premise on which you opened this issue is wrong and misleading. WebRTC leaks still occur and that setting is needed(browserleaks.com is likely broken) and whoever experiences breakage, it is upto to them to disable it.

[andrewmd5]

More importantly, the reason you see unmasked candidates (the local IP address) is because you're likely using the beta version of Edge or Chrome Canary where mDNS is disabled unless explicitly set via a command-line flag.

I don't use Edge, you are making leap worthy assumptions here that are not true.

I listed the two most popular Chromium based browsers.

The whole premise on which you opened this issue is wrong and misleading. WebRTC leaks still occur and that setting is need(browserleaks.com is likely broken) and whoever experiences breakage, it is upto to them to disable it.

Can you provide any details to your environment (such as the browser and version) so I can verify that such leaks still occur? We've collected telemetry from over 400,000 sessions to our app in the last month and every ICE candidate with an unmasked IP address was running either the beta version of Edge or Chrome Canary, unstable versions of the browser where mDNS is disabled.

It may be up to the user to choose to disable "IP leaking" but the user likely does not know what that actually means, nor has it a major issue since 2018 when Firefox, Safari, Chrome, and others implemented mDNS. Applications also break in ways that are almost impossible to diagnose which creates developer headache and a terrible user-experience.

We can create a safer web without nuking things.

[gorhill]

The whole premise on which you opened this issue is wrong and misleading.

I saw the issue yesterday night, but didn't answer because it's just too tedious on a phone. I actually agree that it has become pointless ever since I noticed that even without the setting checked, there is no local IP address leakage (I can't find the issue in which I commented about this).

Given this, I am leaning toward removing it as suggested. However this raise the question: why is the (now useless) setting breaking web applications?

[uBlock-user]

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Do you not see local hostnames leaking ? Only that site leaks hostnames, not seeing localhost leakage anywhere else.

[gorhill]

Do you not see local hostnames leaking ?

I don't see local IP addresses leaking, just my public facing one (expected unless using a VPN), and some GUID-looking local hostnames which change when refreshing the page and trying again, so not something which can be used to fingerprint.

So it's probably best to remove that setting given that it's still cause a lot of invalid issues being reported (people expect their public-facing IP to not be seen...), and because it can break stuff out there, for no gain in the end.

What the setting does currently from testing that page is that it prevent the .local random hostnames from being generated/used.

---

I think I will fix this for the current release candidate.

[uBlock-user]

it's still cause a lot of invalid issues being reported (people expect their public-facing IP to not be seen...)

Yes that's been on the rise as some users simply do not understand the setting itself.

[gorhill]

This also allows me to remove ugly initialization code for Chromium-based browsers because toggling the setting was causing an extension crash on the Arch version of Chromium.

[gwarser]

https://bugzilla.mozilla.org/show_bug.cgi?id=1588817 "Enable mDNS hostname obfuscation"
https://bugzilla.mozilla.org/show_bug.cgi?id=1544770 "[meta] Add mDNS support to webrtc signaling"

https://bugs.chromium.org/p/chromium/issues/detail?id=878465 "mDNS service for IP handling in WebRTC"

[gwarser]

Obfuscation still not supported on Android (confirmed) https://bugzilla.mozilla.org/show_bug.cgi?id=1581947 "Support mDNS hostname obfuscation on Android"

[mraonea]

Shouldnt there be code to cleanup this pref if a user has set it?

[gwarser]

It was done by API and uBO turned it "on" on every startup.

[mraonea]

Well, I still have the relevant prefs set. Just removing the toggle without cleaning up the prefs leaves users with a broken browser with no way to fix it.

[gorhill]

Just removing the toggle without cleaning up the prefs leaves users with a broken browser with no way to fix it.

Please explain "broken browser", provide details about what exactly is broken.

[mraonea]

What this issue is about, WebRTC applications breaking with "webrtc leak prevention" toggle set on in ublock.

https://searchfox.org/mozilla-central/source/toolkit/components/extensions/parent/ext-privacy.js#133

These settings are left as is, since ublock does not clean up after itself, instead just removing the toggle for setting them in the addon settings. Thus resulting in "webrtc leak prevention" set to on permanently without a way for users to disable it, since the toggle is gone from addon settings.

(I had to manually clean up the prefs in about:config back to their default state)

[gorhill]

You are still not providing any details.

So far it appears the real issue is you are making flawed assumptions. The setting is not used anywhere than mobile browsers. You do not make the case the setting is having an effect in desktop browsers. How is providing a link to Firefox's source code making the case for what you alleged is happening in uBO?

uBO does not modify about:config, it has no access to about:config, and the setting browser.privacy.network.webRTCIPHandlingPolicy is reset by the browser when uBO terminates, and since version 1.38.0, uBO does not make use of this setting in desktop browsers.

[mraonea]

I have had Ublock Origin installed in Firefox. I have had "prevent webrtc leakage" ticked in Ublock settings. In the latest Ublock version update the setting got removed from the addon options.

However, the prefs the ublock setting modifies (linked to above), still remain in their altered state, so in effect the "prevent webrtc leakage" setting is still enabled in the browser even though the toggle got removed from Ublock settings. I had to manually clean up those prefs back to their original state through about:config, as the toggle does not exist in Ublock Origin anymore.

I dont know why the prefs Ublock modifies remain in their altered state if indeed the browser is supposed to reset them to their default settings automatically, but this has not happened for me and it would seem like Ublock needs to clean up after itself by resetting them if the user has had the setting toggled, or the user ends up permanently with these altered settings.

[gorhill]

I had to manually clean up those prefs back to their original state through about:config, as the toggle does not exist in Ublock Origin anymore.

You are misdiagnosing your issue. There is no code which calls browser.privacy.network.webRTCIPHandlingPolicy in Firefox's desktop version of uBO 1.38.2, so what you state is not possible, because this line and this line, and this is confirmed by actually stepping in the code while webrtcIPAddressHidden is true -- uBO's webrtcIPAddressHidden is a noop in 1.38.2, and there is nothing to clean up.

I suggest you research better and throw out all assumptions before you conclude anything.

Locking this thread now, enough time has been wasted on a non-existing issue. If you have actual and detailed repro steps (which you persist to avoid), open a new issue and be sure that your steps are carefully detailed so that whoever else can reproduce.