Re: [rtcweb] Please require user consent for data channels

[Sergio Garcia Murillo <[e-mail]>]

Hi,

While acknowledging that there might be a potential privacy issue, I 
don't think agree on your analysis on the issue that you have made nor 
your proposal.

The information available in the ICE gathering process and made 
available to the JS app is the following:

-Host candidates, mostly private IP addresses
-Server reflexive candidates, exposing the public IP address as shown by 
the TURN/STUN server
-Relay candidates, hosted by the TURN server

My understanding of the issue is that the leak happens when the 
application is able to retrieve information not already available to it.
That happens either when the user is using a VPN and have multiple 
public IP addresses or using an external PROXY so the http/ws connection 
have a different originator public IP address. AFAIK there should be no 
potential danger in leaking the private IP4 addresses (here you got 
mine, in case you are interested 127.0.0.1 and 192.168.64.2 ;). I have 
not much background on IPv6, so please complete any missing info and how 
would it affect here.

I don't think it is a good idea to tight the solution of requesting user 
permission, to not leak IP information, as theoretically a user could be 
interested in using webrtc (audio/video/datachannels) and still don't 
disclose their public IP address (i.e. forcing all the data to go via a 
TURN server).

One possible solution would be that the browser don't gather/announce 
host&reflexive candidates when an HTTP proxy is set, and only use turn 
relay candidates instead. The second solution (which I think it is 
already discussed somewhere else) would be to allow the user to 
configure a TURN server to override the app settings and force all 
connection to go through it. (Then build a chained-TURN infrastructure 
into TOR and you could have a killer combo ;)

Regarding the issue that the browser becomes a CDN peer, not sure if 
anyone has ever raised the issue before. From my point of view, there is 
not, but in any case, I think it is orthogonal to the leak issue.

Best regards
Sergio



On 11/07/2015 18:42, Daniel Roesler wrote:
> Howdy all, this is mostly a re-surfacing of the discussion about IP
> address leaking back in April[1], which unfortunately I did not
> discover until recently.
>
> One of the items in the new proposal was "WebRTC already requires
> permission to access getUserMedia. Why not use that permission to
> control interface enumeration?" That item didn't really get discussed
> much in the thread, but I think it's one of the most important issues.
>
> Why? There is now a documented case where a third party on nytimes.com
> is using a fake webRTC datachannel to silently gather user local (and
> potentially "real" ISP) IP addresses.
>
> https://twitter.com/incloud/status/619624021123010560
>
> So I'd like to voice my support for adding a consent requirement that
> would prevent this type of silent behavior. A user that is
> purposefully visiting a site that has a legitimate reason for using a
> webRTC data channel will have the necessary context to give consent,
> just like they have to get consent on getUserMedia.
>
> I'm really unclear on why it's so important to have the silent webRTC
> data channel behavior. P2P data connections should be held to the same
> consent requirements just like P2P video and voice connections. In
> addition to the silent third party local IP tracking, a silent P2P
> data channel opens up users to silently becoming nodes in a web-based
> file sharing network. For example, webtorrent[2] can be silently
> embedded on a website so that all of the users to that website start
> seeding content they don't know they are seeding.
>
> Possible fix:
>
> 1. Require user consent before calling the callback on createOffer().
> 2. If the user has already given consent via getUserMedia, the user
> consent requirement is satisfied.
> 3. If there's no previous gUM consent, then ask the user for consent.
>
> This implementation requires no updates to current webRTC demos, since
> you have to wait for a callback on createOffer anyway. I'm open to
> other ways, such as making createDataChannel asynchronous like gUM,
> but that would require updates to existing apps that use
> createDataChannel.
>
> Thanks!
> Daniel Roesler
>
> [1]: https://www.ietf.org/mail-archive/web/rtcweb/current/msg14494.htm
> [2]: https://github.com/feross/webtorrent
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb