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

From: Sean Turner <[email-masked]>
Date: Wed, 7 Mar 2018 14:49:17 -0500

All,

This is the WGLC for the "WebRTC IP Address Handling Requirements” draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.  Please review the draft and send your comments to this list by 2359UTC on 30 March 30 2017.

Thanks,
C/T/S

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Mar 2018 20:12:50 +0000

Hiya,

On 07/03/18 19:49, Sean Turner wrote:
> All,
> 
> This is the WGLC for the "WebRTC IP Address Handling Requirements”
> draft available @
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.
> Please review the draft and send your comments to this list by
> 2359UTC on 30 March 30 2017.

I've raised this previously, so this is, I guess, mostly just
for the record, and I'll likely still be in the rough...

I continue to think it is a bad idea to use the term "consent"
at all, and especially coupled with getUserMedia and with mode
1 having a MUST for using all interfaces based on what I think
is such a bogus concept. There is, IMO, no valid way in which a
person can fairly be considered to have consented to any of this.
I think entwining IETF specifications in the tangled web of web
"consent" (so called) is going in exactly the wrong direction.

Cheers,
S.

> 
> Thanks, C/T/S _______________________________________________ rtcweb
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 7 Mar 2018 12:47:19 -0800

To be clear, the MUST does not say that all interfaces MUST be used if
consent is given, rather the converse, that you MUST only use all
interfaces if there is consent.

In addition, while gUM consent is given as an example, it is not normative.

   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.

On Wed, Mar 7, 2018 at 12:12 PM, Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Mar 2018 21:12:14 +0000

Hiya,

To also be clear: my main objection is to the term consent being
used at all. The stuff below isn't that big a deal, though would
change if the WG did drop the idea of "consent" supposedly being
a real thing.

> interfaces if there is consent.

It's unclear to me that there's any practical difference there.
Are there any implementations that do something else? (Apologies
if that's clear to everyone else:-)

>    mechanism is to tie this consent to getUserMedia consent.

Sure. OTOH, IIUC, that is what's done in web browsers so it kind
of really is normative, in practice. Again, apologies if there
are other things done in browsers.

S.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Mar 2018 14:13:40 -0800

> change if the WG did drop the idea of "consent" supposedly being
So, while I am sympathetic (just generally, really, not just to this), I
think "consent" is basically a term of art in the web world and that its
use in the document is consistent with the more general use.

If you know of a different term of art here that would be similarly
well-understood, I would be glad to know of it.  It may also be an
interesting project to create such a term.  But I don't think the document
should wait on that.

> If I recall correctly, it was not made normative because mobile
applications might use this using advice outside browser contexts.  I can't
find an immediate citation to that, though, so it may be a convenient
reconstruction rather than an accurate memory.

Ted

---

From: Justin Uberti <[email-masked]>
Date: Wed, 7 Mar 2018 14:35:45 -0800

> are other things done in browsers.

I believe that the Brave browser uses Mode 4 in its private browsing mode.
https://github.com/brave/browser-laptop/issues/260

---

From: Justin Uberti <[email-masked]>
Date: Wed, 7 Mar 2018 14:39:15 -0800

On Wed, Mar 7, 2018 at 2:13 PM, Ted Hardie <[email-masked]> wrote:

> On Wed, Mar 7, 2018 at 1:12 PM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
>> Hiya,
>>
Yes, that was one reason; generally, there was squeamishness around
codifying the exact form consent should take in this sort of document
(i.e., an IETF vs W3C recommendation).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Mar 2018 22:51:32 +0000

> https://github.com/brave/browser-laptop/issues/260

Interesting, didn't know that and good to see.

OTOH, still the vast majority of web browsers will I assume
do mode 1 for the vast majority of webrtc calls.

So it's a bit of a fig leaf IMO.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Mar 2018 23:04:38 +0000

Hiya,

> use in the document is consistent with the more general use.
Yes. And there's IMO plenty of reason to not want to be consistent
with that general (ab)use. If we start down that road, I worry that
we'll end up with the moral equivalent of "you looked at my web-page
(possibly whilst ignoring 300 pages of legal crap); therefore you
have already agreed to my T&Cs" which'd be an even worse thing if
attempted/applied at lower layers. To me, this usage matches that
(slightly exaggerated) anti-pattern.

> well-understood, I would be glad to know of it.  

Fair point and a fair ask.

I'll think some more about it, but TBH, I doubt I could come up
with something with a chance of garnering WG consensus. (I don't
think this is just terminology btw - I suspect with any better
term, the modes defined would also have to change.)

If I get inspired, I'll post something. (Hopefully someone smarter
than I and with more WebRTC/STUN clue will get there first:-)

