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

What you describe is the proper operation of RFC5245, so this isn't a
Chrome implementation decision (Firefox behaves the same way, and I assume
Edge will as well).

However, we have been thinking about whether refinements to the behaviors
specified in RFC5245 are warranted in the web context.

On Fri, Jul 17, 2015 at 12:11 PM, Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>  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>
> 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>
> wrote:
>
>> On Fri, Jul 17, 2015 at 11:04 AM, Justin Uberti <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 listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>