Re: [rtcweb] Please require user consent for data channels

[Randell Jesup <[e-mail]>]

Note: responding to an older message. Also, Mozilla is planning to land 
a number of optional controls for ICE candidate generation and TURN 
server use.  We also plan to add hooks that extensions can use to prompt 
(depending on circumstance) or monitor 'background' use of 
PeerConnections (without user-granted permission).

On 7/11/2015 12:42 PM, Daniel Roesler wrote:
> One of the items in the new proposal was "WebRTC already requires
> permission to access getUserMedia. Why not use that permission to
> control interface enumeration?" That item didn't really get discussed
> much in the thread, but I think it's one of the most important issues.

In addition to Kaufman's answer, I'll add that this would effectively 
make WebRTC unusable for users - and/or would destroy the utility of 
camera access requests (and WebRTC), due to user request-fatigue.  (If 
you ask a user for permission too many times, especially for something 
they asked to do and the question is about something they don't really 
understand, they either a) always hit yes regardless of the question, or 
b) stop using the feature entirely, because it's too annoying.)

Even camera-access requests are arguably a problem - but the alternative 
(granting permanent permission by default) is itself problematic.

> Why? There is now a documented case where a third party on nytimes.com
> is using a fake webRTC datachannel to silently gather user local (and
> potentially "real" ISP) IP addresses.

Sure, and gathering those for normal users is already trivially possible 
*without* webrtc - external IP's are trivial: whatismyipaddress.com, and 
for LAN addresses you can infer the LAN address with high probability by 
trying to load images from likely gateway addresses 
(192.168.0.1/192.168.1.1/10.0.0.1/etc) to find the likely subnet, and 
then scan the subnet using the same trick, recording the time-to-fail 
for each.  That will map the entire list of devices on the LAN, and you 
may be able to infer from it which address is yours (probably the 
fastest failure).  Note the LAN map itself is often a larger fingerprint 
reveal than the LAN IP address alone.  And yes, I've seen real examples 
of these tricks.

The case this doesn't directly cover fully is the "partial VPN" case, 
where someone has a VPN, but *also* still allows routing out directly 
without going through the VPN.  This is already hugely risky if you're 
trying to maintain anonymity - it's a false sense of security.  However 
it is at least a real concern, as is the "hiding at a shelter" case 
discussed a long time ago, where the issue is exposing external IP's to 
a remote caller (not to the service provider or STUN/TURN server).  I 
will note that there are many ways someone can find your external IP 
address unless you're very paranoid and careful (never load images in 
email, etc).

> So I'd like to voice my support for adding a consent requirement that
> would prevent this type of silent behavior. A user that is
> purposefully visiting a site that has a legitimate reason for using a
> webRTC data channel will have the necessary context to give consent,
> just like they have to get consent on getUserMedia.

You could disable DataChannels and have the same problem, note - this 
would have to apply to all PeerConnections (think of a call with 
offerToReceiveAudio - no gUM request would be made).

> I'm really unclear on why it's so important to have the silent webRTC
> data channel behavior. P2P data connections should be held to the same
> consent requirements just like P2P video and voice connections.

They are.

> In addition to the silent third party local IP tracking, a silent P2P
> data channel opens up users to silently becoming nodes in a web-based
> file sharing network. For example, webtorrent[2] can be silently
> embedded on a website so that all of the users to that website start
> seeding content they don't know they are seeding.

Note we don't require permissions to open WebSockets either.  While 
those don't allow P2P access, downloaded JS can use your CPU for bitcoin 
mining (though not efficiently yet), SETI searches, can store data and 
serve it back to the same (or other) servers, etc.

> 1. Require user consent before calling the callback on createOffer().
> 2. If the user has already given consent via getUserMedia, the user
> consent requirement is satisfied.
> 3. If there's no previous gUM consent, then ask the user for consent.

This could be done technically, and would cover the 
offerToReceiveAudio/Video case.  And there are still ways this could be 
abused, though not as easily.

It would cause people using WebRTC for the advantages DataChannels has 
over WebSockets to be annoyed (such as games).  Anything that benefits 
from UDP-like semantics has cause to use WebRTC/DataChannels, even if 
it's just talking directly to the server, and this would put a huge 
roadblock in the face of such utility.   Web-based games are starting to 
make use of DataChannels, and this would be a real problem for them.

Working around this for access back to the server would require some 
variant of CORS (to bypass the request if it's back to the same origin 
you loaded the page from - and that means you'd make it trivial again 
for the site to find your IPs, which was the reason this was brought 
up).  So that's not really useful.

One thing that *could* be done is to create an option to force such 
requests; we can debate what the visibility of such an option should be, 
and what the defaults should be - but a designed-in option opens the 
door for trivial extensions to change the or to provide UI to expose it 
(either in prefs or in main browser chrome or in a modal popup).  We 
could also flip the pref by default in private browsing mode, though 
that might require in-browser UI since random sites may trigger it.


Speaking to the non-fingerprinting aspects of this which had previously 
been discussed:

I understand your concerns, however the IP address exposure and LAN 
exposure is a red herring (and even more so in IPV6 world), except for 
the "I'm hiding" cases (poorly-configured VPN hiding or hiding from 
another user of the service).  We do surface the ability to not only 
know what PeerConnections are in use, but also that have been in use, so 
you can vet if sites are actually making connections. Right now it 
doesn't list unconnected PeerConnections (used for IP address 
harvesting), but it could.

One could also provide some sort of semi-persistent indicator of such 
background usage without requiring the user to interact with it.  (See 
the hooks I mention at the top of this post.)

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't [e-mail]!  Way too much spam