- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 03 Feb 2015 17:42:01 +0100
- To: Tim Panton new <thp@westhawk.co.uk>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
- CC: public-webrtc <public-webrtc@w3.org>, "rtcweb@ietf.org >> rtcweb@ietf.org" <rtcweb@ietf.org>
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.... Harald
Received on Tuesday, 3 February 2015 16:42:34 UTC