Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt

Harald Alvestrand <harald@alvestrand.no> Mon, 12 February 2018 09:26 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDEF1241F5 for <rtcweb@ietfa.amsl.com>; Mon, 12 Feb 2018 01:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 u8LZrEPro9pO for <rtcweb@ietfa.amsl.com>; Mon, 12 Feb 2018 01:26:28 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66061120047 for <rtcweb@ietf.org>; Mon, 12 Feb 2018 01:26:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EB5737C3965; Mon, 12 Feb 2018 10:26:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtGnARDkZkFE; Mon, 12 Feb 2018 10:26:25 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id A971F7C3565; Mon, 12 Feb 2018 10:26:25 +0100 (CET)
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, rtcweb@ietf.org
References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <f3712b9f-f7dd-27b1-a9aa-3c7fceb1008e@cs.tcd.ie>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no>
Date: Mon, 12 Feb 2018 10:26:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <f3712b9f-f7dd-27b1-a9aa-3c7fceb1008e@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="4nJoyJTGL3HTRWQ9ONTp72IPtOxdXt9Zx"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/xXpCNc-10-D0KgvQSebVCaUrb1w>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Feb 2018 09:26:36 -0000

Den 12. feb. 2018 00:24, skrev Stephen Farrell:
> 
> I forget if this was explicitly discussed before. Apologies if
> it was.
> 
> I consider the following text ridiculous:
> 
>    "Mode 1 MUST only be used when user consent has
>     been provided;"
> 
> The reason is that it is not possible for all WebRTC users to
> ever provide real consent to something dealing with which IP
> addresses are used in ICE. So assuming consent is just BS, as
> people cannot provide consent to something they do not understand.
> (And that won't be explained by their systems or s/w.)
> 
> For me, that means that this draft will appear pretty much as a
> fig leaf, intended by us technologists to allow us to pretend
> we're doing the right thing, when we're not. I think that's not
> really that useful.
> 
> Is it really too late to try fix the concept of consent that's
> (ab)used in WebRTC?

I'm sorry, but I don't agree with you on this point.

The decision to go for these modes was based on the theory that if the
user has already consented to the near-perfect tracking abilities that
are implicit in offering a video stream (tracking camera defects, for
instance), and all the information that can be gleaned from a live audio
stream, then the idea of protecting the user against tracking by
restricting access to his IP addresses became of so little value that it
was moot and was worth trading away for better performance of the
functions the user asked for.

Explanations about what the IP address is for and how it is used doesn't
matter in this argument. The point is that the user has already agreed
to a degree of invasion of privacy that a) is perfectly understandable,
and b) is of significantly more significance than what's being discussed
here.

Unfortunately the way in which documents depend on each other, and the
degree to which it's desirable to have each area of concern be described
on its own, make it hard to state this in the document as explicitly as
I do when discussing it.

This thread re-raises an issue that has been hashed over many times, and
I believe the current draft represents the (rough) consensus of the WG
on this matter.

> 
> Even if so, I don't see any reason to make it worse, via this
> draft, and especially via the quoted text above, so I'd argue
> that we ought get rid of that concept from this draft.
> 
> FWIW, I reckon, if implementers liked it, that there is a
> better answer here which is to provide an interface (API and/or
> UI) that allows selected interfaces to be omitted from ICE.

We have that API offered in Javascript already. It's called "skipping
the candidates". But JS API surface helps the JS provider defend against
other attackers; it has no benefit when the JS provider *is* the attacker.

Non-JS-visible APIs discussed have included the ability to specify
"corporate" TURN servers in browser configs and requiring that these be
used. These are typically out of scope for standards; I haven't seen
anything published on whether or not those have been implemented.

> 
> S.
> 
> On 11/02/18 09:00, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF.
>>
>>         Title           : WebRTC IP Address Handling Requirements
>>         Authors         : Justin Uberti
>>                           Guo-wei Shieh
>> 	Filename        : draft-ietf-rtcweb-ip-handling-05.txt
>> 	Pages           : 10
>> 	Date            : 2018-02-11
>>
>> Abstract:
>>    This document provides information and requirements for how IP
>>    addresses should be handled by WebRTC implementations.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05
>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-05
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>