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

From: T H Panton <[email-masked]>
Date: Sun, 1 Apr 2018 12:32:37 +0100

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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>
>>> 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 <[email-masked]>
>>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 1 Apr 2018 12:51:15 +0100

Hiya,

> - I'm no GDPR specialist, but I think adding 'informed' above may be wise.

Luckily, I'm also not a GDPR specialist:-)

But I think adding "informed" takes this further from reality and so is
worse. (Further from reality in terms of me just not believing that ICE
is understandable for a random user, and therefore consent of any kind
to doing iCE, isn't possible, so informed consent is even less
possible;-)

In general I'm not sure wordsmithing will help here - I reckon those of
us in the rough (well, me at least), have a fundamental problem with
the current state of implementations and with the basic idea in the
draft so I don't think any simple wording change can solve that. (I'm
not saying that to be difficult but to avoid us all wasting time
thinking we can solve the problems via wordsmithing.)

Cheers,
S.

---

From: westhawk <[email-masked]>
Date: Sun, 1 Apr 2018 13:51:28 +0100

> On 1 Apr 2018, at 12:51, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Giving literal consent is somewhat frowned on these days - hence ‘informed'.

> to doing iCE, isn't possible, so informed consent is even less

Ah, that’s where we disagree. We don’t have to explain ICE -
(frankly almost no-one understands ICE
not even those of us who have implemented it.)
Just like we don’t explain the detailed risks of giving camera permissions.

But I do think we can give a better hint at what the area of risk is, fundamentally:
"do you trust this website with your (network) location?”

Whilst some of the detailed risks are shared with
“do you want to use your camera?” Not enough of them are IMHO.

> thinking we can solve the problems via wordsmithing.)

Mmm, I think we differ, I’d rather give wordsmithing a try before we go back to square 1.

T.

> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 1 Apr 2018 14:26:29 +0100

> Giving literal consent is somewhat frowned on these days - hence ‘informed'.

This [1] captures my understanding of informed consent pretty well. In
particular where it says: "An informed consent can be said to have been
given based upon a clear appreciation and understanding of the facts,
implications, and consequences of an action."

That's the kind of definition we use when considering research ethics.

It's unclear to me why some other definitions might apply in a case
like WebRTC in browsers that will affect many many more people.

Cheers,
S.

[1] https://en.wikipedia.org/wiki/Informed_consent

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Apr 2018 13:42:01 -0700

> like WebRTC in browsers that will affect many many more people.

This is the standard term of art. I believe we should leave it as-is

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Apr 2018 07:55:16 -0600

All the stuff we are discussing here has been brought up and discussed in the WG. If there was a way we could tweak the words of this to be better, I think we would have already done that. What I don’t want to do is spend a bunch of time rehash old arguments and several months from now come to exactly where we are today. The wording has been tweaked many times. The browsers added APIs so that browser extensions could have better control over what happened. Thick apps have access to all this same data. 

I don’t agree with some parts of the draft but I do recognize that the WG had consensus that the current document covers the issues and I am just in the rough on this. I think most the WG feels that the current draft is the best possible choice and the browser have done what they can to mitigate this. That’s why I tried to make it clear in my email that I don’t expect this draft to change because of my concerns, but I am simply noting my disagreement. I do not think that spending a bunch more time discussing this would in change the outcome from what the draft currently says. 

Cullen

---

From: T H Panton <[email-masked]>
Date: Tue, 3 Apr 2018 10:14:26 +0100

In case anyone thinks this issue will go away if we ignore it:

https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ <https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/>

T.

> On 2 Apr 2018, at 14:55, Cullen Jennings <[email-masked]> wrote:
> 
>

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 3 Apr 2018 15:17:32 +0200

> https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/ <https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/>

It turned out the issue in this case is
a) browser extensions that add a proxy server calling themselves a "VPN"
b) said browser extensions being unaware of the Chrome Extension API to 
set mode 4 which prevents UDP from being used if a proxy server is set.

See https://voidsec.com/vpn-leak/ for the original article. Its 
interesting research and shows that the actual problem is not VPNs in 
split mode as I had assumed.

---

From: Andy Hutton <[email-masked]>
Date: Tue, 3 Apr 2018 15:56:47 +0100

On 3 April 2018 at 14:17, Philipp Hancke <[email-masked]> wrote:
>> https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/
>> <https://www.theregister.co.uk/2018/03/29/almost_a_quarter_of_vpns_tested_leak_ip_addresses/>
>
>
> b) said browser extensions being unaware of the Chrome Extension API to set
> mode 4 which prevents UDP from being used if a proxy server is set.
>

The reference to mode 4 forced me to read that part of the draft again
and now I have a question:

In the description of mode 4
*https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2)
what is meant by "or the WebRTC implementation does not support UDP
proxying"?

Does "UDP Proxying" refer to the return proxy mechanism, a network
specific TURN server, or something else?

Andy

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Apr 2018 14:52:34 -0600

> On Apr 3, 2018, at 3:14 AM, T H Panton <[email-masked]> wrote:
> 

I’d phrase that as 77% of VPNs are not broken and here is a simple WebRTC test to find out if your VPN is totally broken. Note that if it is broken for WebRTC, is is also broken for non WebRTC apps like Skype. I will not that since that article was published, the guys that did the tests has updated the data at https://voidsec.com/vpn-leak/ and now only 83% of the VPN are not broken. It clear that VPN providers are fixing this problem.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 04 Apr 2018 04:59:04 +0000

On Tue, Apr 3, 2018 at 7:56 AM Andy Hutton <[email-masked]>
wrote:

> >> <
> set

UDP proxying refers to any technique that allows the browser to tunnel UDP
through a proxy, which would include RETURN, and possibly other types of
proxies (QUIC?) in the future.

---

From: Lennart Grahl <[email-masked]>
Date: Wed, 11 Apr 2018 20:15:01 +0200

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Apr 2018 12:10:59 -0700

> considered a valid alternative to getUserMedia?

