Abusing WebRTC to reveal coarse location data in Signal
medium.com
medium.com
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?
There's an interesting fundamental tradeoff somewhere between optimization and information. If you make things as efficient as possible, you'll probably leak information.
at which point the threshold could lower ...
I realize that ping is a very poor benchmark as most routers do not handle ping in their fast path, but it's not adding 40ms of latency. So I suspect my modem.
I’d recommended you look into it, and potentially get another modem. If all my requests started taking another 30ms, I’d consider my network degraded.
This effectively means that even if your share of the total upstream link of a network "collision domain" (shared coaxial medium really) is low (i.e you're using less than 1/n and accordingly should not be experiencing queueing in the modem), you might be seeing latency spikes due to having to compete and wait for transmission timeslots.
My local DOCSIS link is experiencing anything between 0 and 60 milliseconds of latency which I suspect is mostly due to this (since it's inversely correlated to upstream bandwith).
I'd be interested in hearing counterexamples, but I imagine that people with good experiences are on DSL or Fiber.
That's not buffer bloat (but might nevertheless be something that happens on DOCSIS modems, although I haven't heard of buffering several packets before contending for an upstream send grant).
Buffer bloat, while also rampant especially in shitty CPE like most DOCSIS modem/router combinations, would only occur when your upstream is saturated.
Supposedly though, on DOCSIS, the upstream access contention algorithm used can sometimes add the latency you describe, adding latency even for single packets.
It seems like the only way to avoid that is with one bucket (constant time).
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
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.
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.
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?
Anyways, time to sleep. Sun's getting too bright.
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
You can easily be next door to someone, and your packets go all the way across the country to get there.
I've definitely seen cases where my latency to two servers in the same building were wildly different, depending on the paths my ISP and their ISP(s) routed the traffic.
I'm about 22 ms roundtrip away from ISPs facility at the local internet exchange in Seattle. If a server is connected to that exchange, and traffic flows through the exchange both ways, I see ping times of about 22 ms. Sometimes, my ISP will send traffic through San Jose instead, but the server returns the traffic in Seattle, and that adds about 26ms, so I get a 48 ms ping. If both sides route through San Jose for whatever reason, I'll get 74 ms, which is close to what I'd get if the routing was sensible and the server was in the Washington, DC area. (You normally can't see the routing back from the server, but sometimes you control the server, too).
If I were building something like this, I'd want to try to determine how much of the latency was the user getting to where their ISP interconnects with other networks (or with multiple routes within their own network), and then where that interconnection location is. I'd guess you can get a pretty good idea of the interconnection location, based on reasonable network paths from there, but distance from the interconnection point is going to be tricky, most residential networking technologies add much more latency than the speed of light, so your upper bound of distance is going to be pretty far off. Of the roughly 22 ms I see to Seattle, about 20 ms is just coming from the DSL termination; when I had AT&T GPON, it added about 4 ms to my pings; that's a lot of distance.
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.
Yes.
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.
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)
Any idea when more information might be available on this? Asked moxie years ago to add this and know 100s of other have too.
Worth noting the FAQ as it relates to the PIN length is not correct, “How long can my PIN be? There is no limit. Feel free to add as many characters as you want.” [2] ...tested it and longest PIN I was able to create was 20 characters all numeric.
[1]: https://signal.org/blog/signal-pins/
[2] https://support.signal.org/hc/en-us/articles/360007059792-Si...
I thought Signal was all about privacy by default? :D
Signal fans love to dunk on Telegram for secret chats not being the only kind of chat.. well turns out on Signal, private is not the only kind of call, and your IP address is exposed by default.
EDIT: What I meant by this, as upon re-reading it seems unclear, is that the privacy as I understand it is not supposed to protect one party from the other party with which they are communicating, but rather conceal the conversation from third parties.
Signal's conscious choice is to interpret a user adding another as a contact as an implicit signal to mark them trustworthy enough to forfeit the second kind of privacy in exchange for better voice quality (latency and bandwidth) as well as to lighten the strain on their resources.
In my opinion, this is a reasonable default: Relaying all voice calls would use significant resources and might increase latency for users far away from the nearest relay (topologically or geographically).
Also, what's with the snarkiness? Are Signal's security tradeoffs or vulnerabilities somehow making Telegram more or less secure?
The two of them intentionally make different security/usability tradeoffs (the most significant one being Telegram's choice to provide a server-side message history visible to the service operator).
Of course this tradeoff isn't inherently bad, but weird communication and branding on Telegram's side in the past has given this a weird aftertaste that, at least for me, is still sticking around.
Essentially, they are not much better than Whatsapp stans.
Well, 5 years ago...
It it without a doubt that he is under constant electronic and physical surveillance by the Russian and American governments. His phones and computers are also very likely compromised. At that point your choice of messenger app matters about as much as the color of your socks because the interception is happening at another layer.
How to keep it free of custom targeted malware? That is another question!
Two key words in your comment are both spectrums: trust and privacy.
Most people implicitly trust their hardware more than Snowden does now -- they overestimate the security from the factory and he probably has better expectations of the likelihood of hardware compromise.
On the privacy spectrum, one point is how much privacy you think you have, and the other (unknown) point is how much you actually have. Similarly, I think Snowden's situation and prior experience helps him more accurately understand where those points are; the rest of us are up on the first peak of the Dunning-Kreuger chart.
But one can use Session (a fork of Signal) over Lokinet (an onion routing network, which is similar to Tor).
Even the updated version of Signal merely relays stuff through a proxy. That is, there's just one hop, and that's trivial to deanonymize. With Lokinet, there are multiple hops, so adversaries must compromise multiple nodes.
Also, Session requires no PII for account creation. That's great for anonymity, but there's no built-in authentication. So users must authenticate contacts in meatspace or via other communication channels.
Creating a new service node requires a providing a stake in Loki, which I believe currently costs on the order of $5000. And the only source is Loki held by existing service nodes. So arguably, as the creation rate for new service nodes increases, the price of the requisite Loki stake increases, perhaps supra linearly, or even exponentially.
There's also the issue that service nodes that behave maliciously lose all of their Loki, both the initial stake, and anything that they've earned.
I don't know specifics, however. So I don't know just how high the bar is for malicious service nodes.
I got a blank page on the original domain, perhaps due to DNS adblocking.
Here, regardless of if you have that setting enabled or not, and regardless of if you accept the call, contacts and non-contacts can cause your device to make a DNS request, which will leak your DNS server. And if using a DNS server with EDNS Client Subnets, the first 3 octets of your IP address will also be leaked.
I think there's another issue like what you're describing which can kind of obviate this, though: the vast majority of Signal users probably use Signal on their regular mobile phone and its number, not a burner phone/SIM/number. (Few users probably even own a burner phone/SIM/number or understand what that is or why they might want one or how they'd obtain one.) So... everyone can just see your phone number, which probably has an area code corresponding to your city or close to it, and the other digits can possibly pinpoint it even more precisely than that.
Anyone who isn't tunneling all of their DNS traffic with a VPN or otherwise probably also isn't anonymizing their phone number and just has the app installed on their personal, standard cell phone.
If they aren't traveling and haven't moved recently, you can probably see what city they're in just from that. (This exposure does allow coarse location detection even when someone's traveling, though it's a lot more coarse than the area code, unless the Client Subnet value is being sent.)