this post was submitted on 26 Oct 2025
771 points (97.8% liked)
Mildly Infuriating
42668 readers
2387 users here now
Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.
I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!
It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.
Rules:
1. Be Respectful
Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.
Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.
...
2. No Illegal Content
Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.
That means: -No promoting violence/threats against any individuals
-No CSA content or Revenge Porn
-No sharing private/personal information (Doxxing)
...
3. No Spam
Posting the same post, no matter the intent is against the rules.
-If you have posted content, please refrain from re-posting said content within this community.
-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.
-No posting Scams/Advertisements/Phishing Links/IP Grabbers
-No Bots, Bots will be banned from the community.
...
4. No Porn/Explicit
Content
-Do not post explicit content. Lemmy.World is not the instance for NSFW content.
-Do not post Gore or Shock Content.
...
5. No Enciting Harassment,
Brigading, Doxxing or Witch Hunts
-Do not Brigade other Communities
-No calls to action against other communities/users within Lemmy or outside of Lemmy.
-No Witch Hunts against users/communities.
-No content that harasses members within or outside of the community.
...
6. NSFW should be behind NSFW tags.
-Content that is NSFW should be behind NSFW tags.
-Content that might be distressing should be kept behind NSFW tags.
...
7. Content should match the theme of this community.
-Content should be Mildly infuriating.
-The Community !actuallyinfuriating has been born so that's where you should post the big stuff.
...
8. Reposting of Reddit content is permitted, try to credit the OC.
-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.
...
...
Also check out:
Partnered Communities:
Reach out to LillianVS for inclusion on the sidebar.
All communities included on the sidebar are to be made in compliance with the instance rules.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You could probably just record the users ID and it's IP address. IP addresses that see a lot of different user IDs are either VPNs, companies or universities.
Or they are just home users behind a CGNAT, which more and more ISPs use.
And even if they aren't, home users usually have dynamic IPs, meaning it can change.
Another thing that only very large companies can do is see the response time and compare packet size from different servers to narrow down your location, effectively defeating the VPN in a lot of cases.
Hypothetically, a specific amount of bytes gets sent to server B, response time indicates it was received 300 miles away which matches the response time of going from Server B to Server A where the user lives.
Of course it's still important to use a VPN, if only because those big companies don't want us to.
The latency to your VPN server is a constant added to the latency between your VPN server and whatever servers you are connected to. As long as the user's VPN service doesn't use different VPN servers for different destinations, it is impossible to determine the location of the user behind the VPN based on latency, and in general it is impossible to determine how far a user is from their VPN server because of varying latency introduced by the user's own network or by bad infrastructure at the local ISP level. You can only know how far they aren't based on the speed of light across the surface of the earth.
But, without a VPN, this is a real attack that was proven by a high school student using some quirks of Discord CDNs. Even without using Discord's CDNs, if somebody wanted to locate web visitors using this technique, they could just rent CDN resources like nearly every big company is doing. Of course, if you have the opportunity to pull this off, you normally have the user's IP address and don't care about inferring the location by latency. The reason why it was notable with Discord was because the attacker was not able to obtain the victim's IP address.
You say what I described is impossible but it's been demonstrated by researchers such as "CPV: Delay-Based Location Verification for the Internet" by AbdelRahman Abdou with the Department of Systems and Computer Engineering, Carleton University Ontario.
Furthermore, on top of that method, if a company has access to data from servers in multiple places along the chain between endpoints, then they can see that a series of packets of specific size are traveling in a specific direction, narrowing down the location of the other endpoint. A company like Amazon, whose AWS servers make up almost 30% of the internet.
One of the more convoluted methods to defeat this approach was to simply add more stops along the chain, fragment the encrypted data into multiple parts, and pass it along random paths to the endpoint. I believe, but I could be wrong, that Tor utilizes this method. The problem with that is: it's slower.
It is impossible. CPV is only going to allow the attacker to know that the device is probably not located next to the VPN server. It can only prove a positive, not a negative.
The second method you're describing is only possible for people who control internet infrastructure and are able to infer correlations data going into your VPN server with data going out of your VPN server, which is both easier and more difficult than you're suggesting. The attacker does not need to most of the internet routers because they only care about the data going into and out of the VPN server (it's onion routing where the attacker needs to control many routers), but the attacker does need to have a powerful enough device to be inferring (hopefully) encrypted network flows on the public network to the packet sizes of encrypted VPN traffic for all of the traffic that is passing through that VPN server at the same time.
This...sounds a bit like bs. Can you share a more detailed writeup? At best you could get a radius, but that wouldn't really be helpful
I imagine they could compile large datasets of ping times and server locations and do some extrapolation. I don't think it ever goes past a best guess but they'd have an idea (if what this person said actually happens).
Companies dont really need to know where you are. They just need to know where you aren't. If you are not within a certain threshold of response time to certain cdn servers, then its reasonable to assume that you are outside their contractually obligated broadcast region.
They kind of have it backwards. They aren't triangulating your location, they are taking the location your connection tells them you are and tests to see if that is correct or not by checking with known servers in an area around your claimed location. It can verify you are not where you say you are, but beyond that it can't find you. At least, not the paper the person is mentioning - this "other method" they mention doesn't appear to be linked to any paper or anything and might just be their personal theory, not sure.
Yeah there was a cool paper on Delay Response method by AbdelRahman Abdou with Department of Systems and Computer Engineering, Carleton University called "CPV: Delay-Based Location Verification for the Internet".
The other method I mentioned, checking packet size and general direction, would require accessing data along multiple stops before reaching the other endpoint with which to compare the sizes of encrypted data packets and use that to identify what is traveling where, which either has not been demonstrated or the companies utilizing it haven't admitted to it, yet. It's not a stretch to think it's happening, though, with massive companies like AWS and CloudFlare or telecom giants like AT&T.
The CPV paper was not doing what you are saying, defeating a VPN by finding your real location. It is basically the opposite - if you are using a VPN to claim you are in a place, it can verify that you are not in that place. It doesn't find your location, it can only verify you aren't in the area you claim to be.
If you can prove where people aren't then you can prove where they are.
Not really, because the only reason they have a location to test against is because the connection looks like it is coming from the vpn server location. They don't have any other location data to test against, and even if they decided to then run the test against every possible location on the planet, they still have the issue that their data is heavily skewed by the fact your traffic is flowing through a vpn, so your latency is not going to be perfectly matching their test servers unless they force the test servers' traffic through the same vpn server.
Nothing about this is setup to find your location on the other side of a vpn - it is basically testing if you are using a vpn or otherwise "spoofing" your location and returning a yes or a no.
I was like 3 paragraphs into a writeup about response times, latency, probabilities, etc but I realized you already have all the information and can't be reasoned with.
You do know what I mean by "response time" right? The recieving computer gets the packets and sends word back. NOT the VPN node, the VPN is not unencrypting traffic to emulate a real computer, it's instead just relaying the packets TO YOUR MACHINE. VPNs are not the perfect black box void immune to complicated analysis.
Do you not think a VPN will affect response time?? I implore you re-read the paper you keep referring to because they spell it out pretty basically what they are doing - and finding a person's actual physical location behind a VPN is not it.
I am not claiming a VPN is a perfect or complete solution... The modern web has an absolute ton of ways to track you even through a VPN, but CPV isn't it.
VPN will affect response time and that effect on response time is easily measurable.