Subject: Re: [rtcweb] Fwd: New Version Notification for draft-shieh-rtcweb-ip-handling-00.txt

From: Wendy Seltzer <[email-masked]>
Date: Mon, 2 Nov 2015 15:25:17 -0500

Hi Justin,

On 10/19/2015 08:03 PM, Justin Uberti wrote:
> FYI - A rough initial attempt to document the recommended IP handling logic
> for WebRTC apps.
> 
> A new version of I-D, draft-shieh-rtcweb-ip-handling-00.txt
> has been successfully submitted by Justin Uberti and posted to the
> IETF repository.
> 
> Name:           draft-shieh-rtcweb-ip-handling

Thanks for the analysis. I think a big piece of the challenge here is in
discerning what users' purposes and intents are, as you note in the
discussion of VPNs, and further, determining what protocol and API
designers should do when those purposes are unclear.

Adding to the challenge, privacy-seeking users benefit when they don't
have to identify themselves as such, but can employ general-purpose
tools to hide in the crowd. Some of those users will be technical enough
to explain their needs and watch for changes that would break use cases,
others won't be and won't even have conceived the problems that way.

So, on to specific concerns:

Saying that "local audio and video, ... are typically much more
sensitive than the aforementioned IP address information" is overbroad:
they're sensitive to different audiences and contexts. Moreover, if the
audio/video are encrypted between peers, while the IP is revealed to
intermediaries, the privacy risk is of a different nature, so coupling
these permissions isn't ideal. [This distinction may be messier in
practice, since the media-capture permission can't (yet) be scoped to
locally-encrypted access, the user can't in fact distinguish between
granting media to peers and to intermediaries.]

There's also a time dimension: as new features get established, they can
change the expectations of users and of privacy-application developers.
A privacy-proxy dev who knows about WebRTC can add an explicit
configuration or warning; one whose tools are deployed before a
user-agent change couldn't have anticipated the risks.

So I'd suggest good practice to require more explicit permission prompts
about IP-exposure early in the feature's roll-out, so that both
privacy-conscious users and those who design tools and trainings for
them have the opportunity to recognize and respond to the specific
privacy threats they might face.

--Wendy

> Revision:       00
> Title:          WebRTC IP Address Handling Recommendations
> Document date:  2015-10-19
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/internet-drafts/draft-shieh-rtcweb-ip-handling-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-shieh-rtcweb-ip-handling/
> Htmlized:
> https://tools.ietf.org/html/draft-shieh-rtcweb-ip-handling-00
> 
> 
> Abstract:
>    This document provides best practices for how IP addresses should be
>    handled by WebRTC applications.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
Wendy Seltzer -- [email-masked] +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

---

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Nov 2015 20:45:06 -0800

> privacy threats they might face.

I'm not exactly sure what you are suggesting; WebRTC has been deployed at
scale for some time, and we are now refining the policy on how we gather
and expose IP addresses, especially for sites that are not using WebRTC for
audio/video communication.

Agree that coupling the network and audio/video permissions isn't perfect,
but this is a challenging thing to convey to users, the vast majority of
whom aren't using a proxy or VPN or have even heard of one. At a first
step, we think coupling these permissions addresses the concern of IP
address gathering on non-communication sites.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 3 Nov 2015 14:50:43 +0900

On Tue, Nov 3, 2015 at 1:45 PM, Justin Uberti <[email-masked]> wrote:
> whom aren't using a proxy or VPN or have even heard of one. At a first step,
> we think coupling these permissions addresses the concern of IP address
> gathering on non-communication sites.

And I'm not sure I see a way to not couple those permissions that
doesn't have drawbacks that UAs seemingly can't accept. Wendy, are you
suggesting some modification to the Mode 1 in the document or a new
mode?

Justin and co-author: I'm glad you guys have gotten to this point and
written this up, thanks!

---

From: Wendy Seltzer <[email-masked]>
Date: Tue, 3 Nov 2015 20:23:25 -0500

> audio/video communication.

The last paragraph was aimed mostly at thinking in advance about the
next new privacy-impacting feature.

> address gathering on non-communication sites.

Yes, that's a good step forward, and it may be the most practical
response here. Let's not describe the permissions as coupled *because*
one is "more sensitive" than the other. Different users will have
different sensitivities. If the limits of the dialogs mean that they're
combined in browser UX, then at least we're providing the hooks for
extensions and config-file hacking to de-couple them. Tool-providers and
trainers can help users who need the differing configs to get them.

Thanks,
--Wendy