If I don't, and nobody else does, it's fair to consider me in the
rough.

Cheers,
S.

> It may also be an

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Mar 2018 10:57:49 -0600

Theses comments are sent as an individual contributor. 

Let me start by saying I think I am in the rough on the consensus of this draft and I expect the draft to be sent to the IESG with no changes. For the record, as I have said at the floor microphone in the past, I don't agree with the draft. 

This draft results in the situation where implementations decide if they should reveal the users location to the website by asking a questions of the form "Will you allow example.com to use your camera?" If the user says that is OK to use their camera, in many cases they have also allowed the website to get their location via the IP address. From a user point of view, I think this is awful, There are many reasons I might allow a website I do not trust to know my location to access my camera - for example, I have a black cover over my camera and the website won't work unless I say yes to this request. Or a webcam worker where the job involves revealing video but revealing the locations they work at may put them at risk of serious harm. Or I am in a domestic abuse shelter and want to have a call but revealing may location puts me at risk of physical harm. I do not think the IETF should in any way endorse this extremely misleading form of consent. It is simply not consent. I realize this would be good for companies that are primary funded by by web advertising for which location is valuable.

There are several people who's opinion I deeply respect that have looked at this problem in detail. They somewhat agree the above is a problem, but they argue it is better than any alternative design. I disagree with this.The root of the problem we are trying to solve with this draft is that some VPNs are configured to send some packets over the VPN while at the same time some other packets are not sent over the VPN. If you use a VPN configured like this to try and hide your location, WebRTC can end up sending packets not over the VPN and that can reveal your location. I think the right solution to this problem is to acknowledge this is a VPN problem, not a WebRTC problem. If you are using a VPN to hide your location, do not allow that VPN to send packets outside the VPN. I will note most VPNs support this. 

John Morris words from [1], more or less sum up about how I feel about this - just reverse W3C and IETF.

    "By not actually building privacy into the specification, the W3C has  
    both missed a significant opportunity to improve user privacy on the  
    Web, and it has harmed the efforts of another standards body -- the  
    IETF -- to protect location privacy and to improve the privacy  
    paradigm for Internet services."

From a process point of view: 1) I have had time to express this opinion in the rtcweb WG meetings and it has been discussed. My read of the consensus in the room is that I am in the rough on this topic  2) I don't think the rtcweb WG is the WG in the IETF with the most expertise in VPNs

Thanks, Cullen

As FYI, the actual questions that are asked by today's browsers are roughly the following:

In firefox: "Will you allow webrtc.github.io to use your camera?"

In chrome: "webrtc.github.io wants to use your camera"

In safari: "Allow webrtc.github.io to use your camera?"

In edge: "Let webrtc.github.io use your webcam?”

[1] https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html

> On Mar 7, 2018, at 7:49 PM, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Mar 2018 18:15:27 +0100

On 27/03/18 17:57, Cullen Jennings wrote:
> Let me start by saying I think I am in the rough on the consensus of
> this draft and I expect the draft to be sent to the IESG with no
> changes. For the record, as I have said at the floor microphone in
> the past, I don't agree with the draft.
As I said also on the list in the past, I fully agree with Cullen
but also think we're both in the rough.

The only thing I'd add is that I also think having any concept of
"consent" in IETF protocol specifications at this layer or below
is also a bad precedent.

S.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 27 Mar 2018 10:35:07 -0700

Question as chair:

On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings <[email-masked]> wrote:

