Repository navigation
Remove WebRTC leak prevention #1723
Description
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
- Enable "Prevent WebRTC from leaking local IP addresses"
- 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
Activity
uBlock-user commentedon Sep 14, 2021
It is defaulted to off.
Breakage notice has already been added in the wiki, so whoever enables it is expected to know that.
andrewmd5 commentedon Sep 14, 2021
Why keep it around if the very thing is was meant to fix is no longer an issue?
uBlock-user commentedon Sep 14, 2021
Leakage still occurs at https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
uBlock-user commentedon Sep 14, 2021
Just because the website you tested isn't showing leaked IP addresses, doesn't mean the exploit no longer exists.
andrewmd5 commentedon Sep 14, 2021
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 commentedon Sep 14, 2021
I don't use Edge, you are making leap worthy assumptions here that are not true.
uBlock-user commentedon Sep 14, 2021
The whole premise on which you opened this issue is wrong and misleading. WebRTC leaks still occur and that setting is needed(
browserleaks.comis likely broken) and whoever experiences breakage, it is upto to them to disable it.andrewmd5 commentedon Sep 14, 2021
I listed the two most popular Chromium based browsers.
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 commentedon Sep 14, 2021
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 commentedon Sep 14, 2021
Do you not see local hostnames leaking ? Only that site leaks hostnames, not seeing localhost leakage anywhere else.
4 remaining items
Keep ability to prevent local IP address leaks for mobile version
mraonea commentedon Oct 10, 2021
Shouldnt there be code to cleanup this pref if a user has set it?
mraonea commentedon Oct 10, 2021
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 commentedon Oct 10, 2021
Please explain "broken browser", provide details about what exactly is broken.
mraonea commentedon Oct 10, 2021
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 commentedon Oct 10, 2021
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 toabout:config, and the settingbrowser.privacy.network.webRTCIPHandlingPolicyis 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 commentedon Oct 10, 2021
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 commentedon Oct 10, 2021
You are misdiagnosing your issue. There is no code which calls
browser.privacy.network.webRTCIPHandlingPolicyin 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 whilewebrtcIPAddressHiddenistrue-- uBO'swebrtcIPAddressHiddenis 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.