>Even Edward Snowden, the well known American Whistleblower, claims “I use Signal every day.”
Well, 5 years ago...
Abusing WebRTC to reveal coarse location data in Signal
11–20 of 64 posts
Re: Abusing WebRTC to reveal coarse location data in Signal
#12I 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?
Hate to be a pedant, but it's technically trilateration.
Re: Abusing WebRTC to reveal coarse location data in Signal
#13Earlier quoted context omitted.
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'…
Unimpressed with yours. Why? Because my ISP got some IPv4 space recently, which was formerly allocated to .ua, .ru, .iq, & .ir. While being physically next to or in Hamburg, .de.
That led to all sorts of inconveniences for some people, suddenly barred from logging on, or using the sites they frequent, because they used outdated geo-ip data. I didn't even notice, except for the outrage in their customer forum.
Now yours consistently puts me somewhere into, or onto the shores of the Black Sea, while Vercels doesn't. So that makes me suspicious of your claim by using latency alone.
Edit: There seems to be outdated geo-ip information factored in somewhere. Why else it would put me IN the Black Sea?
Re: Abusing WebRTC to reveal coarse location data in Signal
#14Earlier quoted context omitted.
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'…
Unimpressed with yours. Why? Because my ISP got some IPv4 space recently, which was formerly allocated to .ua, .ru, .iq, & .ir. While being physically next to or in Hamburg, .de. That led to all sorts of inconveniences for some people, suddenly barred from logging on, or using the sites they frequent, because they used outdated geo-ip data. I didn't even notice, except for the outrage in their customer forum. Now you…
I mentioned I just started working on it. To try for yourself you'd need to clone and tweak the servers list to find an optimal arrangement for you. The problem as I see it is that jumping continents occurs really artificial delays which skews the result significantly, so it first needs to identify your relative whereabouts, then decide on an optimal set of servers. If you clone and tweak the servers to place yourself inside the polygon you'd see it does locate you. Vercel is doing a reverse geoip lookup, so your location is preconfigured in some database based on your ip.
Re: Abusing WebRTC to reveal coarse location data in Signal
#15I 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…
Disregarding non-IP candidates is exactly what we've chosen to do (and which the new versions of the app do).
The downside of disregarding all candidates until the call is accepted is that post-accept connectivity would be much slower.
Going through a server to hide your IP is an option in the settings in the app, but it can potentially lead to higher call latency, so there is a trade-off.
To prevent issues like this in the future we are taking more control of WebRTC's behavior with a fork of WebRTC (Signal uses WebRTC) and are providing patches to upstream WebRTC as well.
(I work at Signal on calling)
Re: Abusing WebRTC to reveal coarse location data in Signal
#16Earlier quoted context omitted.
Unimpressed with yours. Why? Because my ISP got some IPv4 space recently, which was formerly allocated to .ua, .ru, .iq, & .ir. While being physically next to or in Hamburg, .de. That led to all sorts of inconveniences for some people, suddenly barred from logging on, or using the sites they frequent, because they used outdated geo-ip data. I didn't even notice, except for the outrage in their customer forum. Now you…
I mentioned I just started working on it. To try for yourself you'd need to clone and tweak the servers list to find an optimal arrangement for you. The problem as I see it is that jumping continents occurs really artificial delays which skews the result significantly, so it first needs to identify your relative whereabouts, then decide on an optimal set of servers. If you clone and tweak the servers to place yoursel…
At least they are current ;-)
Re: Abusing WebRTC to reveal coarse location data in Signal
#17The only universal fix I can think of for this class of attacks is to have routers bound latency to a lower limit (eg. 200ms), with fixed latency buckets (eg. 500ms granularity) when it goes beyond that.
That is, no traffic would traverse the router in less than 200ms, and every other flow would be fixed at 700ms, 1200ms, 1700ms, etc amounts of latency. Tweaked correctly that would limit location to continent, unless I'm missing something.
It would effectively trade quick responses to/from close networks for some extra amount of privacy (in the case that GeoIP has already been taken care of)
The latency would have to be controlled on both ingress and egress to account for internal and external threats. I've got a niggling feeling that an attacker that could control latency of enough geographically diverse networks could find the boundary by manipulating responses to get finer detail, but can't quite work the problem into a solution...
Is there a less horrible or more reliable universal mitigation that I'm not thinking of?
Re: Abusing WebRTC to reveal coarse location data in Signal
#18I 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…
Weird. Your POC seems to be placing me almost directly opposite in the caucasus.
Re: Abusing WebRTC to reveal coarse location data in Signal
#19I 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…
This is commonly referred to as "ping triangulation" and seems to be reinvented every few years. It sounds good in theory but in practice performs poorly unless ran consistently for days, which is why few researchers end up writing it up or publishing POCs for the next person to find. :)
You should take a look at network path convergence for geolocation instead. You can see a demo of the tool I wrote at https://traceroute.guru/tr/209.216.230.240
Re: Abusing WebRTC to reveal coarse location data in Signal
#20https://archive.is/SYq8H
I got a blank page on the original domain, perhaps due to DNS adblocking.