Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

westhawk <thp@westhawk.co.uk> Wed, 28 March 2018 14:15 UTC

Return-Path: <thp@westhawk.co.uk>
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 4919912711E for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2018 07:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 0uaZ5a-KML2h for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2018 07:14:58 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC7F12711B for <rtcweb@ietf.org>; Wed, 28 Mar 2018 07:14:57 -0700 (PDT)
Received: (qmail 23257 invoked from network); 28 Mar 2018 14:14:55 -0000
X-APM-Authkey: 255286/0(159927/0) 1465
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 28 Mar 2018 14:14:55 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 91E4118A029F; Wed, 28 Mar 2018 15:14:55 +0100 (BST)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jk5DPsJFRxYO; Wed, 28 Mar 2018 15:14:55 +0100 (BST)
Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6D2D218A016C; Wed, 28 Mar 2018 15:14:55 +0100 (BST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: westhawk <thp@westhawk.co.uk>
In-Reply-To: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca>
Date: Wed, 28 Mar 2018 15:14:54 +0100
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F313E146-CDAC-4127-8A39-BEA5B8C65327@westhawk.co.uk>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/nCR0dCMvLqudFDxdgk1RIH0msX4>
Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling
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: Wed, 28 Mar 2018 14:15:01 -0000

I tend to agree with Cullen here, this is an issue. (As I said when I first raised it way back when).

It is bad practice to ask a user one (clear) question and the deduce
their agreement to some other things that aren’t (at least to the user) related.

Conversely an infinite series of questions before each call isn’t going to
work either,

With that in mind, perhaps we are hanging off the wrong existing consent.
Given that the VPN users in question are (in practice) trying to hide their location,
perhaps that’s the dialog we should hang off instead.

“This page would like to use your location: allow, deny”
would also unlock public IP address access.

Tim.


> On 27 Mar 2018, at 17:57, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> Theses comments are sent as an individual contributor. 
> 
> Let me start by saying I think I am in the rough on the consensus of this draft and I expect the draft to be sent to the IESG with no changes. For the record, as I have said at the floor microphone in the past, I don't agree with the draft. 
> 
> This draft results in the situation where implementations decide if they should reveal the users location to the website by asking a questions of the form "Will you allow example.com to use your camera?" If the user says that is OK to use their camera, in many cases they have also allowed the website to get their location via the IP address. From a user point of view, I think this is awful, There are many reasons I might allow a website I do not trust to know my location to access my camera - for example, I have a black cover over my camera and the website won't work unless I say yes to this request. Or a webcam worker where the job involves revealing video but revealing the locations they work at may put them at risk of serious harm. Or I am in a domestic abuse shelter and want to have a call but revealing may location puts me at risk of physical harm. I do not think the IETF should in any way endorse this extremely misleading form of consent. It is simply not consent. I realize this would be good for companies that are primary funded by by web advertising for which location is valuable.
> 
> There are several people who's opinion I deeply respect that have looked at this problem in detail. They somewhat agree the above is a problem, but they argue it is better than any alternative design. I disagree with this.The root of the problem we are trying to solve with this draft is that some VPNs are configured to send some packets over the VPN while at the same time some other packets are not sent over the VPN. If you use a VPN configured like this to try and hide your location, WebRTC can end up sending packets not over the VPN and that can reveal your location. I think the right solution to this problem is to acknowledge this is a VPN problem, not a WebRTC problem. If you are using a VPN to hide your location, do not allow that VPN to send packets outside the VPN. I will note most VPNs support this. 
> 
> John Morris words from [1], more or less sum up about how I feel about this - just reverse W3C and IETF.
> 
>    "By not actually building privacy into the specification, the W3C has  
>    both missed a significant opportunity to improve user privacy on the  
>    Web, and it has harmed the efforts of another standards body -- the  
>    IETF -- to protect location privacy and to improve the privacy  
>    paradigm for Internet services."
> 
> From a process point of view: 1) I have had time to express this opinion in the rtcweb WG meetings and it has been discussed. My read of the consensus in the room is that I am in the rough on this topic  2) I don't think the rtcweb WG is the WG in the IETF with the most expertise in VPNs
> 
> Thanks, Cullen
> 
> 
> As FYI, the actual questions that are asked by today's browsers are roughly the following:
> 
> In firefox: "Will you allow webrtc.github.io to use your camera?"
> 
> In chrome: "webrtc.github.io wants to use your camera"
> 
> In safari: "Allow webrtc.github.io to use your camera?"
> 
> In edge: "Let webrtc.github.io use your webcam?”
> 
> 
> [1] https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html
> 
> 
> 
>> On Mar 7, 2018, at 7:49 PM, Sean Turner <sean@sn3rd.com> wrote:
>> 
>> All,
>> 
>> This is the WGLC for the "WebRTC IP Address Handling Requirements” draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.  Please review the draft and send your comments to this list by 2359UTC on 30 March 30 2017.
>> 
>> Thanks,
>> C/T/S
>> _______________________________________________
>> 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