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

[Justin Uberti <[e-mail]>]

On Mon, Apr 20, 2015 at 8:51 AM, Adam Roach <[e-mail]> wrote:

> On 4/20/15 00:49, Justin Uberti wrote:
>
>> We now propose a new mechanism that attempts to address these issues. The
>> new mechanism works like the previous mechanism, but during the candidate
>> generation process, we call getsockname to obtain the local IP address of
>> the interface used to talk to the STUN/TURN server. This obtains a *single*
>> interface IP, which allows the browser to avoid trombone routing, but also
>> minimizes the amount of IP information revealed to JS. Furthermore, the
>> STUN traffic continues to go out the default route, meaning that if a VPN
>> is used, the 'real' public address is still not disclosed. (Naturally, this
>> has some performance implications, as a user may not always want their
>> media to go out the VPN.)
>>
>
> I think this is an incremental improvement on the previous proposal that
> is worth adding.
>
>
>  As this mechanism should alleviate the primary security concerns with
>> interface enumeration, with relatively small impact on user experience, we
>> propose that this be the default for browsers.
>>
>
> Okay, you had me until here.
>
> The idea about choosing the address that we would use to route to a TURN
> server makes some assumptions about network architectures that don't hold
> in the general case. For those users who are willing to accept increased
> latency (sometimes), decreased quality (sometimes), and reduced connection
> rates (sometimes) in exchange for obscuring certain aspects of their
> network configuration, that's probably okay. You're making things slightly
> worse, but for a real benefit. Well, a real benefit for those specific
> users.
>
> The problem is that, despite the noise and fury that's resulted from this
> issue, the number of users for whom it is a real concern is an
> infinitesimally small fraction of those people who will ever use a web
> browser. And I'm not okay with taking an across-the-board service
> degradation for all users based on something that the overwhelming majority
> of them won't care about.
>
> I'll repeat what I said at the mic in Dallas: for users looking for the
> level of obscurity that you're proposing to provide, WebRTC isn't the only
> concern with regards to modern web browser operation. To get this correct
> requires a vast amount of work, and it's not something that anyone is
> likely to get right by themselves, regardless of level of ability. You need
> a comprehensive approach, such as that described at <
> https://www.torproject.org/projects/torbrowser/design/>. To really get
> this correct, you usually need to have someone take care of the heavy
> lifting for you, which means running something like TorBrowser
>
> 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.

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.