[BA] When considering alternative consent models you have to ask if the user will understand what they are being asked to consent to. For getUserMedia (or getDisplayMedia) it is relatively clear: access to a device or to the screen.  But for WebRTC or ORTC, what would you request permission for and when and how would you explain this to the user? Asking permission for object construction probably isn’t viable. So would you ask for permission to create a data channel? To apply a local or remote description? To create a certificate?  What if an application created multiple peer connections? How many prompts would be required for a 20 person conference?

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Apr 2018 15:10:32 -0500

[as an individual]

> considered a valid alternative to getUserMedia?

I think you're not getting a lot of response here because what you're 
proposing is well within the bounds of what the current document says. 
gUM is offered as a non-normative example, but that's all it is. If you 
believe that document changes are in order, perhaps a concrete proposal 
along the lines of "change the text <x> to be <y> instead" or "add text 
<z> at the end of section <q>" would produce more conversation.

/a

---

From: Sean Turner <[email-masked]>
Date: Wed, 11 Apr 2018 18:31:06 -0400

> On Apr 11, 2018, at 16:10, Adam Roach <[email-masked]> wrote:
> 
> [as an individual]
> 
> I think you're not getting a lot of response here because what you're proposing is well within the bounds of what the current document says. gUM is offered as a non-normative example, but that's all it is. If you believe that document changes are in order, perhaps a concrete proposal along the lines of "change the text <x> to be <y> instead" or "add text <z> at the end of section <q>" would produce more conversation.

As the draft’s Shepherd trying to figure out how to bring closure on this issue, I like to offer a summary:

There’s some discomfort with the use of the term “user consent” as well as the non-normative example provided for how to get it. The problem with changing the term to something else is "user consent" is a term of art; we can’t really qualify it with something like “informed”, because we’d need to explain what that means (and well GDPR …), and; frankly the term is used extensively in the other security draft that we pruned ip-handling from.  The problem with changing the non-normative example is that there don’t seem to be other attractive/realistic alternatives.

What I’d like to do is remind everybody that we pruned this draft from the other security drafts to allow it to be updated faster because it’s about a much narrower subject.  With this in mind and Bernard’s long list of questions, I would like to propose that we:*

1) Add another sentence (from Tim) that indicates there are other alternatives:

      Alternatively implementations can provide a separate
      mechanism to obtain user consent.

2) Progress the draft out of the WG.*

3) Update/Obsolete this draft, when a much superior alternative emerges.

spt

* Also "hold your nose" if you’re sad about this proposal but are willing to begrudgingly live with the rough consensus; it’s rough and we noted this in the Shepherd write-up.

** Remember that during the IETF LC we (or somebody in the wider IETF community) might come up with something during the IETF LC.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 23:59:51 +0100

On 11/04/18 23:31, Sean Turner wrote:
> * Also "hold your nose" if you’re sad about this proposal but are
> willing to begrudgingly live with the rough consensus; it’s rough and
> we noted this in the Shepherd write-up.
Yep.

(I could argue as to whether "consent" in the web is a term of art or
is really a term worthy of the artful dodger, but that's not in scope
here:-)

I think it might be worthwhile recording in the shepherd write-up that
the "consent" term caused a chunk of the controversy - that's not quite
a "privacy issue" per-se.

S.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Apr 2018 16:47:37 -0700

Sean said:

"1) Add another sentence (from Tim) that indicates there are other
alternatives:

3) Update/Obsolete this draft, when a much superior alternative emerges."

[BA] This seems like the best we can do at the moment.

With respect to alternatives, they have been explored and will no doubt
continue to be.

But it's not clear (at least to me) what metrics can be used to determine
whether an implemented alternative is "superior".

On Wed, Apr 11, 2018 at 3:31 PM, Sean Turner <[email-masked]> wrote:

> proposing is well within the bounds of what the current document says. gUM
> is offered as a non-normative example, but that's all it is. If you believe
> that document changes are in order, perhaps a concrete proposal along the
> lines of "change the text <x> to be <y> instead" or "add text <z> at the
> end of section <q>" would produce more conversation.
>
> There’s some discomfort with the use of the term “user consent” as well as
> the non-normative example provided for how to get it. The problem with
> changing the term to something else is "user consent" is a term of art; we
> can’t really qualify it with something like “informed”, because we’d need
> to explain what that means (and well GDPR …), and; frankly the term is used
> extensively in the other security draft that we pruned ip-handling from.
> The problem with changing the non-normative example is that there don’t
> seem to be other attractive/realistic alternatives.
>
> What I’d like to do is remind everybody that we pruned this draft from the
> other security drafts to allow it to be updated faster because it’s about a
> much narrower subject.  With this in mind and Bernard’s long list of
> questions, I would like to propose that we:*
>
> * Also "hold your nose" if you’re sad about this proposal but are willing
> to begrudgingly live with the rough consensus; it’s rough and we noted this
> in the Shepherd write-up.
>
> ** Remember that during the IETF LC we (or somebody in the wider IETF
> community) might come up with something during the IETF LC.

---

From: Sean Turner <[email-masked]>
Date: Wed, 11 Apr 2018 23:03:01 -0400

> On Apr 11, 2018, at 18:59, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Fair point.

spt

---

From: Lennart Grahl <[email-masked]>
Date: Thu, 12 Apr 2018 14:22:17 +0200

>> I think you're not getting a lot of response here because what you're proposing is well within the bounds of what the current document says. gUM is offered as a non-normative example, but that's a…

Thanks, this and the response from Bernard is good feedback that I
should provide a more concrete proposal next time.

> ** Remember that during the IETF LC we (or somebody in the wider IETF community) might come up with something during the IETF LC.

I realise I've joined a tad late and it should be clear by now that I
have a strong reluctance when it comes to using getUserMedia for the
purpose of getting consent to use mode 1. But you are correct, it is
non-normative and I'm more irritated by the implementations that don't
provide an alternative than this document. Still, I would appreciate if
the sentence from Tim you mentioned in 1) will be added.

Regarding 3): Like Bernard, I'm unsure how to determine a "superior
alternative" (especially in the context of a non-normative section).

Cheers
Lennart

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 12 Apr 2018 14:41:58 +0200

On Thu, 12 Apr 2018 14:22:17 +0200
Lennart Grahl <[email-masked]> wrote:

> >>> 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?  
> >>
> >>
> >> I think you're not getting a lot of response here because what
> >> you're proposing is well within the bounds of what the current
> >> document says. gUM is offered as a non-normative example, but
> >> that's all it is. If you believe that document changes are in
> >> order, perhaps a concrete proposal along the lines of "change the
> >> text <x> to be <y> instead" or "add text <z> at the end of section
> >> <q>" would produce more conversation.  
> 
> > As the draft’s Shepherd trying to figure out how to bring closure
> > on this issue, I like to offer a summary:
> > 
> > There’s some discomfort with the use of the term “user consent” as
> > well as the non-normative example provided for how to get it. The
> > problem with changing the term to something else is "user consent"
> > is a term of art; we can’t really qualify it with something like
> > “informed”, because we’d need to explain what that means (and well
> > GDPR …), and; frankly the term is used extensively in the other
> > security draft that we pruned ip-handling from.  The problem with
> > changing the non-normative example is that there don’t seem to be
> > other attractive/realistic alternatives.
> > 
> > What I’d like to do is remind everybody that we pruned this draft
> > from the other security drafts to allow it to be updated faster
> > because it’s about a much narrower subject.  With this in mind and
> > Bernard’s long list of questions, I would like to propose that we:*
> > 
> > willing to begrudgingly live with the rough consensus; it’s rough
> > and we noted this in the Shepherd write-up.
> > 
> > ** Remember that during the IETF LC we (or somebody in the wider
> > IETF community) might come up with something during the IETF LC.  
> 
> provide an alternative than this document. Still, I would appreciate
> if the sentence from Tim you mentioned in 1) will be added.
> 

Since there seems to be a call for proposed text:

	The details of this consent are left to the implementation; one
	potential mechanism is to tie this consent to getUserMedia
	consent.  It should be noted, though, that getUserMedia
	consent is typically only required when users are supposed to
	share media content from their local devices. This may not
	always be the case, e.g., in scenarios where users will only
	be receiving media (e.g., a broadcast), or when
	PeerConnections are created for the sole purpose of setting up
	datachannels. Requiring getUserMedia consent when it's not
	really needed may end up discouraging users from establishing
	a media session, or getting unwarranted access to more
	information they meant to share. As such, alternative and more
	appropriate means for getting user consent for Mode 1 are
	suggested.

Probably overly verbose, but it voices my (and I think Lennart's)
concern with the current text.

Lorenzo

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Apr 2018 08:52:59 -0400

> On Apr 12, 2018, at 08:22, Lennart Grahl <[email-masked]> wrote:
> 

I already submitted a PR :)
https://github.com/juberti/draughts/pull/98

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 13 Apr 2018 01:48:59 +0200

> concern with the current text.

Likely a verbose version of https://github.com/juberti/draughts/pull/98.
But I appreciate and would agree with that since it clarifies that some
non-obvious use cases exists that we have found throughout the years
where getUserMedia is painful (if anything). I don't know if that's an
appropriate way of telling implementers about these use cases, though.

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Apr 2018 00:22:45 +0000

Being non-interactive, it's not clear that those cases require Mode 1
though; they should work well even in Mode 2. I also don't think that
suggesting "more appropriate means" is useful when we as a WG haven't been
able to come up with any.

Note also that between -02 and -03, we as a WG chose to remove a more
explicit discussion of getUserMedia, namely this para:

       The getUserMedia
       suggestion takes into account that the user has provided some
       consent to the application already; that when doing so the user
       typically wants to engage in a conversational session, which
       benefits most from an optimal network path, and lastly, the fact
       that the underlying issue is complex and difficult to explain,
       making explicit consent for enumeration troublesome.

If we're not going to talk about the upsides of the getUserMedia
mechanism, I don't think we should have a lengthy discussion of
downsides either.

---

From: westhawk <[email-masked]>
Date: Fri, 13 Apr 2018 08:59:13 +0200

> On 13 Apr 2018, at 02:22, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Being non-interactive, it's not clear that those cases require Mode 1 though; they should work well even in Mode 2. I also don't think that suggesting "more appropriate means" is useful when we as a WG haven't been able to come up with any.

Whoa there! Non interactive, that’s a big step from non-conversational !
So one current use-case is adjusting room lights over the data channel. You can literally see latency - an unnecessary cloud round-trip is entirely
visible.

Another is driving a droid over the datachannel using it’s camera to feed live video to see where it is going 
- again totally interactive, just not using local media at the user’s end (although we do use the 
motion sensors to give a steering wheel feel) - latency here causes crashes!

A third one is baby cams, where again the video feed is one-way but you’d really like to keep the media on the home wifi
if possible for cost (and privacy) reasons.

In all these I’ll have to introduce an otherwise needless GUM request to get the network behaviour I want. 

Perhaps I should present some of these non-call based usecases at a future F2F so that folks get a sense of the possibilities.

Tim.

---

From: westhawk <[email-masked]>
Date: Fri, 13 Apr 2018 08:59:13 +0200

Tim.

---

From: Balwant Bisht <[email-masked]>
Date: Fri, 13 Apr 2018 13:53:16 +0530

Also what will happen when user have disabled camera & microphone on his
system, don't have any or G Suite Admin have disabled devices on Chromebook
and user just want to see a live event (webinar, baby cam etc).

Regards
Balwant Bisht

On Fri, Apr 13, 2018 at 12:29 PM, westhawk <[email-masked]> wrote:

> So one current use-case is adjusting room lights over the data channel.
> You can literally see latency - an unnecessary cloud round-trip is entirely
> visible.
>
> A third one is baby cams, where again the video feed is one-way but you’d
> really like to keep the media on the home wifi
> Perhaps I should present some of these non-call based usecases at a future
> F2F so that folks get a sense of the possibilities.
>
> Tim.
>

---

