As part of the next release:

1. Set a flag, something like legacyWebrtcProtectionUser, for users who have WebRTC protection enabled.
2. If the legacy flag is set, show a message in the popup that says something like, we are going to remove WebRTC IP leak protection in a future update (maybe linking to this issue), and that you could enable a similar setting in uBlock Origin or install a dedicated extension such as WebRTC Network Limiter (by Google, Chrome-only, not sure what to recommend in Firefox). We could style the badge in a special way to draw attention to the popup.
3. Hide the "Prevent WebRTC from leaking local IP address" UI setting unless the legacy flag is set. (Users with the legacy flag should be able to toggle the setting without it disappearing on them.)
4. Announce the removal in Privacy Badger release notes.

And then as part of a release a couple of versions after the next one:

1. Add migration to clear our webRTCIPHandlingPolicy override if set.
2. Blank out any past webRTCIPHandlingPolicy migrations.
3. Remove all WebRTC IP leak logic including the popup message and the legacy flag from storage.
4. Update any and all documentation such as the permissions explainer doc.

I couldn't disagree more. Your link to UBlock origin's issues shows it is not a solution like you suggest. And the other alternative is a Chrome only extension created by one of the foremost abusers of online privacy. So I don't take either suggestion as a serious effort to help users concerned about this issue. More of a way of punting the problem over to the end user and saying "you solve it. we give up".

Why not implement a more robust and easier to understand implementation? You state that users don't understand what the feature does so how do you expect them to use it? Better documentation and a better implementation would make this something that would benefit all Privacy Badger users.

I hear your frustration!

Privacy Badger is meant to be a no-configuration-necessary, better-privacy-by-default kind of tool. We have limited resources and have to be careful about prioritizing what we work on.

The main problem with the WebRTC toggle is that there is no setting of privacy.network.webRTCIPHandlingPolicy that is good to enable by default for all Privacy Badger users.

We won't fully remove the WebRTC toggle for another several months. Look at it this way: Privacy Badger isn't doing the right thing with its WebRTC toggle as it exists now. Now that you know, you can fix this problem. Either you don't actually need a WebRTC limiter tool and so there is nothing to do, or you do^[*], in which case let's try to find a tool that does the right thing for your use case.

Let me know if this helps.

--
[*] Perhaps you use a proxy and want to force all WebRTC traffic to use that proxy and if the proxy is down, WebRTC breaks but that's what you want.

I have arrived here via the very notice posted in the extension, as mentioned above.

PrivacyBadger has had this setting for a very long time. Along the way, other WebRTC 'off' 'buttons' have (now) appeared, e.g. proxy / VPN clients, uBlock origin, and so on.