>
> There are several people who's opinion I deeply respect that have looked
> at this problem in detail. They somewhat agree the above is a problem, but
> they argue it is better than any alternative design. I disagree with
> this.The root of the problem we are trying to solve with this draft is that
> some VPNs are configured to send some packets over the VPN while at the
> same time some other packets are not sent over the VPN. If you use a VPN
> configured like this to try and hide your location, WebRTC can end up
> sending packets not over the VPN and that can reveal your location. I think
> the right solution to this problem is to acknowledge this is a VPN problem,
> not a WebRTC problem. If you are using a VPN to hide your location, do not
> allow that VPN to send packets outside the VPN. I will note most VPNs
> support this.
>
>
The document's current description of this problem is:

       If the client is multihomed, additional public IP addresses for
       the client can be learned.  In particular, if the client tries to
       hide its physical location through a Virtual Private Network
       (VPN), and the VPN and local OS support routing over multiple
       interfaces (a "split-tunnel" VPN), WebRTC will discover not only
       the public address for the VPN, but also the ISP public address
       over which the VPN is running.

Would adding a statement such as "Users desiring maximum privacy should
avoid split-tunnel configurations when they are in control of that
configuration" help?

Ted

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Mar 2018 12:54:32 -0500

[as an individual]

On 3/27/18 12:35 PM, Ted Hardie wrote:
> Would adding a statement such as "Users desiring maximum privacy 
> should avoid split-tunnel configurations when they are in control of 
> that configuration" help?

I think the value of adding *application* *user* guidance to an RFC is 
of questionable value under pretty much all circumstances, fully 
analogous to adding "safe driving" tips to ASTM's automotive standards. 
I wouldn't spend too much time wordsmithing words that will never reach 
their intended audience.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Mar 2018 12:18:13 -0600

> On Mar 27, 2018, at 11:35 AM, Ted Hardie <[email-masked]> wrote:
> 
> Question as chair:
> 
> On Tue, Mar 27, 2018 at 9:57 AM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Would adding a statement such as "Users desiring maximum privacy should avoid split-tunnel configurations when they are in control of that configuration" help?  
> 
> Ted

I think proposal along those lines had been rejected in the past by WG. The problem is we get in arguments about if it should say something like your suggestions or something more like “Users desiring location privacy must not use split-tunnel VPN configurations with WebRTC”. As you know, this is not a case of just noticing something new in WGLC, this problem and argument has been considered by the WG and I think Stephen and I are in the rough. 

I do appreciate you trying to find some middle ground here

---

From: Lennart Grahl <[email-masked]>
Date: Wed, 28 Mar 2018 03:49:59 +0200

> This draft results in the situation where implementations decide if they should reveal the users location to the website by asking a questions of the form "Will you allow example.com to use your ca…

I agree with you here and this is most likely the reason why WebRTC is
on the blacklist of many privacy extensions for browsers.

However, I believe there could be a form of consent in the browsers -
tell them what you actually want to do: Expose (all) private IP
addresses to create a direct connection. Yes, getting users to
understand what it means to "establish a direct connection" may not be
trivial - granted. But it's much more sincere AND it would not
discriminate data channel only use cases (yeah, it's really shady to
request capture permissions to be able to use mode 1).

And FWIW I'm not sure this form of consent fits into the scope of the
IETF. Maybe the modes could be defined in this document and which mode
to choose under which circumstances could be moved into the W3C WebRTC spec.

Cheers
Lennart

---

From: westhawk <[email-masked]>
Date: Wed, 28 Mar 2018 15:14:54 +0100

I tend to agree with Cullen here, this is an issue. (As I said when I first raised it way back when).

It is bad practice to ask a user one (clear) question and the deduce
their agreement to some other things that aren’t (at least to the user) related.

Conversely an infinite series of questions before each call isn’t going to
work either,

With that in mind, perhaps we are hanging off the wrong existing consent.
Given that the VPN users in question are (in practice) trying to hide their location,
perhaps that’s the dialog we should hang off instead.

“This page would like to use your location: allow, deny”
would also unlock public IP address access.

Tim.

