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

[Justin Uberti <[e-mail]>]

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 <[e-mail]> wrote:

> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <[e-mail]>
> 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
>