[Adding GeoIP setting a la https://chrome.google.com/webstore/detail/change-geolocation-locati/lejoknkbcogjceoniealiipllomkpioe or https://chrome.google.com/webstore/detail/change-geolocation/njjpmclekpigefnogajiknnheheacoaj, would as such be a useful enhancement to PrivacyBadger, given the principles above.]

The point of PrivacyBadger has been one-stop shopping of automatic protection for the uninitiated, by an 'independent' trusted 'vendor' such as EFF.

I understand from the comments above that WebRTC is problematic to 'do right'.

There is a Unix principle of do one thing, and do it right.

If WebRTC can't be 'done right', particularly given limited resources, and can't just incorporate other trusted FOSS implementations of WebRTC blocking, then instead referring the user to another 'endorsed' and EFF-trusted/vetted equivalent maintained functionality (and appropriate settings to adjust) - then I believe the original intent of implementing the WebRTC blocking code is well honoured.

There is no point re-inventing the wheel. There is a point of leveraging the one thing done right and done well by pointing such out to users. Perhaps optionally opening that add on page to the obvious 'Add to Chrome' button.

The basic point of Privacy Badger / EFF is the legacy of user trust of endorsed open sourced no cost appropriate functionality. Whether it includes that functionality within itself, or notes its trust of another to implement such functionality - is likely equally acceptable to the end user.

CDN$0.02

Hi Privacy Badger volunteers,

I’m not sure how this actually confused users. It either prevents the leak of your IP address or it doesn’t? Correct? Personally I want the protection, and am against it being removed. Since it’s been indicated that this “persistently confuses users,” how about the below instead.

Checkbox: “Do not leak my Internet facing IP address.”
Popup: This will break some apps.

I (and I’ll assume most users) don’t care what you call the privacy violation, we want it to just stop. The above addresses that clearly and concisely with no ambiguities. Making it on/off should simplify the back-end code to the point that the limited resources you have are not over utilized.

Please reconsider you decision to make the web less safe.

Thank you,
Michael

I’m not sure how this actually confused users. It either prevents the leak of your IP address or it doesn’t? Correct?

We all have a public network IP address and a local/private network IP address. One concern with WebRTC is that it can expose your private network IP address. To help address this concern, various modes of WebRTC IP handling have been standardized and exposed to Web extensions. All modes beyond the default have the potential to degrade and/or break WebRTC applications.

The first problem is that these modes have nothing to do with your public IP address. Users think that this setting offers some sort of VPN-like protection. It does not.

The second problem is that Privacy Badger cannot pick a more strict level for this setting by default for all Privacy Badger users, because this is not a one-size-fits-all situation. This setting should never have been added to Privacy Badger in the first place. Please see my previous post for more on this point.

Let me know if this helps.

I want to help find replacement tools for whoever wants to restrict WebRTC from leaking their local/private network IP addresses. It would help me to know what browser you use and what it is you're looking to achieve.

Hi Alexei,

We all have a public network IP address and a local/private network IP
address.

Yes, this is the topography as I understand it for this context.

PC (local/private IP) <=> Router (public IP) <=> [VPN (exposed public IP)] <=> Internet

One concern with WebRTC is that it can expose your private network
IP address. To help address this concern, [various modes of WebRTC IP
handling](https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handli
ng-01#page-5) have been standardized and exposed to Web extensions. All
modes beyond the default have the potential to degrade and/or break WebRTC
applications.

Agree.

The first problem is that these modes have nothing to do with your public
IP address.

Agree.

Users think that this setting offers some sort of VPN-like
protection. It does not.

The user’s lack of education is beyond the scope of software development. A simple link to Wikipedia solves the responsibility of user education in this instance.

The second problem is that Privacy Badger cannot pick a more private
setting by default for all Privacy Badger users,

Agree.

because this is not a one-size-fits-all situation.

Strongly disagree.

As you say it is not Privacy Badger’s goal to nuance WebRTC settings. My replacement suggestion does not create a default setting for Privacy Badger users. It provides a check box such that IF a user has a VPN like routing with an ‘exposed public IP’ different from the actual ‘public IP’ then WebRTC, and any other similar security threat, is completely disabled in the browser.

Again, user education is the user’s responsibility. EFF/Privacy Badger, by providing a link to Wikipedia, has done due diligence.

This setting should never have been added to
Privacy Badger in the first place. Please see [my previous
post](#2782 (comment)
04682) for more on this point.

I read that post, and every post in this thread, prior to my initial comment. I disagree with it, which is why I posted my comment.

I want to help find replacement tools for whoever wants to restrict WebRTC
from leaking their local/private network IP addresses.

This is why I disagree with removing this function from Privacy Badger. I try to stay current on security issues in my browsers, but the method for ‘turning off WebRTC’ type security issues are constantly changed. This leads to users ending up with a false sense of security as they have found and set some obscure, but working at the time, about:config element in 2019, but that element was removed/changed/modified in 2020 such that, without their knowledge!, they are no longer secure.

One extremely knowledgeable entity keeping track of “don’t leak my ‘public IP’” is much safer and more effective than thousands/millions of individual users trying to do the same.

It would help me to know what browser you use

Daily Driver: Waterfox (w/ HTTPS Everywhere, Privacy Badger, uBlock Origin)
Banking, library, and similar highly identifiable access accounts: Pale Moon
Website work: Vivaldi
Website QA only: Firefox & Chromium (blocked from Internet, w/ no addons [1])
Misc: Opera
YouTube, Google, and anything else known to be sketchy: Tor browser bundle (stock)
Just for fun and to pollute traffic patterns: Whonix

and what it is you're looking to achieve.

To maintain privacy.

WebRTC is one mechanism used to track users. Blocking its functioning seems to be within Privacy Badger policy of ‘block[ing] invisible trackers.’

Thank you Alexei for your time and consideration.

Best Regards,
Michael

[1] As FYI for others: https://serverfault.com/questions/550276/how-to-block-internet-access-to-certain-programs-on-linux

If you use uBlock Origin, you will continue to have access to this functionality through uBlock's "Prevent WebRTC from leaking local IP addresses" setting.

FWIW I've been using https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-disable-webrtc/ and have been pretty happy with it. Yes, it disables WebRTC completely but OTOH the number of websites requiring WebRTC is very low. I only wish the extension gave notifications about when a website tried to use WebRTC. The way it is right now, I sometimes forget that I have WebRTC disabled and end up being surprised that website X is not working.

uBlock Origin is removing their version of this setting too, as apparently your browser should already protect your local IP at this point, so this setting just breaks applications for no benefit.