I don’t think so.
There have been at of chatter lately about the NY Times and local IP address use. A rather old Mozilla bug got some attention due to it, with some interesting comments:
I’ve said this before and I’ll say it again. Data channels should require user consent just the same as video and audio (getUserMedia). I haven’t yet heard a good reason on why a silent P2P data channel connection is required.
We are considering adding an extension to restrict the use of WebRTC but are still studying what would be most effective.
I would like to second this observation. I have not attempted to dig into the details of the spec, but it *sounds* like the entire problem goes away if creating any sort of channel requires explicit user authorization.
The rants go on.
What they all share in common? Leak of IP addresses is wrong and shouldn’t be done. Not without a user’s consent.
I’d like to break the problem into two parts here:
- IP leakage
- Consent
IP leakage
The issue of leaking a local IP address is disconcerting to some. While I understand the issue for VPN configurations, I find it a useless debate for the rest of us.
My own local IP address at the moment is 10.0.0.3. Feel free to store this information for future dealings with me. Now that you know it – have you gained anything? Probably not.
Oh, and if you have a mobile phone, you probably installed a bunch of apps. These apps are just as complex as any web page – it connects to third parties, it most likely uses an ad network, etc. How hard is it to get the local IP address inside an app and send it to someone else? Do you need special permissions to it? Do users actually approve it in any way? Do you think the NY Times app uses this for anything? How about Candy Crush? Or Angry Birds?
Local IPs are compromised already. Everywhere. They are easy to guess. They are easy to obtain in apps. Why is the web so different? And what huge secret do they store?
Consent
When someone wants access to my camera, microphone or screen – I understand the need for consent. I welcome it.
But when it comes to the data channel I am not so sure. There are differences here. My thinking about it runs in multiple paths.
1. Content
Microphone, Camera and Screen actually give new data to Java Script code to work with. The Data Channel is a transport and not the data itself.
The browser doesn’t ask permission to download 50+ resources from a web page when we only asked for the web page. It doesn’t ask for permission when 40+ of these resources are located at other domains than the one that we asked for. It doesn’t ask for permission when a web page wants to open a WebSocket either. It doesn’t ask for permission when a web page tries to generate other bidirectional methods to connect to our browser – SSE or XHR – it just runs it along.
As we are trying to protect content, permission on the data channel level seems unnecessary.
If we want to protect local IP address exposure, we should find other means of doing that – or accept that in many use cases, they aren’t worth the protection.
2. User experience
For a video call, a request to allow access is fine – there’s a human involved. But for a programmatic interface that’s a bit of an overkill. With many WebRTC data channel use cases targeting CDN augmentation or replacement, would users be willing to take the additional approval step? Would content providers be willing to take the risk of losing customers?
Let’s assume GIS and mapping on the internet adopts the WebRTC data channel – similar to what PeerMesh are doing. Would you be happy with the need to allow each and every web page that has a Google Map on it to have access to the data channel?
Would you want your games to ask you to allow connecting to others when switching to multiplayer?
Do you want Akamai (a CDN) powered websites to ask you to allow them to work to speed up page loads?
This doesn’t work.
Stop thinking about the data channel as a trojan horse – it is just another hammer in our toolbox.
3. Web trends
In many ways, we are at a phase where we are trying to decentralize the web – enabling browsers to reach each other and to dis-intermediate the servers from the communications. FireChat is doing it for awhile now, but they are far from being alone in it.
This kind of decentralization cannot work properly without letting browsers chat sideways instead of via web servers. While we may want in the future to make such connections as low level TCP and other network building blocks, this isn’t the case today.
We need to find other solutions than placing a permission request on every data channel we try opening.
Why is it important?
We need to be able to distinguish between FUD and reality.
Data channels by themselves aren’t a threat. They may change the way browsers operate on the network level, which may expose vulnerabilites, but the solution shouldn’t be disabling data channels or putting manual roadblocks to them on the browser – it should be in better architecting the solution around them.
As WebRTC grows and matures, these issues will be polished out. For now, I still believe WebRTC is the most secure VoIP technology out there to build your services. Trust, on the other hand, will always depend on the web service’s developers.
I don’t think people are happy about what smartphone apps do either. 😉
CDN on a general webpage is so far the only use-case I’ve seen which needs data-channels without consent.
Every other data-channel use-case I’ve seen is some kind of ‘app’. For example if you are going to play a game (which could need data-channels) and it asks for some extra permissions, it’s … do-able.
Some people will want to have some kind of way to control which IP’s are sent. I think browser vendors will have to create an API for extension creators or some preferences for it.
Sorry, I’ve been really busy. But I really want to take a look if browsers leak IPv6 information which can be used to track people around the web. See my comment on the NY Times post: https://bloggeek.me/webrtc-new-york-times/#comment-114343
Currently it’s less than 8% worldwide of website visitors has IPv6. But this will and has to grow.
For example IPv4 in the ARIN region (which is mostly the US and Canada) is running out today. See the counters on the right side of these webpages:
https://www.arin.net/resources/request/ipv4_countdown.html
https://ipv6.he.net/statistics/