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