From: Balwant Bisht <[email-masked]>
Date: Fri, 13 Apr 2018 13:53:16 +0530

Regards
Balwant Bisht

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Apr 2018 15:36:56 +0000

> F2F so that folks get a sense of the possibilities.

The original comment from Lorenzo that I was responding to specifically
cited one-way media broadcasts.

Regardless, I contend that those cases as well as your scenarios should all
work as desired in Mode 2, which allows direct connections.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 13 Apr 2018 15:36:56 +0000

---

From: Justin Uberti <[email-masked]>
Date: Sun, 15 Apr 2018 13:09:21 +0000

On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <[email-masked]> wrote:

>> Perhaps I should present some of these non-call based usecases at a
>> future F2F so that folks get a sense of the possibilities.
>>
>
> Regardless, I contend that those cases as well as your scenarios should
> all work as desired in Mode 2, which allows direct connections.
>

Now, one might reasonably ask: if this is the case, what's the benefit of
Mode 1?

Simply stated, Mode 1 allows the client to pick whatever network interface
works best, and this provides two key benefits:
a) handoff or multipath between interfaces (e.g. wired/wifi or wifi/cell)
b) use of non-VPN interfaces when a VPN exists

I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC
will already have to solve this, and it's also not clear that this
situation actually presents an issue.

Therefore, the problem seems to reduce to b), and this may be a much more
tractable situation. If a user is using a VPN to access a web application
(i.e., the 'default' route that would be chosen by WebRTC is for a VPN
adapter), one could imagine the browser asking permission to use non-VPN
interfaces.

This could still be too complicated for typical users to understand (as I
still don't know what the prompt text should say), but the key point here
would be that only VPN users (who presumably are somewhat more savvy) would
have to see this prompt.

Thoughts? If we like this formulation, we could redefine Mode 1
accordingly, and cite the mechanism above as a potential alternative to
getUserMedia.

---

From: westhawk <[email-masked]>
Date: Sun, 15 Apr 2018 16:40:04 +0200

> On 15 Apr 2018, at 15:09, Justin Uberti <[email-masked]> wrote:
> 
> 
> 
> On Fri, Apr 13, 2018 at 8:36 AM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, Apr 12, 2018 at 11:59 PM westhawk <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 13 Apr 2018, at 02:22, Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>> wrote:
> > 
> The original comment from Lorenzo that I was responding to specifically cited one-way media broadcasts. 
> 
> Regardless, I contend that those cases as well as your scenarios should all work as desired in Mode 2, which allows direct connections.
> 
> Now, one might reasonably ask: if this is the case, what's the benefit of Mode 1?
> 
> Simply stated, Mode 1 allows the client to pick whatever network interface works best, and this provides two key benefits:
> I imagine that a) is not unique to WebRTC, i.e., in-browser MPTCP or QUIC will already have to solve this, and it's also not clear that this situation actually presents an issue.

I’m not sure I agree - or disagree - yet.
Here are a couple of sources of my uncertainty:

SCTP has also has multipath/multihome capabilities which ICE is effectively obscuring in the current setup.
Given this is the 1.0 spec, we also have SRTP to worry about which isn’t capable of multipath (as far as I’m aware). 

An example of this may be an LTE phone that has a ‘data bearer channel’ and a ‘media bearer channel’ - the billing routability and QoS behaviour of these
two interfaces will be different. I could imagine that a carrier app might want to use the media bearer for a voice call. (Sorry for my 3GPP  semi-ignorance).

> 
> Therefore, the problem seems to reduce to b), and this may be a much more tractable situation. If a user is using a VPN to access a web application (i.e., the 'default' route that would be chosen by WebRTC is for a VPN adapter), one could imagine the browser asking permission to use non-VPN interfaces. 

Is it possible to tell if an interface is a VPN ? I’m not convinced I know how to reliably distinguish between a VPN and a multi-bearer LTE
config.

> 
> This could still be too complicated for typical users to understand (as I still don't know what the prompt text should say), but the key point here would be that only VPN users (who presumably are somewhat more savvy) would have to see this prompt.
> 
> Thoughts? If we like this formulation, we could redefine Mode 1 accordingly, and cite the mechanism above as a potential alternative to getUserMedia.
I like this in principle. But I also feel that the prompt would include the concept of revealing location/service provider.

Tim.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 15 Apr 2018 15:12:28 +0000

On Sun, Apr 15, 2018 at 7:40 AM westhawk <[email-masked]> wrote:

>>> A third one is baby cams, where again the video feed is one-way but
>>> you’d really like to keep the media on the home wifi
> SCTP has also has multipath/multihome capabilities which ICE is
> effectively obscuring in the current setup.
> Given this is the 1.0 spec, we also have SRTP to worry about which isn’t
> capable of multipath (as far as I’m aware).
>

SCTP is a non-issue here; as you point out, it's being tunneled over
DTLS/ICE, so it's whatever ICE chooses to do (which is the core issue).
SRTP similarly follows what ICE does. And ICE, in Mode 1, can use whatever
interface it wants; it can choose a different interface for every packet,
as long as it has a valid pair on that interface.

>
> An example of this may be an LTE phone that has a ‘data bearer channel’
> and a ‘media bearer channel’ - the billing routability and QoS behaviour of
> these
> two interfaces will be different. I could imagine that a carrier app might
> want to use the media bearer for a voice call. (Sorry for my 3GPP
>  semi-ignorance).
>

I don't think this is relevant to this discussion; since this isn't
surfaced upwards as different interfaces to the OS, any behavior here is
the same as you would get in Mode 2 when using the cellular interface.

> Is it possible to tell if an interface is a VPN ? I’m not convinced I know
> how to reliably distinguish between a VPN and a multi-bearer LTE
> config.
>

You can easily tell those apart via OS interface properties. For example,
Windows allows one to determine the type of an interface, e.g. physical or
tunnel (
https://msdn.microsoft.com/en-us/library/windows/desktop/aa814491(v=vs.85).aspx).
Now,
there are multiple possible types of tunnel, but even just knowing tunnel
vs non-tunnel might be sufficient.

> I like this in principle. But I also feel that the prompt would include
> the concept of revealing location/service provider.
>

That seems entirely reasonable, especially the "service provider" angle,
which is more accurate and likely understandable than "location".

---

From: Lennart Grahl <[email-masked]>
Date: Sun, 15 Apr 2018 17:14:58 +0200

> situation actually presents an issue.

I have run into some edge cases where not having a) is an issue:

1. Testing data channel implementations over a separate network where
delay, packet loss, etc. can be applied without affecting the signalling
network or access to the internet. The only solution I was able to come
up with was temporarily changing the default route until the peer
connection is set up (and I can't use getUserMedia because I don't
always control the test scripts).

2. Sitting in the German high speed train (called "ICE" btw. ;)) and
using the hotspot (default route) as well as being connected to the
smartphone via another interface and using Threema Web to connect to the
smartphone app. This is exactly where WebRTC should shine but it doesn't
because the default route lead to both devices talking via TURN since
network policies in the train prevent the devices from talking to each
other directly. And you can imagine how well TURN works in a high speed
train, especially with the horrible network coverage in Germany...

