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.