Re: [rtcweb] ICE exposes 'real' local IP to javascript

On 2/4/2015 3:53 AM, tim panton wrote:
>> On 4 February 2015 at 16:47, Harald Alvestrand<harald@alvestrand.no>  wrote:
>>> We have discussed this before, and concluded that a confirmation dialog
>>> makes no more sense than having a confirmation dialog for performing an
>>> XHR request or opening a Websocket - neither of which requires
>>> confirmation dialogs today.
> Yes, but I don’t think we considered the VPN-for-privacy angle at that point.
> Xhr and Websockets don’t reveal all the local IP addresses - just the one that is configured
> to be used, or indeed no local IPs if the user has elected to use a http(s) proxy.

I think no local IPs are disclosed by that, only external IPs (and in 
that case the external IP of the far-end of the VPN I presume). The 
local address (in non-VPN case) is an extra bit (bits) of fingerprinting 
info, though likely not generally needed to identify which machine 
behind a NAT is talking - other factors (fonts, etc) work fine for 
distinguishing in most cases.

<jesup elides a recitation of the entire fingerprinting discussions from 
the past...>


>> Yes.  Every time something like this comes up, someone inevitably
>> suggests that asking users is an acceptable way to deal with it, as if
>> somehow that transfers the responsibility for solving the problem onto
>> users.  Even if we could communicate the risks effectively, which I
>> don't believe we can, I still wouldn't be in favour of a dialog.

I agree.

>> There are two concerns here:
>> 1. fingerprinting - for which I believe the only recourse is to
>> disable the feature.  The combination of device enumeration and SDP
>> provides a fairly rich surface even without IP addresses.

See above, though device enumeration is supposed to be blocked until 
consent is granted to limit drive-by fingerprinting.  There are other 
techniques that are more powerful, however.

>> 2. exposure of privacy-VPN users.
>>
>> This latter is what people seem most concerned with at this point in
>> time.  And I'm not against someone building options into their browser
>> to manage this.  That, or, if the VPN is for privacy-preserving
>> purposes, the interfaces that are potentially revealing could be
>> disabled.  Neither option requires action by this group.
> I disagree, we should at least document the risk, and in my view we should
> recommend the provision of a browser configuration mechanism to disable specific interfaces from appearing in ICE.

Document it - yes!  Provide a way to disable it - ok, probably. Also 
(per many discussions) provide a way to force only relay candidates for 
location anonymity from callers (but not from sites) (protection orders, 
stalkers, etc).

Configuration options for specific interfaces: way, way too involved 
even for moderately technical users.

I would suggest addons/extensions to browsers be available targeted for 
people who want a "VPN mode" or "Privacy mode" to give them additional 
controls/whitelists/notifications for this (and perhaps other things).  
Also, if you really want a secure VPN, it should be set up in the 
router, or use a VPN that blocks all non-VPN interfaces.

Such browser extensions can have a nice user-visible toggle for VPN 
mode, whitelists if they want, big red warning boxes if something tries 
to use WebRTC, ways to mark "only use this interface if it's available", 
perhaps even automatic VPN detection for your specific VPN, etc.  This 
is exactly this sort of thing extensions are made for (and 
sub-communities they're made for).

> In case folks are assuming this is an obscure issue, I’d point out that there is a pretty common use-case for privacy VPNs/proxies: watching domestic IPTV when traveling.
> Whilst we don’t want to condone license infringements it would be a shame if folks turned off webRTC just when they needed it most :-)

That's probably the #1 use of VPNs; and I suspect most content providers 
don't go to this length to de-anonymize VPN users.  Not saying none 
would, but I'd guess most wouldn't care enough.  If they do, see above 
(and use a better VPN setup too).

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

Received on Thursday, 5 February 2015 21:00:09 UTC