3. Tim brought up another example: "So if my phone is acting as a
hotspot for my drone, and connecting to 4g. The phone's 4g is the
default route for the browser - but I actually want the traffic to go
over the wifi interface."

I realise these examples are very specific but I would not be surprised
if this is something that happens in large corporate networks as well
(peers technically being able to talk to each other via a different
network but not via the one with the default route).

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Sun, 15 Apr 2018 15:25:54 +0000

On Sun, Apr 15, 2018 at 8:15 AM Lennart Grahl <[email-masked]>
wrote:

> >>> Another is driving a droid over the datachannel using it’s camera to
> feed
> >>> live video to see where it is going
> >>> - again totally interactive, just not using local media at the user’s
> end
> >>> (although we do use the
> you’d
> >>> In all these I’ll have to introduce an otherwise needless GUM request
> to
> >>> get the network behaviour I want.
> >>>
Right, I agree these edge cases are reasonable illustrations of the general
case - "use another interface if my primary interface is crap".

My overall point is that we might be able to consider using multiple
non-virtual interfaces as part of Mode 2, or perhaps an in-between "Mode
1.5", since HTTP traffic could conceivably do the same in the near future
(via MPTCP <https://support.apple.com/en-us/HT201373> or QUIC connection
migration
<https://datatracker.ietf.org/meeting/100/materials/slides-100-quic-sessb-connection-migration-01>).
IOW, a) could be handled separately from this complex "consent" discussion
(and the consent discussion would be focused on b)).

---

From: westhawk <[email-masked]>
Date: Sun, 15 Apr 2018 17:34:49 +0200

> On 15 Apr 2018, at 17:12, Justin Uberti <[email-masked]> wrote:
> 
> 
> I don't think this is relevant to this discussion; since this isn't surfaced upwards as different interfaces to the OS, any behavior here is the same as you would get in Mode 2 when using the cellular interface. 

That’s not the impression I got from this CCC talk https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf <https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf>

One of the slides explicitly shows 2 interfaces surfaced to the ifconfig in linux busybox. 
I realise that these slides are a couple of years old, but I doubt VoLTE has changed much in that time. (I’m still semi-ignorant on 3gpp )

Tim.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 15 Apr 2018 15:51:07 +0000

On Sun, Apr 15, 2018 at 8:34 AM westhawk <[email-masked]> wrote:

>> two interfaces will be different. I could imagine that a carrier app
>> might want to use the media bearer for a voice call. (Sorry for my 3GPP
>>  semi-ignorance).
>>
>
> That’s not the impression I got from this CCC talk
> https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf
>
> I realise that these slides are a couple of years old, but I doubt VoLTE
> has changed much in that time. (I’m still semi-ignorant on 3gpp )
>

Yes, I see what you mean. It seems like the bearer is intended to be locked
down to VoLTE traffic - but this may not always be happening yet in
practice (although this issue was reported to Google and may have been
fixed in a recent version of Android). Regardless, I would still contend
that selecting a specific bearer for WebRTC traffic is outside of our
current remit.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 16 Apr 2018 21:06:48 +0000

Here's a specific and minimal proposal, which is a slight modification
of Sean's
proposal in https://github.com/juberti/draughts/pull/98/files:

*The details of this consent are left to the implementation; one potential
mechanism is to tie this consent to getUserMedia consent. Alternatively
implementations can provide a specific mechanism to obtain user consent
where needed, e.g., when a VPN is in use.*

Are folks in favor of:
a) the text above
b) Sean's proposal (without the boldface)
c) something else

On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti <[email-masked]> wrote:

> Yes, I see what you mean. It seems like the bearer is intended to be
> locked down to VoLTE traffic - but this may not always be happening yet in

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Apr 2018 16:22:50 -0500

[as an individual]

I'm good with (a) or (b). I'm not too hot on (c), as I don't want to see 
this text caught up in another lengthy round of wordsmithing.

/a

On 4/16/18 4:06 PM, Justin Uberti wrote:
> of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:
>
> /The details of this consent are left to the implementation; one 
> consent. Alternatively implementations can provide a specific 
> mechanism to obtain user consent *where needed, e.g., when a VPN is in 
> use.*/
>
> Are folks in favor of:
> a) the text above
> /
> /
> On Sun, Apr 15, 2018 at 8:51 AM Justin Uberti <[email-masked] 
> <mailto:juberti@google..com>> wrote:
>
>
>
>     On Sun, Apr 15, 2018 at 8:34 AM westhawk <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>>         On 15 Apr 2018, at 17:12, Justin Uberti <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>
>>             An example of this may be an LTE phone that has a ‘data
>>             bearer channel’ and a ‘media bearer channel’ - the
>>             billing routability and QoS behaviour of these
>>             two interfaces will be different. I could imagine that a
>>             carrier app might want to use the media bearer for a
>>             voice call. (Sorry for my 3GPP  semi-ignorance).
>>
>>
>>         I don't think this is relevant to this discussion; since this
>>         isn't surfaced upwards as different interfaces to the OS, any
>>         behavior here is the same as you would get in Mode 2 when
>>         using the cellular interface.
>
>         I realise that these slides are a couple of years old, but I
>         doubt VoLTE has changed much in that time. (I’m still
>         semi-ignorant on 3gpp )
>
>
>     Yes, I see what you mean. It seems like the bearer is intended to
>     be locked down to VoLTE traffic - but this may not always be
>     happening yet in practice (although this issue was reported to
>     Google and may have been fixed in a recent version of Android).
>     Regardless, I would still contend that selecting a specific bearer
>     for WebRTC traffic is outside of our current remit.
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Apr 2018 16:22:50 -0500

