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

Lorenzo Miniero <lorenzo@meetecho.com> Thu, 29 March 2018 15:34 UTC

Return-Path: <lorenzo@meetecho.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 4310312D95F for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2018 08:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it
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 lpuCbSOj5GdX for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2018 08:34:06 -0700 (PDT)
Received: from smtpcmd10101.aruba.it (smtpcmd14161.aruba.it [62.149.156.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6E312711B for <rtcweb@ietf.org>; Thu, 29 Mar 2018 08:34:05 -0700 (PDT)
Received: from lminiero ([93.44.67.253]) by smtpcmd14.ad.aruba.it with bizsmtp id Tra31x00P5TrUJd01ra36B; Thu, 29 Mar 2018 17:34:04 +0200
Date: Thu, 29 Mar 2018 17:34:03 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Lennart Grahl <lennart.grahl@gmail.com>
Cc: rtcweb@ietf.org
Message-ID: <20180329173403.78d6efde@lminiero>
In-Reply-To: <ce205a81-64c8-f2d0-8dea-0ce9f1f1c5de@gmail.com>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> <ce205a81-64c8-f2d0-8dea-0ce9f1f1c5de@gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1522337644; bh=o68gxYFFPI57an1XKnwAEXwfugnHOdMbMHIMf70VIQc=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=mUOlcTIvRkZcuGFYSwWZm7aJsnM+M+M6HQsKcHWM2r7BnR7KKMkn8sNW8GlmC2CpD WanjbLN/ysx8tQFBoWiRBOJs++H5SbPv6axqllIU/LlXrSWqeXPx0M3fhT00RTRrRP Tc2KqHU/WasUGS9px0uDNUQABsxnuZ64jkKU+EWPEioGMvrP3dadH2uDmLIAlhbz5u jiIadf2HxvHxR8cT9/Y/6gg3HWGe7iqZXx6JI31w7ePlNqwt3wQEMk/6zuUvcvRwaC oHDqeR5RjgawehdVCTVykSGdNFY3Rl/NHUCPwtRmUdJOd//FPDoN3ZgVP9XM+fI+5E cBavscV3w8Nlg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/L_jmWcdW7yvTwNKlP7OA25FvYs4>
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 15:34:09 -0000

On Wed, 28 Mar 2018 03:49:59 +0200
Lennart Grahl <lennart.grahl@gmail.com> wrote:

> On 27.03.2018 18:57, Cullen Jennings wrote:
> > 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 t  
>  his would be good for companies that are primary funded by by web
> advertising for which location is valuable.
> 
> I agree with you here and this is most likely the reason why WebRTC is
> on the blacklist of many privacy extensions for browsers.
> 
> However, I believe there could be a form of consent in the browsers -
> tell them what you actually want to do: Expose (all) private IP
> addresses to create a direct connection. Yes, getting users to
> understand what it means to "establish a direct connection" may not be
> trivial - granted. But it's much more sincere AND it would not
> discriminate data channel only use cases (yeah, it's really shady to
> request capture permissions to be able to use mode 1).
> 


And let's not forget we're not just talking of discriminating data
channels, here. As someone else already pointed out, this would affect
recvonly audio/video PeerConnections as well. Requiring access to
a local device to implement those would be a very hacky solution (and
in fact Safari, which currently does something like this, is horrible
in that regard), especially considering that, just as for data channels,
there would be no need to require access to your webcam if you just
wanted to attend a webinar and never say anything yourself. It would
actually have the effect of looking even shadier to end users ("why
exactly do you want to access my webcam? I'm just trying to watch
something here!"), just as it would for datachannel-only PCs, and
further reduce the trust people would have in WebRTC as a technology.

As Lennart said, a different popup that says something like "this page
wants to create <something>" would be a much better solution. Yes,
another UI knob or something like this, but still much better than
abusing the only consent request we currently expose simply because
it's, again, the only we have and we don't want to annoy users too much.

Lorenzo 

 
> And FWIW I'm not sure this form of consent fits into the scope of the
> IETF. Maybe the modes could be defined in this document and which mode
> to choose under which circumstances could be moved into the W3C
> WebRTC spec.
> 
> Cheers
> Lennart
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero