It is a technical requirement, because the protocol attempts to connect over the local network if both peers are under the same NAT. The local IP is shared so that the peers can attempt to make a local connection.

>> It is a technical requirement, because the protocol attempts to connect over the local network if both peers are under the same NAT. The local IP is shared so that the peers can attempt to make a local connection.

That's an optimization, not a requirement.

A public IP is also leaked when you use a proxy. At least in Chrome, in practice. I don't know if this can be avoided in principle.

I'd assume that this is a rather rare usecase in the world wide web, so why is it not disabled by default?

It is rare in WWW land, but not rare in P2P land.

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.

>You can't even turn it off in the case that you don't want to use WebRTC.

In Firefox, you can easily disable it:

1) Type 'about:config' in your address bar

2) Set 'media.peerconnection.enabled' value to 'false'. (The Default value is 'true')

No, it's not rare. This is something all peer-to-peer networks running over IPv4 must do. WebRTC video, audio, or data wouldn't work without this.

> all

Considering your emphasis, that's a bold claim. Simple to disprove with a single counter-example: Bittorrent does not communicate your internal IP to do its job

Things worked fine before ICE. In fact, stuff like Bittorrent still works fine. If they were truly concerned with connectivity, they'd use upnp. But since that wasn't a standard from a friendly body, they added this ICE hack to try to make things work.

As someone who's implemented a P2P feature for an application: UPnP works great... if you have a router that supports it. Many in the wild do not. If yours doesn't, you have to manually port forward, which, even disregarding the newbie user issue, isn't possible if you're connected to someone else's network. Otherwise, as I assume you know, you can only initiate connections, not receive them, which means you can't talk to anyone with the same limitation - which might not be fatal to your BitTorrent download, albeit limiting your speed, but kinda sucks in something like a one-on-one video chat or game session.

AFAIK, all major video chat applications use some variant of STUN, on which ICE is based, along with some proxying mechanism for users who truly can't connect directly to each other, which corresponds to the rest of ICE.

I don't think upnp is actually an adequate replacement for this even on routers that support it, because many of the older ones don't support NAT hairpinning so even if you open a port on the public IP address using upnp other nodes on the LAN can't connect to it.

Advantages are better chance of connection success for a multihomed device and finding more direct connections (e.g. if you are in the same network as your peer, a direct connection likely is quicker than one which has to go through your internet gateway, and can be established more reliably if you are behind NAT towards the internet)