> On 27 Mar 2018, at 17:57, Cullen Jennings <[email-masked]> wrote:
>

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 28 Mar 2018 20:37:09 +0200

Am 27.03.2018 um 18:57 schrieb Cullen Jennings:
[...]
> I disagree with this.The root of the problem we are trying to solve with this draft is that some VPNs are configured to send some packets over the VPN while at the same time some other packets are not sent over the VPN. If you use a VPN configured like this to try and hide your location, WebRTC can end up sending packets not over the VPN and that can reveal your location.

Isn't the problem that some VPNs promise you to hide your location while 
actually operating in split mode?

> I think the right solution to this problem is to acknowledge this is a VPN problem, not a WebRTC problem. If you are using a VPN to hide your location, do not allow that VPN to send packets outside the VPN. I will note most VPNs support this.

I find it somewhat interesting that the narrative among "hide my 
location" VPN vendors is still "webrtc exposes you" and not "oh, you are 
using $competitors product? here is your real location. We can protect 
you for a modest fee".

IIRC initially there was also an actual issue in Chrome where is leaked 
UDP candidates when a socks proxy was set (which is how tor operates). 
This was bad has been fixed pretty quickly.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 29 Mar 2018 04:39:32 +0000

Note that this VPN behavior is not unique to web browsers. Mobile
applications are free to use whichever interface they prefer without
needing any additional user permissions.

On Wed, Mar 28, 2018 at 7:15 AM westhawk <[email-masked]> wrote:

> this draft and I expect the draft to be sent to the IESG with no changes.
> For the record, as I have said at the floor microphone in the past, I don't
> agree with the draft.
> >
> > This draft results in the situation where implementations decide if they
> should reveal the users location to the website by asking a questions of
> the form "Will you allow example.com to use your camera?" If the user
> says that is OK to use their camera, in many cases they have also allowed
> the website to get their location via the IP address. From a user point of
> view, I think this is awful, There are many reasons I might allow a website
> I do not trust to know my location to access my camera - for example, I
> have a black cover over my camera and the website won't work unless I say
> yes to this request. Or a webcam worker where the job involves revealing
> video but revealing the locations they work at may put them at risk of
> serious harm. Or I am in a domestic abuse shelter and want to have a call
> but revealing may location puts me at risk of physical harm. I do not think
> the IETF should in any way endorse this extremely misleading form of
> consent. It is simply not consent. I realize this would be good for
> companies that are primary funded by by web advertising for which location
> is valuable.
> >
> > From a process point of view: 1) I have had time to express this opinion
> in the rtcweb WG meetings and it has been discussed. My read of the
> consensus in the room is that I am in the rough on this topic  2) I don't
> think the rtcweb WG is the WG in the IETF with the most expertise in VPNs
> >
> > Thanks, Cullen
> >
> >
> > [1]
> https://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0020.html
> >
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.  Please
> review the draft and send your comments to this list by 2359UTC on 30 March
> 30 2017.
> >>
> >> Thanks,
> >> C/T/S

---

From: Balwant Bisht <[email-masked]>
Date: Thu, 29 Mar 2018 13:59:34 +0530

All VPN setup are not for hiding location, but some are setup to allow
remote users to connect to company network. If MCU server is inside VPN and
browser didn't get VPN candidates then its not possible to establish
PeerConnection with MCU. Also linking it with device access is bad, e.g. if
participants joining a webinar and they didn't want to give access to
devices, they will not be able to join at all.

Regards
Balwant Bisht

On Thu, Mar 29, 2018 at 10:09 AM, Justin Uberti <
juberti=[email-masked]> wrote:

