IETF Logo Mail Archive

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

Daniel Roesler <diafygi@gmail.com> Fri, 17 July 2015 18:23 UTC

Return-Path: <diafygi@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73311AD0B0 for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 11:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7xvO5vbXq7W for <rtcweb@ietfa.amsl.com>; Fri, 17 Jul 2015 11:23:00 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0491AD0AC for <rtcweb@ietf.org>; Fri, 17 Jul 2015 11:22:59 -0700 (PDT)
Received: by qkdv3 with SMTP id v3so74792773qkd.3 for <rtcweb@ietf.org>; Fri, 17 Jul 2015 11:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PiUyTW1q29Vs16f9oYcfIs8C4g3IoAwb5dnnC+oGm90=; b=OKvOI1fcFw3hVGBSFF9kDg11+lZgtKgBRXxZnZ5JS7saG7DtXY7opI8Ftj5026t1TT Vr/dVW+zQh9oJHO3zrZ6sVlg7tt/ERnkk/vQYcnCWYIyn/3Bjj+1SFxeUULLRQ7p+hYV P8XlsEDg1FsPnBaysGdtGzUhLzR6SOMMmpjnzjmeKmu00IO+f0W1hhdsgpAcYzV/7A1K g49fH4pfpWdAy69ocNWpSILQIv3ahyoWqekS5vwBALqtUPjRAXNc+/XdfWPnfxue0neD p3K+dU3cNG75ZRph2ajwI7IOb7zf+YbqbNBGYmELC3T+H/TRrb9WRzfwDoZUpvIM3/U4 zY4Q==
X-Received: by 10.55.43.75 with SMTP id r72mr28078414qkh.80.1437157379113; Fri, 17 Jul 2015 11:22:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.108.130 with HTTP; Fri, 17 Jul 2015 11:22:29 -0700 (PDT)
In-Reply-To: <CAOJ7v-0UBGtP0-atxP7X4OTj-H6Lost5o42aAS65mA6CEqcQsw@mail.gmail.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <CAOJ7v-0UBGtP0-atxP7X4OTj-H6Lost5o42aAS65mA6CEqcQsw@mail.gmail.com>
From: Daniel Roesler <diafygi@gmail.com>
Date: Fri, 17 Jul 2015 11:22:29 -0700
Message-ID: <CA+65OsrhXHK+cRAFLCZFt+34vr8eRhj+CN3DgznUBfSwmWYggw@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/ETJFdvFrZukrLJON6ZLJ1uwTw_o>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2015 18:23:02 -0000

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

v2.23.0 | Report a Bug | By Email