“We are considering adding an extension to restrict the use of WebRTC”

It's probably a billion dollar business by now.

Cases like the one I described could actually help by giving users plausible deniability, but that would just end with browser developers being pressured into disabling the feature.

Note: this is a simplified explanation. Some details are glossed-over/wrong. But it will give you the basic idea. In order for someone to be able to talk to your machine they need to know your IP address. In general, this if fine because you can just tell people your IP address. However if you are on an internal LAN then you have the same external IP address as everybody else on the LAN. There needs to be a way to route packets to you.

A P2P application needs to have some way of telling the outside world, "If you want to send packets to me, this is how to do it". Of course, LANs are designed to stop people from being able to randomly send packets from outside the LAN to machines inside the LAN for obvious security reasons. So if you do this, then you are compromising the security of your LAN to a certain degree.

As I said, P2P apps need the ability to advertise how to connect to you or else you can only connect outwards. In other words, if it were a telephone, you could make outgoing calls, but couldn't receive incoming calls because nobody knows where you are. So when you start up Skype or Bittorrent, etc, it usually uses some tricks to figure out how people can contact you and advertises it.

The problem with WebRTC is not so much that it has this capability -- it needs it. The problem is that it is accessible remotely and doesn't ask for permission. You can go to a website that will jam some javascript at you that gets this information.

You can't even turn it off in the case that you don't want to use WebRTC. Requests to change the functionality to prompt the user (or at least have an option to prompt the user) when this functionality is used has been turned down. Not a lot of coherent reasoning has been given (as far as I can tell), but I imagine that the implementation is difficult and they don't think the majority of users will care.

I suppose as a middle-ground they have offered this plugin. I have my own strongly held beliefs on this topic (which may be evident from what I wrote), but hopefully this is neutral enough that you can understand the issue, do some reading and form your own opinion.

uBlock is an adblocker, uMatrix has finely grained matrix controls for which http requests are even allowed to go through and requires tuning for most sites. I like having both :)

If you attack scenario is trying to circumvent authoritative governments, don't use a web browser with extra features or plugins like WebRTC turned on.

"Hiding a users 's true IP at all costs who are using a VPN" is not a reasonable design expectation for mainstream browsers. They are fixing bugs and adding features. This is an extreme edge case at best for them.

There are already forced opt-ins for accessing the microphones and cameras, this should probably be fully extended to require the user to opt-in when any WebRTC feature is used.

192.168.1.10

Based on this, you can probably guess the router is 192.168.1.1 and maybe even have a clue about the vendor based on the IP assigning patterns.

Then you can direct them to a page with an submitting POST <form> that makes modifications to their router settings. This is more like CSRF than XSS though.

With that said, now let me express an opinion (not a fact): for every technological innovation there are downsides and upsides, and it's up to people to decide if the greatness makes up for the (potential) problems. With cell phones for instance, most people accept potentially having their location disclosed to the accuracy cell towers and triangulation allow, because it's super damn convenient to be able to place and receive calls and text from just about anywhere. Of course, there's a minority that is not comfortable with this and refuses to use cell phones or takes extra precautions.

Similarly, people may be willing to accept the problems of WebRTC because its applications are enough to make up for the disadvantages. People who don't accept will find ways to not use it. If the majority of users ends up blocking it, we can conclude that people don't want a peer-to-peer web, but a more sensible conclusion will be that people were not OK with that particular implementation of peer-to-peer networking, and a different implementation is in order, or that at least patches to the current implementation are needed.

> Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies.

I think that most likely, these data-scarfing companies (and other parties) will learn to use WebRTC (as it is now) for nefarious purposes, before it hurts a tiny bit of their bottom line. I bet it's much easier and there is much more immediate monetary support for developing the pieces necessary to track users with WebRTC, than to implement an actual peer-to-peer application with it.

IPv6 with its built in true end-to-end connectivity just called and wants to have a word with you, but you were stuck behind some inferior IPv4 NAT blockade.

I won't even go into the debate of whether or not we want "the web" to be the support for the p2p network of the future.

> Peer-to-peer networking is the web's big chance to weaken these huge personal data-scarfing companies.

On the other hand, this particular problem is another ace in the hands of those huge personal data-scarfing companies.