Re: PING feedback on WebRTC 1.0

Hi,

On 27/01/2017 17:12, Dominique Hazael-Massieux wrote:
>> 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.
>
> 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.

Here is some more detailed explanation about your points 1 & 2 above. I
would appreciate if you could also indicate whether this addresses your
initial comment - preferably, before the end of this month.

----
# Leaking of local IP addresses

As described in the spec and the in the [supporting IETF
spec](https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/),
browsers can operate in 4 modes with regard to their policy of
disclosing "local" IP addresses. The 4 modes represent different
possible trade-offs users may want to make between limiting exposure of
these IP addresses and performance of audio/video communications.
So what drove the design was the recognition that different users will
want to make different trade-offs for different Web sites, and the
proposed default mode of operation (mode 2 in the IETF document) offers
a balance where no sensitive information gets leaked prior to consent on
camera/mike usage, while still allowing quicker network path when
consent has been granted.
The proposed mitigation is to let users select a stricter (or looser)
mode via their user agent.

# Change to the same-origin policy because of p2p communication
WebRTC does not change the same-origin policy: an origin cannot obtain
data from another origin using the datachannel API without its cooperation.
WebRTC does offer a more direct transmission path from one browser to
another peer (a browser or not) where the server attached to a given
origin only needs to be used once for establishing the connection rather
than serving as a relay (which is what WebSockets or even XHR enables).
But the existence of that transmission path does not alter the
restrictions of data across origins.
As a result, it's not clear that this feature needs any specific mitigation.

# Client-side or device id leakage
Beyond IP addresses (addressed above), the usage of the WebRTC API
exposes more detailed and client-bound information about underlying
software and hardware.
The expected mitigation for this risk is the one used for other similar
features: browsers can support a mode where they disclose a uniform set
of information instead of the one that would enable the more customized
experience.

# Ad networks using WebRTC for accessing IP address
We believe that implementation of the mode 2 described above as the
default mode of operation will severely limit that practice since only a
limited number of IP addresses will be disclosed by default.
----

Thanks,

Dom

> 1. http://w3c.github.io/webrtc-pc/
> 2. https://w3c.github.io/mediacapture-main/
>

Received on Tuesday, 7 February 2017 10:28:53 UTC