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.

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.

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.

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....


Received on Tuesday, 3 February 2015 16:42:34 UTC