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

Lennart Grahl <lennart.grahl@gmail.com> Wed, 11 April 2018 18:15 UTC

Return-Path: <lennart.grahl@gmail.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 74805126CD8 for <rtcweb@ietfa.amsl.com>; Wed, 11 Apr 2018 11:15:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2GBOYjMexQO5 for <rtcweb@ietfa.amsl.com>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 6FB06126C89 for <rtcweb@ietf.org>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id r82so5440827wme.0 for <rtcweb@ietf.org>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:references:openpgp:to:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nFR/CWao/t/tQe8+8chska0tJtacjXjJt5k/5fRqNW0=; b=vCoudc7w+7II8XeVh0y+Y5rHTo20PSYZeuXELCUuoV65FzqLY64PNp4eQooCd8sDka 2DY6I2jqOJie8FsEM3/OOY2qoONu8dyqd/9kCeRNCBdTG/aUrDAC6I+jepO8ikPxeEqQ W6irePyno+0W97cLl2rBiwJjtqSN4DLUrXJCO49oLcasJHw78mvka3JRHUwdZFW+ULxV qgdTyRdRzd8qiT4Whi3zzk0Jo3q76GFJiB5ztL+2X2klX+akiR70AWVobx2FJYVvkHgJ wKJ5ekTcIONpLKSh0ahZ0oQLwIjZwbEmXzNChdk2GnuOFfBDkJL5vcg0CB1/TPdPeAKn sWrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:references:openpgp:to:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nFR/CWao/t/tQe8+8chska0tJtacjXjJt5k/5fRqNW0=; b=ThEbESfHOX66CpZ2WquS0Bt2XpMM+KCZcpjred8tOf/dxGvarVxm3M5J/Hwpx65/5E hUc3Wz+U0jucozwyqIxPNy86VIiwIu87/84yRRf7XbzdVCWOJyrCAhzs1UyWsta3s/pA AhS5+kHvAY8K6wHvpE4/t3CMI+Sj53qeFDqvChakBVW00Iofh1/j7HFlLaUisIkJgW/D MR7SYcRvS6P2fn6SN3ebU63AgsCAjoSmLqmfC/UNXAWf+N/tED0eIIJlw7z2YyjvXXr5 UJyxJrBHQdRXxJyRY9Hl1a+WGggZWcA2FUjXdTxHvSEu5GTYa3He95s2CbJb7txa0RtI FhTw==
X-Gm-Message-State: ALQs6tBpcsJhTOQcfCWcSbK1byCUWaqPnoNYyOGh5ruhDImiInZL9sCK NlYJJ7OWUJv8vFCdJOM358iPlQ==
X-Google-Smtp-Source: AIpwx4/1LjTDKihgEBJzcyWk2nBcDi58bU3mKROz5RiZ2HrtA0AAyIiRwolRL73o8yshBjvNBeopfg==
X-Received: by 10.80.166.99 with SMTP id d90mr11049401edc.53.1523470504463; Wed, 11 Apr 2018 11:15:04 -0700 (PDT)
Received: from ?IPv6:2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2? (p200300CD6F24EB003D14E3E82CEF11E2.dip0.t-ipconnect.de. [2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2]) by smtp.gmail.com with ESMTPSA id l1sm1062482edi.54.2018.04.11.11.15.03 for <rtcweb@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 11:15:03 -0700 (PDT)
From: Lennart Grahl <lennart.grahl@gmail.com>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <63282b84-4493-3fcb-a95f-4afe17d96bb6@cs.tcd.ie> <CAOJ7v-1gTq+EEjb+-q-T-pABBW--rpNGegoj_d2_7f7AKGksCA@mail.gmail.com> <403713b4-31d4-9085-d639-d3f60935ed5a@cs.tcd.ie> <CAOJ7v-0ED-FK=JmSxBJYfM=PCdgY6kmbiq6aFLcP7OXugG07EA@mail.gmail.com> <e6938f7d-542d-736b-0a3d-9269d7dd06e5@cs.tcd.ie> <CAOW+2dv1ORz2tEkgDTvdM1DtgyOdgXqKU30T4QhLAp1NT+rirg@mail.gmail.com> <CAOJ7v-0tCcg3FdzyfSJ6Y3JaH-TivFf-Sey6+tD8BANJKsjqtQ@mail.gmail.com> <1fceb3c4-35f3-34f7-de1d-79d5805e6d22@gmail.com> <9517D601-D3E8-46E1-94E5-7EC29FD6319B@sn3rd.com> <b5d323ac-2205-2aee-05c9-f270e80215f5@gmail.com> <CAOJ7v-0+hr-NddbLCwgjkfyEFEzoLYW8BcE5OYZ+HUiqDRnarg@mail.gmail.com> <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com>
Openpgp: preference=signencrypt
To: RTCWeb IETF <rtcweb@ietf.org>
Message-ID: <06252a76-f12e-4d8d-4a07-5240a7605bce@gmail.com>
Date: Wed, 11 Apr 2018 20:15:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <0dee004d-159a-a9be-a0b8-ecbfd4204d72@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Nc2zSuNUCPSYyTSSMcWO3hNY6-Y>
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, 11 Apr 2018 18:15:08 -0000


