Abusing WebRTC to reveal coarse location data in Signal
1–10 of 64 posts
Re: Abusing WebRTC to reveal coarse location data in Signal
#2I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
Re: Abusing WebRTC to reveal coarse location data in Signal
#3I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
That's pretty interesting. So, effectively, a triangulation based on latency times?
Re: Abusing WebRTC to reveal coarse location data in Signal
#4I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
That's funny, I was just working on a POC like this today[0] - it's accurate most of the time for my location but I haven't tested from other locations. You'd need to tweak the 'known' servers on and off to find the optimal arrangement because you'd need to be somehow inside the polygon. I was planning to find a way to discover these itself and other tweaks (like trying multiple times then averaging out)
Edit: the paper I found related to this is here[1]
[0]: https://github.com/stagas/http-geolocate
[1]: https://homes.cs.washington.edu/~tom/support/geoloc.pdf
Re: Abusing WebRTC to reveal coarse location data in Signal
#5I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
Would be interesting to see a link! That doesn't sound like it would get an accurate guess to me, given facts like "light travels slower in copper than fiber" and "your packets have to enter a country through specific large hubs" etc etc.
Re: Abusing WebRTC to reveal coarse location data in Signal
#6I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
That's pretty interesting. So, effectively, a triangulation based on latency times?
> So, effectively, a triangulation based on latency times?
Yes.
Re: Abusing WebRTC to reveal coarse location data in Signal
#7I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
That's funny, I was just working on a POC like this today[0] - it's accurate most of the time for my location but I haven't tested from other locations. You'd need to tweak the 'known' servers on and off to find the optimal arrangement because you'd need to be somehow inside the polygon. I was planning to find a way to discover these itself and other tweaks (like trying multiple times then averaging out) Edit: the pa…
https://vercel.com/edge-network
This page contains websocket addresses of a CDN that returns ping pong from a huge number of locations. It works surprisingly well for working out very fine grain location in just playing with it.
Re: Abusing WebRTC to reveal coarse location data in Signal
#8I recall seeing a paper where they showed how close you can geolocate with various numbers of peers to the target, by using network latency alone
Would be interesting to see a link! That doesn't sound like it would get an accurate guess to me, given facts like "light travels slower in copper than fiber" and "your packets have to enter a country through specific large hubs" etc etc.
If you have enough machines you can just use machines after those large hubs. The copper/glass light speed difference doesn't matter much because the speed differences added by hops in the middle are usually orders of magnitudes higher.
In the end, unless you've got machines next door pinging your target you won't be able to differentiate between houses or city blocks.
Re: Abusing WebRTC to reveal coarse location data in Signal
#9Earlier quoted context omitted.
That's funny, I was just working on a POC like this today[0] - it's accurate most of the time for my location but I haven't tested from other locations. You'd need to tweak the 'known' servers on and off to find the optimal arrangement because you'd need to be somehow inside the polygon. I was planning to find a way to discover these itself and other tweaks (like trying multiple times then averaging out) Edit: the pa…
https://vercel.com/edge-network This page contains websocket addresses of a CDN that returns ping pong from a huge number of locations. It works surprisingly well for working out very fine grain location in just playing with it.
Oh wow, they're actually doing the same thing, triangulating on latency. Hive mind, I guess. I used universities because I figured a)they won't mind, and b)they're more likely to have their servers on premises, then used a public reverse geoip to get their locations. I'll try to see if I can integrate with Vercel's edge network, seems more ideal.
Edit: no, I misunderstood, the location dot that's being displayed isn't the product of triangulation, they're just doing reverse geoip lookup. So, I wonder now if the edge network would perform better.
Update: it doesn't perform better. Either there is some kind of proxy redirecting their traffic or these servers aren't where they say they are, the center is skewed out completely. The universities win so far being correct and accurate most of the time.
Re: Abusing WebRTC to reveal coarse location data in Signal
#10I can see where a FQDN candidate is no biggie in a browser's offer/answer since DNS lookups occur all the time. But I imagine the simple fix for Signal's WebRTC use, since they control both sides of the exchange, is to just disregard non-IP candidates. Or even better, don't do anything with the candidates until the call is accepted. Worst case, could just have a geographically centralized signaling server (or shared IP). Granted, since Signal controls both sides, might as well only serve fixed "host" candidates and disallow any offer/answer with custom crafted ones.
One also wonders, to prevent other forms of leaks, if Signal can make a blanket policy to prevent DNS lookups or in general get tighter control on outbound network.