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

If I have understood the looong thread correctly, the issue is that 
Chrome overrides the OS default route and sends the STUN requests via 
all available interfaces, therefore leaking the IP addresses on the process.

AFAIK, that behavior is a Chrome implementation decision (wrong in my 
opinion, but understandable) and it is not specified on WebRTC, so while 
acknowledging the importance of the issue, this is not something that we 
should discuss in this mailing list, except if we decide that we should 
decide to explicitly forbid this behavior and add it to the security draft.

I will send a reply to discuss-webrtc to continue the discussion from a 
Chrome point of view.

Best regards
Sergio

On 17/07/2015 20:36, Justin Uberti wrote:
> The title is somewhat inaccurate, but 
> https://code.google.com/p/chromium/issues/detail?id=457492 is the 
> current bug for this.
> See also https://code.google.com/p/chromium/issues/detail?id=333752, 
> from which the above bug was spun out.
>
> On Fri, Jul 17, 2015 at 11:22 AM, Daniel Roesler <diafygi@gmail.com 
> <mailto:diafygi@gmail.com>> wrote:
>
>     On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti
>     <juberti@google.com <mailto:juberti@google.com>> wrote:
>     >
>     > This is already possible using non-WebRTC technologies, e.g. web
>     sockets. As
>     > such, I don't think that permission should be needed to create a
>     data
>     > channel, or receive (but not send) media.
>     >
>
>     The big difference is that Web Sockets starts off with an HTTP
>     request, so it can be filtered by various plugins (PrivacyBadger,
>     uBlock, Ghostery, etc.). WebRTC is invisible to those services since
>     it does not have any HTTP requests at all. In fact, is WebRTC the only
>     browser standard (i.e. not flash) that can fire off a DNS request
>     that's not (at least at first) for an HTTP address[1]? Lacking an
>     initial HTTP request makes it impossible for plugins to selectively
>     filter these requests, so they have to fall back to an all-or-nothing
>     config setting approach (which hurts WebRTC adoption in
>     general)[2][3].
>
>     > That said, I agree that WebRTC should not allow drive-by
>     harvesting of IP
>     > addresses, and we intend to make changes to Chrome to prevent this.
>
>     Great to hear! Thanks! Is there a bug that is tracking this?
>
>
>     [1]:
>     https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers
>     [2]: https://github.com/EFForg/privacybadgerfirefox/issues/394
>     [3]: https://github.com/gorhill/uBlock/releases/tag/0.9.9.3
>
>     Daniel
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb