Re: [rtcweb] New proposal for IP address handling in WebRTC

[Randell Jesup <[e-mail]>]

On 4/22/2015 8:14 PM, Justin Uberti wrote:
> On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     If we turn your proposed behavior on by default, we're doing the
>     equivalent of putting a locked deadbolt on the bathroom window
>     while leaving the front door unlocked, open, and made out of
>     cardboard.
>
>     So I'm all for including this ability as something that users can
>     turn on, and I'd be happy to brainstorm ways to expose this to
>     users in ways other than deep, dark prefs tweaking. But I think it
>     would be a very detrimental overreaction to hobble WebRTC by
>     default just to solve a problem for a tiny fraction of users.
>
>
> I certainly understand this position. But I wonder if we are 
> overestimating the downside and underestimating the upside.
>
> My sense is that any service degradation will be mainly limited to 
> cases where the user is using a VPN for work, and media ends up 
> tunnelled where it would otherwise go direct. But pretty much all the 
> other cases result in the same routing as in our current 
> implementations. And even cases where routing is suboptimal could 
> perhaps be resolved by adding an explicit permission request for full 
> interface access.

Are you thinking of a constraint on new RTCPeerConnection? (or 
createOffer...) Or something separate from a specific PeerConnection, 
since certain patterns will result in the same page making a series of 
PeerConnections (in parallel or series).  We don't want a page to 
repeatedly have to request access...

Of course, #include <user/dialog/blindness>, but it would be (somewhat!) 
safer-by-default, modulo Adam's cardboard analogy limiting the total 
effectiveness.

And of course the point being made here is that there's a difference 
here between successfully fingerprinting someone, and identifying their 
external DHCP address that can lead to a knock on the door. Of course, 
if the attacker is halfway competent, successfully fingerprinting 
someone (without external IP) is most of the work required to knock on 
the door (since you can then take that fingerprint and match it against 
zillions of other records which identify the fingerprint as  Joe Shmoe, 
123 Main St - so the front door really is made of cardboard).

> Regarding upside, these issues are very complex and hard to explain 
> even to technical people unless they have a comms background. This 
> leads to widespread confusion and misleading pronouncements, which 
> could become a headwind for WebRTC adoption.

True - regardless of the facts, if it's seen as "dangerous", it will 
hurt.  Of course, it silently and inexplicably sucking for a major 
(though far from majority) class of users will hurt too.  If there's 
some way to make it not silent about sucking, that would help a lot in 
shifting the balance.  Ideas?

-- 
Randell Jesup -- rjesup a t mozilla d o t com