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

[westhawk <[e-mail]>]

GuM permission is the wrong trust measure here.

So for example, If I use webRTC to get a realtime feed from a webcam/ baby monitor
then I won’t use GuM, all my recv_only video traffic will go via a TURN server
even if I’m on the same Wifi ?

Likewise if I use webRTC DC to control my lighting, I get extra latency because
I don’t need GuM?

(Both of these are real projects).

My current workaround is to use the camera to scan a QR and piggyback off
that permission. (Which is crazy).

The IP address reveal is unrelated to the UserMedia.
It is a ‘Trust/location' issue.

Also - if GuM permission was granted for this origin, does this mean that 
subsequent page loads that _don’t_ request GuM don’t get local candidates
even if they would get GuM if they asked for it?
(i.e. if I’ve once scanned a QR on this domain, do I always reveal my local/public IPs?)

Try explaining the logic of any of that to anyone outside this group….

Tim.

> On 1 Apr 2018, at 00:47, Lennart Grahl <[e-mail]> 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.
> 
>> 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
>>>> 
>>> 
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb