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

[Lennart Grahl <[e-mail]>]

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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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
>>>>
>>>
>>