Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt

[Sean Turner <[e-mail]>]

> On Feb 13, 2018, at 15:46, Justin Uberti <[e-mail]> wrote:
> 
> 
> 
> On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Hiya,
> 
> On 12/02/18 09:26, Harald Alvestrand wrote:
> > Den 12. feb. 2018 00:24, skrev Stephen Farrell:
> >>
> >> I forget if this was explicitly discussed before. Apologies if
> >> it was.
> >>
> >> I consider the following text ridiculous:
> >>
> >>    "Mode 1 MUST only be used when user consent has
> >>     been provided;"
> >>
> >> The reason is that it is not possible for all WebRTC users to
> >> ever provide real consent to something dealing with which IP
> >> addresses are used in ICE. So assuming consent is just BS, as
> >> people cannot provide consent to something they do not understand.
> >> (And that won't be explained by their systems or s/w.)
> >>
> >> For me, that means that this draft will appear pretty much as a
> >> fig leaf, intended by us technologists to allow us to pretend
> >> we're doing the right thing, when we're not. I think that's not
> >> really that useful.
> >>
> >> Is it really too late to try fix the concept of consent that's
> >> (ab)used in WebRTC?
> >
> > I'm sorry, but I don't agree with you on this point.
> 
> Fair enough.
> 
> >
> > The decision to go for these modes was based on the theory that if the
> > user has already consented to the near-perfect tracking abilities that
> > are implicit in offering a video stream (tracking camera defects, for
> > instance), and all the information that can be gleaned from a live audio
> > stream, then the idea of protecting the user against tracking by
> > restricting access to his IP addresses became of so little value that it
> > was moot and was worth trading away for better performance of the
> > functions the user asked for.
> 
> I understand that logic. It does however seem to have caused
> issues for at least some people who don't agree that the this
> leakage is moot. I'm not claiming that all such claims are
> well founded, but I think at least some are.
> 
> So this document tries to address two sets of issues:
> a) leakage in contexts when the user is not intentionally using a WebRTC application
> b) leakage in contexts when the user is intentionally using a WebRTC application
> 
> The 'consent' discussion is focused around a), with the result being that the ISP address will not be provided when using a VPN unless the user has consented to use of their camera. The WG went back and forth and came to a rough consensus on this being a reasonable solution to the problem.
> 
> However, b) is also discussed in the document, and browsers could implement their own local policy, e.g., their own default or perhaps a preference to exclusively use Mode 2, regardless of webcam consent.
> 
> Such an approach wouldn't provide as much nuance as your suggested per-interface permission list, but there already are examples of this (various browser extensions that set the ip-handling mode), and I think we can all admit that asking OSes to indicate which interfaces are OK to use for ICE would be a long-term project.
> 
> If it would help, I could rework the section around the recommended defaults to make it clear that users or browsers could choose not to use Mode 1, and/or discuss the defaults and how they relate to a)/b) above.

Justin: Since you offered ;) Go ahead and take a stab at it.

Everybody: Hoping this won’t be too controversial since it appeared that we were getting very close to being done with this draft.

> > Explanations about what the IP address is for and how it is used doesn't
> > matter in this argument. The point is that the user has already agreed
> > to a degree of invasion of privacy that a) is perfectly understandable,
> > and b) is of significantly more significance than what's being discussed
> > here.
> >
> > Unfortunately the way in which documents depend on each other, and the
> > degree to which it's desirable to have each area of concern be described
> > on its own, make it hard to state this in the document as explicitly as
> > I do when discussing it.
> >
> > This thread re-raises an issue that has been hashed over many times, and
> > I believe the current draft represents the (rough) consensus of the WG
> > on this matter.
> 
> I'm willing to accept that I'm in the rough in terms of how
> the WG is using the term "consent."
> 
> Nonetheless, if the term can be avoided here, then I still
> think that'd be an improvement.

Stephen: The only thing I’d add to Harald's point is that this draft hasn’t yet been through WGLC, but the draft has basically had the same recommendations since before it was a WG draft (the draft was adopted about two years ago).  Namely, Mode 1 (enumerate all addresses) is recommended only if the user has done something explicit else Mode 2 (default route + associated local addresses) is recommended.  While Justin might be reworking the section around the recommended defaults, I don’t think the recommended defaults are going to change (unless of course there’s a pretty substantial outcry that’s going to upset what appeared to be the emerging rough consensus).

spt