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

[Lennart Grahl <[e-mail]>]

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.

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