>> > This draft results in the situation where implementations decide if
>> they should reveal the users location to the website by asking a questions
>> of the form "Will you allow example.com to use your camera?" If the user
>> > There are several people who's opinion I deeply respect that have
>> looked at this problem in detail. They somewhat agree the above is a
>> problem, but they argue it is better than any alternative design. I
>> disagree with this.The root of the problem we are trying to solve with this
>> draft is that some VPNs are configured to send some packets over the VPN
>> while at the same time some other packets are not sent over the VPN. If you
>> use a VPN configured like this to try and hide your location, WebRTC can
>> end up sending packets not over the VPN and that can reveal your location.
>> I think the right solution to this problem is to acknowledge this is a VPN
>> problem, not a WebRTC problem. If you are using a VPN to hide your
>> location, do not allow that VPN to send packets outside the VPN. I will
>> note most VPNs support this.
>> >
>> > From a process point of view: 1) I have had time to express this
>> opinion in the rtcweb WG meetings and it has been discussed. My read of the
>> draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-
>> handling/.  Please review the draft and send your comments to this list
>> by 2359UTC on 30 March 30 2017.
>> >>
>> >> Thanks,
>> >> C/T/S

---

From: Balwant Bisht <[email-masked]>
Date: Thu, 29 Mar 2018 13:59:34 +0530

Regards
Balwant Bisht

On Thu, Mar 29, 2018 at 10:09 AM, Justin Uberti <
juberti=[email-masked]> wrote:

>> With that in mind, perhaps we are hanging off the wrong existing consent..
>> this draft and I expect the draft to be sent to the IESG with no changes..

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 29 Mar 2018 17:34:03 +0200

On Wed, 28 Mar 2018 03:49:59 +0200
Lennart Grahl <[email-masked]> wrote:

> > they should reveal the users location to the website by asking a
> > questions of the form "Will you allow example.com to use your
> > camera?" If the user says that is OK to use their camera, in many
> > cases they have also allowed the website to get their location via
> > the IP address. From a user point of view, I think this is awful,
> > There are many reasons I might allow a website I do not trust to
> > know my location to access my camera - for example, I have a black
> > cover over my camera and the website won't work unless I say yes to
> > this request. Or a webcam worker where the job involves revealing
> > video but revealing the locations they work at may put them at risk
> > of serious harm. Or I am in a domestic abuse shelter and want to
> > have a call but revealing may location puts me at risk of physical
> > harm. I do not think the IETF should in any way endorse this
> > extremely misleading form of consent. It is simply not consent. I
> > realize t  
>  his would be good for companies that are primary funded by by web
> advertising for which location is valuable.
> 

And let's not forget we're not just talking of discriminating data
channels, here. As someone else already pointed out, this would affect
recvonly audio/video PeerConnections as well. Requiring access to
a local device to implement those would be a very hacky solution (and
in fact Safari, which currently does something like this, is horrible
in that regard), especially considering that, just as for data channels,
there would be no need to require access to your webcam if you just
wanted to attend a webinar and never say anything yourself. It would
actually have the effect of looking even shadier to end users ("why
exactly do you want to access my webcam? I'm just trying to watch
something here!"), just as it would for datachannel-only PCs, and
further reduce the trust people would have in WebRTC as a technology.

As Lennart said, a different popup that says something like "this page
wants to create <something>" would be a much better solution. Yes,
another UI knob or something like this, but still much better than
abusing the only consent request we currently expose simply because
it's, again, the only we have and we don't want to annoy users too much.

Lorenzo 

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2018 23:03:40 +0200

> it's, again, the only we have and we don't want to annoy users too much.

Completely agreed with Lorenzo. Asking for "mic/webcam access" to get
full IP access and then not using the mic/webcam (because the app just
wants to receive media or run a datachannel) is a hacky and ugly
solution.

Please, just add a new prompt to ask for full IP access and save such
a setting per origin (same as getUserMedia when HTTPS). That's all.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 29 Mar 2018 21:21:10 +0000

This notion of sites asking for device access just to get a full set of IP
addresses has been discussed many times, but I am not aware of any cases of
this happening in the real world.

If the user is on a VPN and trying to contact a MCU that is on the VPN,
Mode 2 (no devices access needed) will do the right thing, assuming HTTP
traffic is being routed correctly.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Mar 2018 14:29:12 -0700

Stephen Farrell said:

"So it's all a bit of a fig leaf IMO."

[BA] Correct me if I'm missing something, but there are a class of abusive
applications that don't even pretend to support realtime communications and
don't call getUserMedia (probably so as not to give the user an inkling of
what they are up to).

