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

[Justin Uberti <[e-mail]>]

PTAL at https://github.com/juberti/draughts/pull/96, which tries to explain
that implementations may choose different defaults a bit more clearly.

On Tue, Feb 13, 2018 at 7:06 PM, Sean Turner <[e-mail]> wrote:

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