[as an individual]

/a

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Apr 2018 14:33:05 -0700

I strongly object to the "e.g., when a VPN is in use." This implying that this is needed when a VPN is in use - that is simply not true. As i keep pointing out, most VPNs do not have the problem this draft tries to deal with.  I think that what this draft should say is don't use a VPN to hide your location that fails to hide your location. 

If we are deciding that the current text does not have consensus and need to be changed, then I'm glad to engage in that conversation but right now I am working the assumption that the current text does have consensus so not much to say. 

> On Apr 16, 2018, at 2:06 PM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Here's a specific and minimal proposal, which is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files:
> 
> The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively implementations can provide a specific mechanism to obtain user consent where needed, e.g., when a VPN is in use.
> 
> Are folks in favor of:
> a) the text above
> That’s not the impression I got from this CCC talk https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/829/original/2015.12.28_CCC_Dissecting_VoLTE.pdf
> 
> Yes, I see what you mean. It seems like the bearer is intended to be locked down to VoLTE traffic - but this may not always be happening yet in practice (although this issue was reported to Google and may have been fixed in a recent version of Android). Regardless, I would still contend that selecting a specific bearer for WebRTC traffic is outside of our current remit.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Apr 2018 14:33:05 -0700

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 16 Apr 2018 15:24:33 -0700

> On Mar 7, 2018, at 11:49, Sean Turner <[email-masked]> wrote:
> 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 apologize for bringing this up so late, but it looks to me like we should consider phrasing the words for Mode 4 in this draft more precisely.

As shown here https://bugs.chromium.org/p/chromium/issues/detail?id=767304 <https://bugs.chromium.org/p/chromium/issues/detail?id=767304> and here https://bugzilla.mozilla.org/show_bug.cgi?id=1452713 <https://bugzilla.mozilla.org/show_bug.cgi?id=1452713> implementers are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy is configured.

At a minimum I would suggest to insert “HTTP” before each of the occurrences of the word proxy in the description:

Mode 4:  Force proxy: This forces all WebRTC media traffic through a
            proxy, if one is configured.  If the proxy does not support
            UDP (as is the case for all HTTP and most SOCKS [RFC1928 <https://tools.ietf.org/html/rfc1928>]
            proxies), or the WebRTC implementation does not support UDP
            proxying, the use of UDP will be disabled, and TCP will be
            used to send and receive media through the proxy.  Use of
            TCP will result in reduced quality, in addition to any
            performance considerations associated with sending all
            WebRTC media through the proxy server.
Because apparently some people think of proxies and TURN relays being the same thing. Which I don’t think is/was the intention here.

Second of all I think the draft would benefit from explaining what to do expect in Mode 4 in the absence of a HTTP proxy.

And lastly I think the discussions in the above bug reports have brought up the point that TURN relays might not be trustworthy either.
I’m assuming it’s only a matter of time until when some evil actors will provide fake TURN implementations to gather the browsers routable IP from the TURN layer.
Therefore I think it would make a lot more sense to specify two different modes:
- Mode 4: Relay only: only TURN relay candidates are gathered.
- Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a HTTP proxy.
                If no HTTP proxy is configured no candidates are gathered.
I realize that the process might have gotten already to far to follow this suggestion.

Best regards
  Nils Ohlmeier

---

From: Justin Uberti <[email-masked]>
Date: Mon, 16 Apr 2018 22:28:12 +0000

On Mon, Apr 16, 2018 at 3:24 PM Nils Ohlmeier <[email-masked]> wrote:

> 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 apologize for bringing this up so late, but it looks to me like we
> should consider phrasing the words for Mode 4 in this draft more precisely.
>
> As shown here https://bugs.chromium.org/p/chromium/issues/detail?id=767304 and
> here https://bugzilla.mozilla.org/show_bug.cgi?id=1452713 implementers
> are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy is
> configured.
>
> At a minimum I would suggest to insert “HTTP” before each of the
> occurrences of the word proxy in the description:
>
> Because apparently some people think of proxies and TURN relays being the
> same thing. Which I don’t think is/was the intention here.
>
> Second of all I think the draft would benefit from explaining what to do
> expect in Mode 4 in the absence of a HTTP proxy.
>
> And lastly I think the discussions in the above bug reports have brought
> up the point that TURN relays might not be trustworthy either.
> I’m assuming it’s only a matter of time until when some evil actors will
> provide fake TURN implementations to gather the browsers routable IP from
> the TURN layer.
How would relay-only help here? The web application can still learn the IP
directly from the TURN servers.

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 16 Apr 2018 15:39:56 -0700

> On Apr 16, 2018, at 15:28, Justin Uberti <[email-masked]> wrote:
> How would relay-only help here? The web application can still learn the IP directly from the TURN servers.

At least no IP addresses from your local network are exposed on the signaling path.
Yes if you don’t trust the TURN relay this is the same as Mode 3.
It might make a difference if one has a TURN relay configured in his/her browser (which results in the web browser ignoring the TURN relays from web application), which is not part of the web application.

Best
  Nils Ohlmeier.

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 16 Apr 2018 15:44:30 -0700

> On Apr 16, 2018, at 15:39, Nils Ohlmeier <[email-masked]> wrote:
> 
> 
>> On Apr 16, 2018, at 15:28, Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:

A relay-only mode would also help if you don’t want to hand out your IP addresses to the others side of the PeerConnection, but you do trust the TURN server and web application.

Best
  Nils Ohlmeier

---

From: Justin Uberti <[email-masked]>
Date: Tue, 17 Apr 2018 09:15:14 +0000

On Mon, Apr 16, 2018 at 3:40 PM Nils Ohlmeier <[email-masked]> wrote:

> It might make a difference if one has a TURN relay configured in his/her
> browser (which results in the web browser ignoring the TURN relays from web
> application), which is not part of the web application.
>

IMO "trusting the TURN relay but not the application" is not a significant
enough benefit to merit adding specific functionality for.

Forced TURN relays would be covered as part of Mode 4.

---

From: Lennart Grahl <[email-masked]>
Date: Tue, 17 Apr 2018 14:16:00 +0200

> b) Sean's proposal (without the boldface)