So while there is some leeway to argue about the meaning of "consent" for
an application that actually utilizes the WebRTC APIs for communications
between browsers, there are a class of abusive applications that don't
fulfill even the most liberal definition of "consent".

---

From: Justin Uberti <[email-masked]>
Date: Thu, 29 Mar 2018 22:02:58 +0000

Correct, and I think there are two distinct scenarios being conflated in
this discussion.
1) Web pages who aren't using WebRTC for communication, and therefore don't
call getUserMedia (Bernard's scenario)
2) Web pages who are using WebRTC for communication, and typically do call
getUserMedia.

This document attempts to prevent sites in scenario 1) from having access
to all IP addresses, and I believe does so successfully.

There is of course the question of whether sites in scenario 2) should have
access to all IP addresses. Some observations:
1) This problem is not specific to web browsers. Existing mobile apps
already have access to all IP addresses.
2) The 'right' behavior here is situation-dependent. As an example, should
a user on a VPN send their media traffic over the VPN or not? One can
construct a valid rationale for either position.
3) In the event where specific behavior is desired, this document does
provide specific modes to allow browsers or extensions to select the
desired behavior.

As such, I believe a full treatment of scenario 2 is out of scope of this
document, and the existing options presented in the document are sufficient.

On Thu, Mar 29, 2018 at 2:29 PM Bernard Aboba <[email-masked]>
wrote:

> On Wed, Mar 7, 2018 at 2:51 PM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
>>

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 30 Mar 2018 05:48:42 +0200

> document, and the existing options presented in the document are sufficient.

I would agree with you that the document is sufficient when it comes to
the modes it provides (even though the clever mDNS experiment Apple runs
at the moment might be worth adding to mode 2 and 3 if proven
successful). But the more I think of it, the less I agree with the
"consent" part of the document, especially this particular statement:

> [...] one potential mechanism is to tie this consent to getUserMedia
consent

It's a "potential mechanism" that has been gladly accepted by all
browser vendors, let's face it, probably because it's easy and it seemed
to work well for many use cases. But it's showing its weaknesses:

1. It discriminates various use cases (just one example: a peer-to-peer
file sharing application using data channels, potentially in the same
network), and
2. assumes the user is okay with mode 1 when the application gets
capture permissions. Cullen pointed out that this may be a false
assumption in some cases.

Now, even though the document states that mode 2 SHOULD be used if no
consent has been given (and that would be fine for the majority of use
cases I have in mind), we're already seeing browsers going for mode 3
when no "consent" is available. But the only form of "consent" we have
at the moment is getUserMedia. That makes it a problem for the use cases
that simply cannot utilise those permission requests. And the impact of
being forced to NAT hairpinning or even TURN can be much higher than it
would be for an audio/video conference. Thus, the implementations in the
browsers based on the suggestion in this document already hinder some
interesting use cases.

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?

Cheers
Lennart

---

From: Sean Turner <[email-masked]>
Date: Fri, 30 Mar 2018 18:12:08 -0400

> On Mar 29, 2018, at 23:48, Lennart Grahl <[email-masked]> wrote:
> 

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 30 Mar 2018 18:12:08 -0400

spt

---

From: Lennart Grahl <[email-masked]>
Date: Sat, 31 Mar 2018 12:17:55 +0200

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

---

From: Lennart Grahl <[email-masked]>
Date: Sat, 31 Mar 2018 12:17:55 +0200

Camera to share:
[WebCam 3000 |v]
:WebCam 3000   :
:WebCam 4000   :

[Don't allow] [Allow]

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Sat, 31 Mar 2018 22:26:50 +0000

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.

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

On Sat, Mar 31, 2018 at 3:18 AM Lennart Grahl <[email-masked]>
wrote:

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

---

From: Lennart Grahl <[email-masked]>
Date: Sun, 1 Apr 2018 01:47:52 +0200

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

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

---

From: westhawk <[email-masked]>
Date: Sun, 1 Apr 2018 01:12:14 +0100

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 <[email-masked]> wrote:
>