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

Justin Uberti <juberti@google.com> Thu, 29 March 2018 04:39 UTC

Return-Path: <juberti@google.com>
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 A393B126C0F for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2018 21:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 tzcWYPf9cJqv for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2018 21:39:44 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 2F798124B0A for <rtcweb@ietf.org>; Wed, 28 Mar 2018 21:39:44 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id v134so2676796vkd.10 for <rtcweb@ietf.org>; Wed, 28 Mar 2018 21:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+pDQnn6IklJ+87bYBp0jVLh2NaYSh0D3jiJY/f7WIE=; b=enm9UMQQmbil+dy1/hOWMoeQSbq2LaQI0engVdZDyo/BNeU3EhssMghDFXSI0UZkf6 tgnL6a0YbVpHrFdFHK1ij85PR5qdKFKMmPd02rssOeud7gWlFcze36o5Ta+SuIhFwgvR n09YPxR5AfHxdEk1FNYpmtMyuNmCLcjbdFvONo9WxvdGDvkWK3y7ZpfTSMCMVtACfQDg zdp9LORzrDmoMrsYRcWJhBiMqwJBGT5dc54iP/g4EK/umVgX+3XLhRfOO8yXMhptvgdq /BeLWtxSPllaNMeUes85wYh+ldiWy2VDpz5WMkWcEVlKP98wCQYq3tYw0nktHVqvmaOy 4fXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X+pDQnn6IklJ+87bYBp0jVLh2NaYSh0D3jiJY/f7WIE=; b=DXK5J2QG8XRXDali+ekn/nI+/LIAmibWF8YhjhZqtMJ0O6x1v9q4n7Jsm21dLr61m/ OXd33seffqvu2xP+lXCQWz72+6s3k9+VeUupFoAG5u4Apa1dTM+mczoUkfHsgLeI+E4+ H2wA6fyLl15pJEK+Go8fUHld115YOTIBqVxgh9P1d/Et0aykU/bw7X0V3t1xKfA8NvyX Bj7fQn4fieDf+1Cwi7dJ0O9Sj3RHoMLukmu9ZB+xZjGUT/QhAPnt6iRjQrnzT8Yd4Fb3 nE1pc62QzL5iQ8ks/3JbgyUMLR2RvYibBDtJfsWJclHEC1h4jFY6O44MPDQNrEcC/tOG 1zhg==
X-Gm-Message-State: AElRT7HiVXq5OeAbyHYoqfhsmFfGvxDnW4z15ANye1OmMbnEoxG71ogk DOnsfqXk+MwsLxq4vB2SikZ/HWPynzHl0Z9ZOffigymb
X-Google-Smtp-Source: AIpwx48R9aAZcaDhDwiNvsQze1nJIfRBOhVI7RtNL0J/upLkppx9x6gJMy1jyPGOKpTudiE2A8A/1HG8YjW3wtOj2d4=
X-Received: by 10.31.223.129 with SMTP id w123mr4236181vkg.9.1522298382700; Wed, 28 Mar 2018 21:39:42 -0700 (PDT)
MIME-Version: 1.0
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> <F313E146-CDAC-4127-8A39-BEA5B8C65327@westhawk.co.uk>
In-Reply-To: <F313E146-CDAC-4127-8A39-BEA5B8C65327@westhawk.co.uk>
From: Justin Uberti <juberti@google.com>
Date: Thu, 29 Mar 2018 04:39:32 +0000
Message-ID: <CAOJ7v-3FhLkEDonvwP7LuCYekbTC9YSeknkzTQxTB6WbvGnWUw@mail.gmail.com>
To: Tim Panton <thp@westhawk.co.uk>
Cc: Cullen Jennings <fluffy@iii.ca>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07dc90588095056885b6b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/PJo3CaYagVwYMcM3b_874SvfAMo>
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: Thu, 29 Mar 2018 04:39:49 -0000

Note that this VPN behavior is not unique to web browsers. Mobile
applications are free to use whichever interface they prefer without
needing any additional user permissions.


On Wed, Mar 28, 2018 at 7:15 AM westhawk <thp@westhawk.co.uk> wrote:

> 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>