Re: [rtcweb] Security implications of host candidates

Le lun. 2 juil. 2018 à 16:04, Justin Uberti <juberti=
40google.com@dmarc.ietf.org> a écrit :

> https://tools.ietf.org/html/draft-mdns-ice-candidates-00 has a section
> where it talks about the privacy implications of being able to determine
> that two browser contexts are running on the same machine by making a
> host-host connection and analyzing the connection RTT:
>
>    A successful WebRTC connection between two peers is also a potential
>    thread to user privacy.  When a WebRTC connection latency is close to
>    zero, the probability is high that the two peers are running on the
>    same device.  Browsers often isolate contexts one from the other.
>    Private browsing mode contexts usually do not share any information
>    with regular browsing contexts.  The WebKit engine isolates third-
>    party iframes in various ways (cookies, ITP) to prevent user
>    tracking.  Enabling a web application to determine that two contexts
>    run in the same device would defeat some of the protections provided
>    by modern browsers.
>
>
> I would think that this concern would still exist even without host candidates, through either
>
> a) IP matching + user-agent fingerprinting
>
>
It is true that one can probably try breaking this protection using
fingerprinting, and public IP is a great way to converge more quickly.
That said, this is something we should try to fight against.

b) srflx-srflx connections and NAT hairpinning
>
>
Aren't the packets supposed to go through the router? In such a case, I
would hope the latency to be roughly the same, no matter whether the
devices are the same or not. That is indeed something that should be tested.

> FWIW, this topic does not appear to be noted in the rtcweb security docs.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>