On 01.04.2018 01:47, Lennart Grahl wrote:
> On 01.04.2018 00:26, Justin Uberti wrote:
>> As stated before, this is not a problem unique to web browsers. That is, by
>> installing a mobile application, you implicitly allow it to use all of your
>> network interfaces. As such, trying to design browser mechanisms for
>> networking consent seems like misdirected effort.
> 
> First of all, that comparison doesn't really work for me since an app is
> much less of a sandbox. So, I personally do not trust arbitrary websites
> but I do trust apps that I install (or I just don't install them, or I
> partially trust them and revoke some of the permissions they have).
> 
> It's all about expectations: WebRTC networking is special - it does
> networking entirely different to what people were accustomed to in
> browsers. Which is probably why people are so irritated when they learn
> that it leaks IPs even though they've set a proxy or a VPN. And along
> with the argument that gUM just does not work for a bunch of use cases,
> that is the rationale for my suggestion towards a networking "consent"
> mechanism. With that mechanism in place the user has a voice, we cover
> more use cases, browsers can ship stricter modes by default without
> breaking everything we love about peer-to-peer connections and privacy
> extensions might consider dropping WebRTC from their blacklist. I
> honestly do not see this as being terribly misguided.

Since I haven't seen a satisfactory response so far, let me rephrase
this as a question: Can anyone explain to me why that approach is not
considered a valid alternative to getUserMedia?

Cheers
Lennart

> 
>> Perhaps the key issue here is the word 'consent'. If we replaced this with
>> some notion of 'trust', i.e., that the user has specifically engaged with
>> this app with the intent of having a communications session, maybe that
>> provides a way out, as one can easily claim that installed mobile
>> applications and web apps with gUM rights are 'trusted'.
> 
> I'm sorry but I don't really see the difference. gUM requests a
> permission to access your camera and your microphone and then assumes
> you're "trusting" the page for something different as well.
> 
>>
>> On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl <lennart.grahl@gmail.com>;
>> wrote:
>>
>>> I really don't have a good suggestion other than being completely
>>> honest: "Hey user, I want to establish a direct connection - is that
>>> okay for you? Oh, and here is a help page that will tell you what impact
>>> this may have on your privacy..."
>>>
>>> These permission requests don't have to be mutually exclusive either.
>>> The above request could also be embedded inside the permission request
>>> for getUserMedia to avoid multiple requests:
>>>
>>> Camera to share:
>>> [WebCam 3000 |v]
>>> :WebCam 3000   :
>>> :WebCam 4000   :
>>>
>>> Direct connection: (?) <-- "help" button
>>> [No (Default)                    |v]
>>> :Yes                               :
>>> :Yes, but hide private addresses   :
>>> :No (Default)                      :
>>> :No, and force using a proxy       :
>>>
>>> [x] Remember the decision for this page
>>>
>>> [Don't allow] [Allow]
>>>
>>> Cheers
>>> Lennart
>>>
>>> On 31.03.2018 00:12, Sean Turner wrote:
>>>>
>>>>
>>>>> On Mar 29, 2018, at 23:48, Lennart Grahl <lennart.grahl@gmail.com>;
>>> wrote:
>>>>>
>>>>> I'm fine with the modes, I don't have a strong opinion on whether or not
>>>>> an IETF document should include some form of "consent". But I do have a
>>>>> problem with the suggestion to use getUserMedia. Can we maybe remove it?
>>>>
>>>> As the draft shepherd, I’m trying to figure out how to draw this WGLC to
>>> a close all in the hopes that we can help each other get this RTCweb WG
>>> ship docked.
>>>>
>>>> As far as dropping the getUserMedia suggestion, I’m a little hesitant to
>>> just drop it at this late date.  That suggestion has been in the draft
>>> since October 2016 and it’s stood the test of a couple of WG reviews; not
>>> last calls mind you but there’s been plenty of time for folks to say get
>>> that outta there.  And technically, it’s just a suggestion with no
>>> normative language.  So … maybe a happy middle ground is to have another
>>> suggestion so that there’s more than one potential mechanism?
>>>>
>>>> spt
>>>>
>>>
>>