PING feedback on WebRTC 1.0

Dear Privacy Interest Group,

Back in May, and as part of the wide review of the WebRTC API [1], we
(the WebRTC Working Group) received the following input from your group
(of which I haven't found an archived copy):
> Questions summarized from the PING discussion:
> 1. In reading privacy/security considerations of the spec, the group 
> recognized the various issues, but it was not always clear how
> issues were solved or mitigated. Can you provide more documentation
> on countermeasures and why certain decisions were made? Examples:
> the concrete reasons to accept changes to the same-origin policy.
> (e.g., not only because websocket does it.)
> 2. Related items that were of concern, for which a response would be 
> helpful: leaking of local IP addresses; change to the same-origin
> policy because of p2p communication; client-side or device id
> leakage; ad networks using WebRTC for accessing IP address.
> 3. As a user, I have concerns about wanting to know, for example, in 
> WebEx: when I am speaking and where the data is going. Which items 
> (indicators) are going to left up to the application, and which in
> the user agent? For example, camera light should be on when the
> camera is active--that shouldn't be left up to the application. What
> would be helpful here is to describe what kind of risks exist and how
> they are prevented or solved.
> 4. It is troubling that once a WebRTC connection has been granted,
> could be very difficult for a non-expert user to discover/revoke --
> how is this concern being addressed?
> 5.  What information is available prior to a permission prompt?
> Example: for a Tor activist user, what would they do when they might
> have to choose between communicating and revealing sensitive local
> information?

These points of input have been tracked in our issue tracker as the
following issues: (1-2) (3 (4) (5)

I have been remiss in getting back to you on these topics to allow the
group to move forward.

After discussion with some of the PING participants, we closed issue 689
since it appeared to be a matter with the Media Capture and Streams API
[2] rather than the WebRTC API itself; it is worth noting on this matter
that the Media Capture and Stream specification itself has evolved
recently to be more specific in terms of how permissions can be
discovered and advertized - topic on which we expect to come back to you

I think that likewise, issue 688 has more to do with indicators of
camera usage, which again is a matter of Media Capture and Streams - I
would thus like to proceed with closing that issue unless we hear
differently from you.

For issue 690, the issue itself has a proposed answer to your question 5:
> I think a Tor activist user would have its browser configured to use
> mode 2, 3, or 4 of RTCWEB-IP-HANDLING where no "hidden" IP address
> gets revealed.
> But more to the point, I think the spec already addresses this:
> Mitigating the exposure of IP addresses to the application itself
> requires limiting the IP addresses that can be used, which will
> impact the ability to communicate on the most direct path between
> endpoints. Browsers are encouraged to provide appropriate controls
> for deciding which IP addresses are made available to applications,
> based on the security posture desired by the user. The choice of
> which addresses to expose is controlled by local policy (see
> [RTCWEB-IP-HANDLING] for details).

It would be useful to understand if you feel what additional information
needs to be added to the privacy section in that regard.

I plan on getting back to you on issue 687 (i.e. your comments 1 and 2
above) soon, but it would be great if we could already get closure on
the 3 issues described above.




Received on Friday, 27 January 2017 16:12:54 UTC