Should WebRTC Data Channels be Explicitly Approved by the User?

03/08/2015

I don’t think so.

WebRTC's nefarious nature?

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:

Daniel Roesler #106:

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.

Eric Rescorla #116:

We are considering adding an extension to restrict the use of WebRTC but are still studying what would be most effective.

Zack Weinberg (:zwol) #117:

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:

  1. IP leakage
  2. 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.

Responses

Lennie says:
August 3, 2015

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/

Reply
    Lennie says:
    August 3, 2015

    Instead of waiting for when I have time to look at it, I made time to look at IPv6, privacy and WebRTC. I used this site for testing: https://diafygi.github.io/webrtc-ips/ I had a Ubuntu VM with Firefox 39 and Chrome 43. For some strange reason Firefox didn’t communicate any IPv6 addresses. And Chrome only communicated the temporary (privacy extension) IPv6 addresses. So I think your (Ethernet MAC) privacy is safe with IPv6 and WebRTC on Ubuntu.

    And tested the same thing on Windows 7 and Firefox doesn’t seem to send any IPv6 again. But Chrome 44 on Windows 7 sends all IPv6-addresses, including the Ethernet MAC-derived IPv6-address which means you can use WebRTC to track users on the web !

    Reply
Sergio Garcia Murillo says:
August 3, 2015

The problem is not specific to datachannels, it is due to ICE in both STUN/TURN and consent request that leaks all public IP addresses when using a VPN.

You can get the same behaviour with an recvonly SDP for audio/video that doesn’t require user conset either.

Having said that, the answer is not to screw webrtc UX by another user approval window, but by addressing how ICE works and adding more control to that behaviour on the browsers settings, as Chrome or Firefox has startign to do already.

Reply
    Shachar says:
    August 13, 2015

    The problem is neither Datachannels nor ICE.
    If you’re using a VPN for privacy, that VPN should be configured correctly and take into account new web API’s.
    Proper configuration will leave the STUN adress with the VPN channel’s remote address only and not the user’s true ip.

    Reply
Alfred says:
August 3, 2015
Reply
Michael Gorham says:
August 7, 2015

Remember the FUD surrounding cookies?
https://www.docketalarm.com/cases/PTAB/IPR2014-00039/Inter_Partes_Review_of_U.S._Pat._6628314/10-09-2013-PET-812/Exhibit-1010-Jackson,_T,_Media_Futures_This_bug_in_your_PC_is_a_smart_cookie,_Financial_Times_February_12,_1996/

However, I think the FUD surrounding a traceable IP fingerprint has some validity. Why not show a domain based, one-time request dialog with a way to allow the developer to explain why they want to use data channels? Something similar to the javascript onbeforeunload event …
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload

This would both educate the public about the security issue at hand and allow whitelisting of certain domains. Data channel CDNs or similar use cases could apply to browser vendors to be default whitelisted similar to the Firefox screen share API’s default whitelisted domains.

Reply
    Lennie says:
    August 7, 2015

    You think cookies are FUD ? They clearly can be used both for good and evil.

    Reply

Comment