Voting for b).

Cheers
Lennart

---

From: westhawk <[email-masked]>
Date: Tue, 17 Apr 2018 14:40:34 +0200

> On 16 Apr 2018, at 23:06, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Here's a specific and minimal proposal, which is a slight modification of Sean's proposal in https://github.com/juberti/draughts/pull/98/files <https://github.com/juberti/draughts/pull/98/files>:
> 

b)

---

From: westhawk <[email-masked]>
Date: Tue, 17 Apr 2018 14:40:34 +0200

b)

---

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Apr 2018 07:16:53 +0000

OK, merged b) via https://github.com/juberti/draughts/pull/98.

Sean, should I produce a new version of the document?

On Tue, Apr 17, 2018 at 5:40 AM westhawk <[email-masked]> wrote:

>
>
> On 16 Apr 2018, at 23:06, Justin Uberti <
> juberti=[email-masked]> wrote:
>
> Here's a specific and minimal proposal, which is a slight modification of Sean's

---

From: Sean Turner <[email-masked]>
Date: Wed, 18 Apr 2018 16:20:03 -0400

Yes please.  I think the IETF LC should be on the latest text.

Note I’ve already updated the Shepherd write-up as Stephen suggested.

spt

> On Apr 18, 2018, at 03:16, Justin Uberti <juberti=[email-masked]> wrote:
> 
> On Tue, Apr 17, 2018 at 5:40 AM westhawk <[email-masked]..uk> wrote:
> 
>

---

From: Sean Turner <[email-masked]>
Date: Wed, 18 Apr 2018 16:20:03 -0400

spt

---

From: Justin Uberti <[email-masked]>
Date: Wed, 18 Apr 2018 21:08:39 +0000

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/

On Wed, Apr 18, 2018 at 1:20 PM Sean Turner <[email-masked]> wrote:

> potential mechanism is to tie this consent to getUserMedia consent.
> Alternatively implementations can provide a specific mechanism to obtain
> user consent where needed, e.g., when a VPN is in use.
> >>

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 19 Apr 2018 09:22:36 -0700

While I understand the arguments against adding more mode I still think the paragraph describing Mode 4 is missing details and causes confusion among implementers:

- It is not clear if the word “proxy” refers to a HTTP proxy or a TURN server.

This can easily be improved by replacing the word “proxy” with “HTTP proxy” everywhere in the Mode 4 paragraph.

- It is unclear how an implementation should behave in the absence of such a proxy.

I would suggest to add a sentence the implementation should not hand out any candidates in the absence of a HTTP proxy.

Best regards
  Nils Ohlmeier

> On Apr 18, 2018, at 14:08, Justin Uberti <juberti=[email-masked]> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/ <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/07/>
> 
> On Wed, Apr 18, 2018 at 1:20 PM Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
> > On Apr 18, 2018, at 03:16, Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>> wrote:
> >
> > OK, merged b) via https://github.com/juberti/draughts/pull/98 <https://github.com/juberti/draughts/pull/98>.
> >
> >> On 16 Apr 2018, at 23:06, Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>> wrote:
> >>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 19 Apr 2018 09:22:36 -0700

Best regards
  Nils Ohlmeier

---

From: Justin Uberti <[email-masked]>
Date: Thu, 19 Apr 2018 23:29:04 +0000

On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <[email-masked]> wrote:

> While I understand the arguments against adding more mode I still think
> the paragraph describing Mode 4 is missing details and causes confusion
> among implementers:
>
> This can easily be improved by replacing the word “proxy” with “HTTP
> proxy” everywhere in the Mode 4 paragraph.
>

The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN
proxy (SOCKS is specifically noted in the para).

> I would suggest to add a sentence the implementation should not hand out
> any candidates in the absence of a HTTP proxy.
>

This is a fair point. However, my take is that the behavior should be the
same as Mode 3 in this case, as the web server already sees the client IP.
I could add a sentence to make this super clear.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 19 Apr 2018 23:29:04 +0000

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 19 Apr 2018 16:34:24 -0700

> On Apr 19, 2018, at 16:29, Justin Uberti <[email-masked]> wrote:
> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or RETURN proxy (SOCKS is specifically noted in the para).

Fair enough.

> This is a fair point. However, my take is that the behavior should be the same as Mode 3 in this case, as the web server already sees the client IP. I could add a sentence to make this super clear.

I think that would help.
Although I’m wondering if your assumption is correct here if the user is using a tunneling VPN, e.g. IPSEC or something which is not just a simple HTTP proxy. Then I could see in edge cases the HTTP traffic tacking a different path then your STUN packets. But I think it’s probably okay to ignore that edge case.

Best
  Nils Ohlmeier

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 19 Apr 2018 16:34:24 -0700

Fair enough.

I think that would help.

Best
  Nils Ohlmeier

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 20 Apr 2018 01:40:57 +0200

> I could add a sentence to make this super clear.

The web server, yes. But not the other peer. I don't think we can assume
trust towards the web server equals trust towards the other peer. I
would agree with Nils that it shouldn't hand out any candidates in this
case.

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Fri, 20 Apr 2018 00:02:54 +0000

On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <[email-masked]>
wrote:

> >> - It is unclear how an implementation should behave in the absence of
> such
> >> a proxy.
> >>

