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

[Justin Uberti <[e-mail]>]

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.


> >
> > 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.
>
> >
> >>
> >> Even if so, I don't see any reason to make it worse, via this
> >> draft, and especially via the quoted text above, so I'd argue
> >> that we ought get rid of that concept from this draft.
> >>
> >> FWIW, I reckon, if implementers liked it, that there is a
> >> better answer here which is to provide an interface (API and/or
> >> UI) that allows selected interfaces to be omitted from ICE.
> >
> > We have that API offered in Javascript already. It's called "skipping
> > the candidates". But JS API surface helps the JS provider defend against
> > other attackers; it has no benefit when the JS provider *is* the
> attacker.
>
> Right - I wasn't suggesting a JS API but rather one such as
> you describe below...
>
> >
> > Non-JS-visible APIs discussed have included the ability to specify
> > "corporate" TURN servers in browser configs and requiring that these be
> > used. These are typically out of scope for standards; I haven't seen
> > anything published on whether or not those have been implemented.
>
> Nor have I. I agree that specifying such an API in this draft
> wouldn't be right. I don't agree that such an interface ought
> be out of scope for standardisation, but do agree that figuring
> out where to define one could be tricky.
>
> The interface I have in mind for this case would be something
> that'd allow e.g. an operating system UI to state that "tun0
> isn't to be used for ICE until I say otherwise" or that'd
> allow a VPN client application to call a browser-specific API
> of some sort to do the same. I guess even a browser command
> line argument could help some - then the folks who care about
> this issue could then have a different icon/button/whatever
> for starting a browser for webrtc-without-tun0 or whatever.
>
> What this draft could do however, is get rid of the idea of
> consent, and define the modes as involving all addresses
> except those that are omitted due to local policy, e.g. if
> such an interface exists and has been used.
>
> Lastly - the above is only worthwhile if implementers were
> likely to provide some way to omit addresses/interfaces
> from ICE - if WebRTC clients just weren't ever going to offer
> any way to e.g. omit tun0, then there'd be no point in
> talking about that. If it was something that could be done
> now or in future, then it'd be good to talk about it here
> though.
>
> And FWIW, I still consider talk of user consent for ICE as
> ridiculous:-)
>
> Cheers,
> S.
>
> >
> >>
> >> S.
> >>
> >> On 11/02/18 09:00, [e-mail] wrote:
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>> This draft is a work item of the Real-Time Communication in
> WEB-browsers WG of the IETF.
> >>>
> >>>         Title           : WebRTC IP Address Handling Requirements
> >>>         Authors         : Justin Uberti
> >>>                           Guo-wei Shieh
> >>>     Filename        : draft-ietf-rtcweb-ip-handling-05.txt
> >>>     Pages           : 10
> >>>     Date            : 2018-02-11
> >>>
> >>> Abstract:
> >>>    This document provides information and requirements for how IP
> >>>    addresses should be handled by WebRTC implementations.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/
> >>>
> >>> There are also htmlized versions available at:
> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05
> >>>
> >>> A diff from the previous version is available at:
> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-05
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> submission
> >>> until the htmlized version and diff are available at tools.ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >
> >
>
> --
> PGP key change time for me.
> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
> NewWithOld sigs in keyservers.
> Sorry if that mucks something up;-)
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>