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

Lennart Grahl <> Wed, 11 April 2018 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74805126CD8 for <>; Wed, 11 Apr 2018 11:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2GBOYjMexQO5 for <>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FB06126C89 for <>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
Received: by with SMTP id r82so5440827wme.0 for <>; Wed, 11 Apr 2018 11:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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? ( [2003:cd:6f24:eb00:3d14:e3e8:2cef:11e2]) by with ESMTPSA id l1sm1062482edi.54.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 11:15:03 -0700 (PDT)
From: Lennart Grahl <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Openpgp: preference=signencrypt
To: RTCWeb IETF <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


>> 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 <>
>> 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 <>
>>> 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