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

[T H Panton <[e-mail]>]

Concretely could we adjust :
" Mode 1 MUST only be used when user consent has been provided. The
   details of this consent are left to the implementation; one potential
   mechanism is to tie this consent to getUserMedia consent."

to: 
 " Mode 1 MUST only be used when a user's informed consent has been provided.  The
   details of this consent are left to the implementation; one potential
   mechanism is to tie this consent to one of the the existing getUserMedia/location-access consents.
  Alternatively implementations can provide a separate mechanism to obtain user consent"

- I'm no GDPR specialist, but I think adding 'informed' above may be wise.
Likewise I believe even the non-normative language should be clearer about the possible implementation choices.

Tim.

> On 1 Apr 2018, at 01:12, westhawk <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb