RE: ICE exposes 'real' local IP to javascript

Inline

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: den 3 februari 2015 17:42
> To: Tim Panton new; Göran Eriksson AP
> Cc: public-webrtc; rtcweb@ietf.org >> rtcweb@ietf.org
> Subject: Re: ICE exposes 'real' local IP to javascript
> 
> Some thoughts....
> 
> 1) Datachannel is a red herring. There are many ways to do a valid
> CreateOffer with m-lines, which is all that is required:
> 
> - Datachannel
> - OfferToReceiveVideo  / Audio
> - Generate a MediaStreamTrack from WebAudio
> 
> and so on.
> 
> 2) Speaking with my WebRTC hat on: IP addresses have to be surfaced at the
> API as long as the other side needs to try to send packets to these interfaces.
> We can't obfuscate them or encrypt them because they have to be
> communicated to the other party, through channels that aren't in the
> WebRTC spec.
[GAPE:] OK, sure, that would fit in IETF. But CSP/CORS are within the W3C scope, right? For instance, consider using Web platform mechanisms such as CSP; that should be in the scope of the W3C draft, right? Something along the lines Web site admin using CSP/CORS to have the UA 'check' the 'find&connect' proxy origin (especially when it is not in the same 'origin' as that of the parent document)? 
    
> 
> 3) Speaking with my (imaginary) implementors hat: One can imagine a
> (browser-wide) configuration setting for which addresses to allow access to,
> possibly with a whitelist of apps / pages / sites allowed more access than
> others. Normal people will never configure this (and if they tried, they would
> get it wrong), so the defaults need to be "safe enough for most", but
> sysadmins and the people with special reasons to care about security might.
[GAPE:] Hmm, there are such lists around I imagine, :-). But I would prefer leveraging W3C mechanisms for many reasons- these things are subject to regulation in some parts of the world and it often a + to be able to point to an "open standard" not to mention the fragmentation challenges. But yes, it is especially the 'sys admins'  of the Web site owners I am thinking about now.
> 
> 4) Again wearing my WebRTC spec shepherding hat: It seems that the spec
> should make it clear:
> a) that IP addresses will be exposed (in SDP and in oncandidate callbacks)
> b) why IP addresses are being exposed
> but not really anything more than that.
[GAPE:] +1
> 
> 5) Wearing my forum-shuffling hat, it seems that the "why" part belongs
> more in the IETF than in the WebRTC side of things - so I'd favour continuing
> this thread on rtcweb@ietf only....
[GAPE:] It is not one or the other I would say- this concerns the Web platform users security and privacy, hardly a matter only of IETF concern, :-, and again, we should have a second look at Web platform security mechanisms (such as CSP). But apart from that, we should discuss and possible update relevant IETF drafts with at least that info in Your '4'. 

I am not certain that such a discussion will result in any [significant] impact on the UA, perhaps more "BCP'ish" information, but given the importance of considering user privacy and security, I believe it is worthwhile doing- at the very least spend some time on it here, :-).

> 
> Harald
> 
>

Received on Tuesday, 3 February 2015 20:41:41 UTC