Re: [rtcweb] Security implications of host candidates

[Justin Uberti <[e-mail]>]

Thanks for the new version. I tried a few scenarios and agree that this
technique can identify a same-host situation fairly reliably, especially in
wireless environments; I typically saw ~2 ms latency for same-host and 5-10
ms latency (with occasional spikes) for over-the-air connections.

I'm still not quite sure what we should do about it; as noted, public
IPv4 + user-agent (http://www.whatsmyua.info/) is probably unique in the
vast majority of cases, and the situation is unavoidable with IPv6.



On Wed, Jul 4, 2018 at 2:12 PM youenn fablet <[e-mail]> wrote:

>
> Le mar. 3 juil. 2018 à 14:40, Justin Uberti <[e-mail]> a écrit :
>
>> Updated fiddle (outputs to display as well as console):
>> https://jsfiddle.net/juberti/x7a8ut0q/37/
>>
>
> Right, this shows the local loopback latency.
>
>
>> On Tue, Jul 3, 2018 at 11:16 AM Justin Uberti <[e-mail]> wrote:
>>
>>> I wasn't able to get that example to work (tried with 2 Chrome and 2
>>> Safari instances, got a setRemoteDescription error both times), but I was
>>> able to make a JSFiddle <https://jsfiddle.net/juberti/x7a8ut0q/25/>
>>> which does something similar in a single page. At present, even host-host
>>> connections were seeing a 2 ms RTT, possibly because of the clamping
>>> <https://developer.mozilla.org/en-US/docs/Web/API/Performance/now> that
>>> has been applied to performance.now() to deal with Spectre et al.
>>>
>>
> I updated
> https://evening-thicket-98446.herokuapp.com/src/content/peerconnection/datachannel-b2b/,
> it should hopefully be more intuitive to use this time:
> 1. load the page in one device
> 2. load the link provided by the page on another device
> 3. click 'call' on the first page
> 4. a latency value should appear on the page and be continuously updated
>