search

uBlockOrigin / uBlock-issues

This is the community-maintained issue tracker for uBlock Origin
https://github.com/gorhill/uBlock
935 stars 79 forks source link

Please Re-Instate WebRTC Blocking Immediately. #1799

Closed scramblr closed 2 years ago

scramblr commented 2 years ago

Prerequisites

I tried to reproduce the issue when...

Description

Back in September, a thread was created (https://github.com/uBlockOrigin/uBlock-issues/issues/1723) and WebRTC was removed from the uBlock codebase. This has silently exposed many people who rely on airtight configurations to never expose their external IP address. While the idea of masking your external IP address was mocked in the thread, I would politely refer you to the use cases of Tor, Proxies, and other IP masking technologies. WebRTC is used to hop over these masks and expose a user's true external IP address.

It was a very important safety tool, and it was removed without even alerting anyone. Please add it back.

A specific URL where the issue occurs

https://browserleaks.com/webrtc

Steps to Reproduce

This is N/A.

Expected behavior

Please re-instate WebRTC protections immediately.

Actual behavior

N/A

uBlock Origin version

All future versions

Browser name and version

Chrome, Chromium, etc

Operating System and version

All

sickcodes commented 2 years ago

Why was this removed? WebRTC IP Leaking via STUN requests is textbook tracking

opsxcq commented 2 years ago

This issue affects everyone, please fix it ASAP.

uBlock-user commented 2 years ago

While the idea of masking your external IP address was mocked in the thread, I would politely refer you to the use cases of Tor, Proxies, and other IP masking technologies. WebRTC is used to hop over these masks and expose a user's true external IP address.

WebRTC settings only blocked leaking local router IP address, your external IP address was never hidden in the first place.

scramblr commented 2 years ago

You don't seem to understand how this works.

uBlock-user commented 2 years ago

There's nothing to understand, "Prevent WebRTC from leaking local IP addresses" setting speaks for itself. Your external IP address was never hidden, adding the setting back won't hide it either.

MLGRadish commented 2 years ago

It seems like the name is confusing. Renaming the feature to "disable WebRTC" should fix the issue.

uBlock-user commented 2 years ago

Renaming the feature to "disable WebRTC" should fix the issue.

https://github.com/gorhill/uBlock/issues/2853

Doubt that's possible in Chromium based browsers.

MLGRadish commented 2 years ago

How about a Firefox only feature then?

scramblr commented 2 years ago

Can you please explain to me why the uBlock version from ublock.org is able to protect my IP from exposure still, then? https://pbs.twimg.com/media/FDdOCBUVcAMFrjG?format=jpg&name=4096x4096

There's nothing to understand, "Prevent WebRTC from leaking local IP addresses" setting speaks for itself. Your external IP address was never hidden, adding the setting back won't hide it either.

duaneking commented 2 years ago

Is it possible that this was bought out and so this was removed as a way to make it less effective for users and thus more valuable for the new owners?

uBlock-user commented 2 years ago

Can you please explain to me why the uBlock version from ublock.org is able to protect my IP from exposure still, then? https://pbs.twimg.com/media/FDdOCBUVcAMFrjG?format=jpg&name=4096x4096

Side-effect of that setting on your "airtight" configuration perhaps. Hiding external IP address has never been the intension of the WebRTC setting.

Your external IP address is already sent to the website when you navigate to it via a document request. So in the end it's still exposed.

scramblr commented 2 years ago

You are completely dismissive and condescending about all of this, and you don't have a grasp on what you're doing. Enjoy your day.

ghost commented 2 years ago

Can you please explain to me why the uBlock version from ublock.org is able to protect my IP from exposure still, then? https://pbs.twimg.com/media/FDdOCBUVcAMFrjG?format=jpg&name=4096x4096

Side-effect of that setting on your "airtight" configuration perhaps. Hiding external IP address has never been the intension of the WebRTC setting.

Your external IP address is already sent to the website when you navigate to it via a document request. So in the end it's still exposed.

You really don't get it do you

gorhill commented 2 years ago

The aptly named "Prevent WebRTC from leaking local IP addresses" never had for purpose to hide your public-facing IP address, this is silly to think so -- it's literally in the name of the setting, and uBO is not a VPN or proxy service. Now with regard to non-public-facing IP addresses, the setting is no longer needed in modern browsers:

LAN IP addresses are not disclosed when using my ISP: Screenshot from 2021-11-05 18-59-05

LAN IP addresses and ISP IP address are not disclosed when using a (system-wide) VPN: Screenshot from 2021-11-05 19-00-28

Addendum 2021-11-06, via (browser-wide) Tor proxy: Screenshot from 2021-11-06 11-15-42

Your public-facing IP address is visible to all sites you visit, it's silly to think that if it's not reported at https://browserleaks.com/webrtc specifically it means the site browserleaks.com can't see it, you literally requested a web page from that site, they know your public-facing IP address, they sent the HTTP response to it, see for yourself: https://browserleaks.com/ip.

Also, be aware that extension-based VPNs/proxies are not reliable to hide your ISP IP address, use a real system-wide VPN/proxy if you want to reliably hide your public-facing IP address. If your extension-based VPN/proxy is not properly shielding your ISP IP address, then report to them -- they are the extension with the issue. (Addendum 2021-11-06, actual case demonstrating this: https://twitter.com/fernacen/status/1457003371060137988, and showing that the removed setting was of no help in such case).

gorhill commented 2 years ago

So it appears the invalid issue filed here is a result of this tweet. The tweet contains many falsehoods:

Screenshot from 2021-11-06 06-41-01

"silently removed"

False. There is an issue describing the motivation for the change, and it's in the release notes.

If you do not trust uBO that much, then it's on you to closely follow development and read release notes -- your failure to do so does not make documented changes "silent".

"removed all WebRTC blocking"

False. uBO has never ever supported "WebRTC blocking". The setting was called "Prevent WebRTC from leaking local IP addresses", and its sole purpose was to prevent local IP address leakage through WebRTC, as reported here (2015).

This WebRTC flaw has been fixed natively in Firefox and Chromium more than two years ago, making the uBO setting "Prevent WebRTC from leaking local IP addresses" obsolete ever since this was fixed in those browsers.

The setting is still present and honored in Firefox for Android because it was not fixed natively as in the desktop version of Firefox. If you disable the setting in uBO in Firefox for Android and visit https://browserleaks.com/webrtc, you will likely see the "Local IP Address" entry being filled with one or more IP addresses. This is what the uBO setting is meant to prevent, and it works as expected once you enable it in that browser.

"making MANY users vulnerable to IP unmasking"

False. As seen in my comment above, there is no "IP unmasking", and OP has failed to demonstrate this, and only provided a link to https://browserleaks.com/webrtc, apparently expecting that "Public IP Address" should be n/a -- no actual steps or technical details are provided to make the case there is an actual issue, so essentially just FUD.

As explained in my comment above, this is silly, your public IP address is by definition visible to all sites you visit -- sites don't need WebRTC for this, just visit this page on the same site, it reports your public-facing IP address regardless of whether WebRTC is enabled or not.

The tweet has two screenshots, devoid of any details about the context. The browserleaks.com-related screenshot in the tweet shows that there was no "Local IP address" leakage, thus thereby confirming that the "Prevent WebRTC from leaking local IP addresses" setting is indeed no longer needed.

uBlock-user commented 2 years ago

OP and his posse who downvoted my responses are the same people spreading that mis-information via tweets on some ignorant belief that their ISP associated IP address is somehow blocked via that setting. It's astounding as to how far they will go because of the setting's removal for desktop browsers.

gorhill commented 2 years ago

At this point I am convinced all this is completely in bad faith -- hence why he refuses to come up with details regarding his claims.

Consider that he posted a screenshot of sleazy uBlock supposedly blocking WebRTC as if natively without mentioning that this can be accomplish only after one add the filter *$webrtc:

Screenshot from 2021-11-07 07-49-52

Whoever can try and see this for themselves. There is no setting in the dashboard of sleazy uBlock to control WebRTC behavior, this can only done through adding a filter.

You can accomplish just the same with uBO through its own filter syntax: *##+js(nowebrtc).

uBO's implementation (Jun 2016) predates that of sleazy uBlock (Oct 2018), and in both cases the purpose is to address sites using WebRTC to push ads, not to hide public-facing IP address through WebRTC.

uBlock-user commented 2 years ago

OP and his posse are trolling, ignore them. I don't see anyone with a sensible mind joining in the conversation in the tweets.

gorhill commented 2 years ago

Trolling or not, it's someone with a fair number of followers (many whose opinions appear captive and accepted without questioning that the claim is valid) who spread FUD about uBO:

FUD is generally a strategy to influence perception by disseminating negative and dubious or false information and a manifestation of the appeal to fear.

This is exactly what this case is about, and such case of FUD directed at uBO deserves to be thoroughly documented -- though we will likely never know what ultimately motivated this person to try to undermine the trust people have in uBO, trust earned over years of never compromising users' best interests and through refusing to sell out.

Summary:

If anything this shows that people need to not unquestionably accept someone claims especially when they refuses to substantiate them outright and/or through deflection, regardless of how popular is the source[1].

[1] This is why personally I typically provides upfront as much verifiable information when I make claims, I want people to be able to compare their own findings with mines -- I don't ask people to blindly trust me.

uBlock-user commented 2 years ago

You won't be able to change their minds no matter how much you try to convince them, that's the impression I got at this thread, so document as needed, but engaging them in fruitful conversation is simply never going to happen. Talking to these group kind of people is like talking to a wall.

gorhill commented 2 years ago

won't be able to change their minds

I am not trying to achieve this, I just wanted to document this in details to save time for whoever may want to look more into all this and for future reference if this happens again.

uBlock-user commented 2 years ago

What puzzles me is why they pick uBO only, what they want is not offered by any content/ad blocker in existence, so in theory they should go after other blockers like ABP/AdGuard/Brave too.

gwarser commented 2 years ago

"when mic/camera permission is granted."

I believe this is true. I read about this somewhere[^likely]. But why someone will give browser permission to connect for only purpose to share IP / fingerprinting? On the other hand, with WebRTC blocked, connections will not be possible at all, even legit ones.

@gorhill

[^likely]: Very likely: https://github.com/arkenfox/user.js/issues/1282:

gorhill commented 2 years ago

On my side, when not selecting mic/camera permission, no local IP addresses are leaking. When selecting mic/camera permission, there is an exception -- I don't have a mic/camera.

I believe this is true

Did you reproduce?

gwarser commented 2 years ago

I too don't have mic or camera. Arkenfox issue is linking to convincing documents.

gorhill commented 2 years ago

By the way, I am now blocked by that https://twitter.com/notdan person (ref), because I "dared" to provide a link to the thread here (ref) in response to his recent tweet (ref) in which he referred to the thread here without (conveniently) linking to it.

I consider the advice of using *$+js(nowebrtc) (which curiously he was unable to figure out on his own while he had no issue figuring sleazy uBlock's *$webrtc) to not be ideal, at least it should come with a disclosure that unconditionally patching the DOM this way on all sites makes one stand out since the patching can be seen by page's JS, and thus used as fingerprinting information (through Object.getOwnPropertyDescriptor(window, 'RTCPeerConnection')).

The core issue here is the persistent unwillingness to provide exact repro steps which can be analyzed and acted upon if needed. Asking me to "re-Instate WebRTC blocking immediately" based on two screenshots devoid of context (actually the screenshots were not even mentioned, we had to find them) and where attempts to understand what is being reported are being stonewalled (running a pottymouth on twitter is not a substitute for competent technical information to help reproduce an claimed issue), while those who cared to try to reproduce found the opposite of the original claim.

Ultimately, the whole issue here has been polluted by a bad faith person, and if there is an actual issue to solve, this should be opened as a separate issue with all the actual relevant technical information as required -- all this is not specific to uBO, this is how any project work -- issues have to be substantiated to be acted upon.

gorhill commented 2 years ago

I too don't have mic or camera. Arkenfox issue is linking to convincing documents.

The original comment was linking to https://browserleaks.com/webrtc. On that page, there is a "Audio Capture Permissions" which I am able to activate (I do have a microphone), and I do not see any local IP addresses leaked as a result.

uBlock-user commented 2 years ago

This has silently exposed many people who rely on airtight configurations to never expose their external IP address.

OP's reasoning for adding "WebRTC immediately", which is why this thread was going to go nowhere and was doomed from the beginning.

gwarser commented 2 years ago

I borrowed a camera. On https://browserleaks.com/webrtc when permissions are given permanently (probably page script limitation - it may only detect on reload when temporary permission [already] timeouts) it does detect my LAN IP:

image

On https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ even temporary permission allow to list my LAN IP:

image

Firefox 97.0a1 20211229092739 uBO 1.40.3b0

Chrome does not seem to support temporary permissions, granting them allow both pages to read LAN IP.

Chrome 96.0.4664.110 (Official Build) (64-bit) with custom build uBO 1.40.3b0

gorhill commented 2 years ago

Thanks for reporting this. Question:

uBlock-user commented 2 years ago

@u-RraaLL

u-RraaLL commented 2 years ago

I agree with @gwarser 's findings: Allowing either microphone or camera on browserleaks "permanently" leaks LAN IP. In my case - 2 routers = 2 LAN IPs. On webrtc.github.io, allowing even temporarily leaks both LAN IPs.

Dropping down to uBO 1.37.2 and enabling "Prevent WebRTC from leaking local IP addresses" fixes the issue on both sites.

There is no ISP IP leakage from behind the system-wide VPN I'm using. Haven't tried any VPN extensions though.

gorhill commented 2 years ago

There is no ISP IP leakage from behind the system-wide VPN I'm using.

Thanks, I was waiting for a confirmation.

To be clear, these findings have nothing to do with the opening comment, the two screenshots at the root of why the issue was opened had no local IP address in it.

In any case, I don't consider the new finding is a good reason to bring back the setting, because:

duaneking commented 2 years ago

With respect:

gorhill commented 2 years ago

I suggest you just install an extension that let you manage WebRTC, for example the official one from webrtc.org, https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia. In Firefox, this can be done in about:config. As already stated, that setting in uBO has been no longer relevant in uBO for years, and was actually causing issues for extension-based VPN/proxy.

What you seem to ask is for uBO to take over management of camera/mic permissions, this has never been a feature in uBO, so this is a feature request which should be opened as its own issue.

RedSteel-1 commented 2 years ago

Initially wanted to leave this comment in #1826.

@gorhill , according to the release notes:

"The setting "Prevent WebRTC from leaking local IP addresses" has been removed since it is no longer necessary in modern browsers"

But what about people who are using non-latest browsers where it is necessary? There are people using FF 52/56 because of the extensions, those who still need Flash are sticking to Chromium-87-based browsers, latest Cent and 360 browsers are based on Chromium 86, also Opera 58 where the UI is still not as bad as it is in 60+, XP-users are sticking to {Chromium 48, Opera 36, the mentioned above 360-on-Chr.86}, latest FF versions have horrible UI that many cannot stand, some are sticking to FF 78/91 and/or Chromium-based 88/92 for certain reasons, and etc etc etc. Plenty of examples where (and plenty of reasons why) people are consciously using non-latest browsers.

Why removing the setting instead of keeping it and letting the user decide to use it or not?

I would like to request bringing this setting back and keep the choice for the user.

uBlock-user commented 2 years ago

There are people using FF 52/56 because of the extensions

Minimum supported version now is Firefox 60.

gorhill commented 2 years ago

keep the choice for the user

Those who choose to use outdated browser versions have the choice to use outdated uBO versions.

Just to make this clear, no security-conscious person is ever going to advise to use obsolete, no-long-supported versions of a browser, and frankly your top worry when using an obsolete, no-long-supported version of a browser is not uBO no longer supporting a feature which has become unnecessary for years (and one that has been found to conflict with extension-based VPNs/proxies), and for which you can easily install another extension dedicated to this (there are many of them). Your top worry should be all the security holes afflicting your obsolete, no-long-supported version of the browser you are using, and this is your burden to bear instead of asking extension authors out there to bear the burden of your misguided choice.