This is not unique to Mode 4.

This scenario is discussed in detail in
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4;
I don't think it needs special mention in this doc.

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 20 Apr 2018 03:10:36 +0200

> I don't think it needs special mention in this doc.

Still, I see no possibility for the user to voice it's opinion in this
matter. However, that may simply be an issue for the browser vendors to
resolve (by providing additional browser settings - I think at least
Firefox does that already).

Then it probably should be clarified because if I'm not mistaken Chrome
gets it wrong, too (no proxy = no candidates). Unless that fourth mode
does not actually map to mode 4 (see
https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15).

Cheers
Lennart

---

From: Sean Turner <[email-masked]>
Date: Fri, 20 Apr 2018 08:50:03 -0400

I’m going to go ahead and push this draft towards Adam (our AD) and we’ll treat this as an IETF LC comment to get fixed up before the IESG telechat (i.e., Justin just throw a PR in for whatever change, but there’s no need to spin a new version).

spt

> On Apr 19, 2018, at 21:10, Lennart Grahl <[email-masked]> wrote:
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 20 Apr 2018 14:24:16 +0000

> https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15
In Chrome Mode 4 is currently over-conservative, it forces the use of TCP,
and those TCP connections are sent through a proxy if one exists. This is
because "is a proxy present?" is a per-destination question (at least when
PAC files are used
<https://en.wikipedia.org/wiki/Proxy_auto-config#The_PAC_File>), and as
such was difficult to determine a priori.

FWIW, you can try it out at
https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia?hl=en
.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 20 Apr 2018 14:48:43 +0000

Small PR for improved text:
https://github.com/juberti/draughts/pull/100/files

On Fri, Apr 20, 2018 at 5:50 AM Sean Turner <[email-masked]> wrote:

> I’m going to go ahead and push this draft towards Adam (our AD) and we’ll
> treat this as an IETF LC comment to get fixed up before the IESG telechat
> (i.e., Justin just throw a PR in for whatever change, but there’s no need
> to spin a new version).
>
> spt
>
> >>>>> - It is not clear if the word “proxy” refers to a HTTP proxy or a
> TURN
> >>>>> server.
> >>>>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 20 Apr 2018 10:18:35 -0700

> On Apr 20, 2018, at 07:48, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Small PR for improved text: https://github.com/juberti/draughts/pull/100/files <https://github.com/juberti/draughts/pull/100/files>
I think this helps.

I guess that the implementation is suppose to fall back to mode 3 (vs not work at all) derives from the “This is the same as Mode 3,…” part?
The only option which comes to my mind to make this more explicit would be to add another sentence like “If the applications HTTP traffic is not proxied it should fall back to Mode 3”.

  Nils

> On Fri, Apr 20, 2018 at 5:50 AM Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
> > On Apr 19, 2018, at 21:10, Lennart Grahl <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <[email-masked] <mailto:[email-masked]>>
> >> wrote:
> >>
> >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4>;
> > https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15 <https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15>).
> >
> > Cheers
> > Lennart
> >

---

From: Justin Uberti <[email-masked]>
Date: Fri, 20 Apr 2018 17:40:54 +0000

On Fri, Apr 20, 2018 at 10:18 AM Nils Ohlmeier <[email-masked]>
wrote:

>
> On Apr 20, 2018, at 07:48, Justin Uberti <
> I guess that the implementation is suppose to fall back to mode 3 (vs not
> work at all) derives from the “This is the same as Mode 3,…” part?
>

Correct.

> The only option which comes to my mind to make this more explicit would be
> to add another sentence like “If the applications HTTP traffic is not
> proxied it should fall back to Mode 3”.
>

I thought about this but decided just to clarify the sentence where it
refers to Mode 3, since adding an explicit sentence felt like belaboring
the point. If you still feel this is unclear I could be convinced.

>> > On Apr 19, 2018, at 21:10, Lennart Grahl <[email-masked]
>> <[email-masked]>> wrote:
>> >
>> >> On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <[email-masked]
>> >
>> >> wrote:
>> >>
>> >>>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <[email-masked]
>> >
>> >>> wrote:
>> >>>>
>> >>>> same as Mode 3 in this case, as the web server already sees the
>> client
>> >>> IP.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Apr 2018 12:22:15 -0600

> On Apr 17, 2018, at 3:15 AM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> IMO "trusting the TURN relay but not the application" is not a significant enough benefit to merit adding specific functionality for.
> 

In the case were the TURN server is provided by the JS, I agree. But in the case where the configuration of the browser provided the TURN server, then I think it is as trusted as say a VPN server.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 30 Apr 2018 22:03:12 +0000

Any TURN server provided by the browser is in effect a proxy, and forcing
use of said proxy can be done either through firewall config or explicit
selection of Mode 4. (IOW, no new mode is needed.)

The document originally pointed at RETURN as an example of how such TURN
proxying could work, but was removed in order to avoid a dependency.

On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings <[email-masked]> wrote:

>
>
> On Apr 17, 2018, at 3:15 AM, Justin Uberti <
> In the case were the TURN server is provided by the JS, I agree. But in
> the case where the configuration of the browser provided the TURN server,
> then I think it is as trusted as say a VPN server.
>
>
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 30 Apr 2018 15:21:26 -0700

> On Apr 30, 2018, at 15:03, Justin Uberti <[email-masked]> wrote:
> 
> Any TURN server provided by the browser is in effect a proxy, and forcing use of said proxy can be done either through firewall config or explicit selection of Mode 4. (IOW, no new mode is needed.)

I do agree that these two configurations result in a similar behavior.
But I doubt that these use the same code path in implementations.
And (thus) I doubt readers of the draft/RFC will automatically come to the same conclusion.

It think it might be helpful to add another sentence explaining this scenario.

> The document originally pointed at RETURN as an example of how such TURN proxying could work, but was removed in order to avoid a dependency.

Fair enough.

  Nils

> On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Apr 17, 2018, at 3:15 AM, Justin Uberti <juberti=[email-masked] <mailto:juberti=[email-masked]>> wrote:
>>