> Latency-based geolocation can help protect poll integrity by:
> Detecting when poll responses originate from outside the intended geographic region > Identifying attempts to manipulate polls through elevated VPN/proxy usage
Unless the user also needs to complete a reaction-time test, couldn't this be defeated by using a remote desktop connection to a machine that is physically located in the other geography?
It just shifts which functions need to run on the proxy, from network routing to the browser itself.
I think this is covered on the page
"Successfully manipulating a poll which employs this method would require following efforts and resources:
Gaining control over a large number of devices in the target geographic region for submitting votes through those devices"
So yes, it seems like it can be defeated via a remote desktop (or any proxy in the allowed area)
Yes, and also, I'd argue that anonymizing your location is a sacred feature of the internet that anytime someone builds a better mousetrap we WILL build a better mouse. The internet is not a place where requiring proof of location is welcome.
For online polls, it should never be necessary, either: My rights to vote somewhere should depend only on my membership status to that somewhere, and not my current physical location.
Only a small subset of the IPs has proxies on them, so it would be detectable if a disproportionate amount of traffic is coming from them.
My state lottery app doesn’t let you play outside the state. It detects screen sharing and VPN configuration and refuses to run if it sees these things.
Depending on the importance of the poll, one could definitely apply these other requirements.
That is true, the location proof is only for the hardware whose IP is used for submitting the vote request. However if remote desktop provider / cloud provider / VPN / Tor IPs are already blocked by the voting platform. Then it would require significant effort to acquire hardware in the target geographic region and equip it with a residential IP. Generally the whole setup only makes sense if IP's (or IP ranges) can only vote once per poll. Then large scale manipulations should become impractical.
having worked on IP geolocation in the past, I don't think this works. Though it can do a pretty good job of getting you in the right continent.
* Not all traffic goes through fiber - there are microwave links operating closer to the speed of light, though these are mostly reserved for high-speed trading. There's also satellite connections, but as long as they don't do satellite-staellite, they're slower.
* There are middleboxes messing with traffic, especially TCP, which add delay.
* If you rent servers in datacenters, you might not really know where they are. We had VMs relocated without our knowledge.
* Fibers links aren't direct, they tend to follow public right-of-ways. In much of the US, that's a rectangular grid along the highway system (look at a road map of the midwest sometime), increasing the delay by √2.
* Internet routing isn't shortest-path. It's get-this-crap-off-my-infrastructure, aka hot-potato.
* Anycast prefixes have IPs in multiple locations.
My experience was that with a lot of observation points, you could get within 10ms, 1000km in most places.
I work for IPinfo, and we run active measurements through hundreds of servers. Allow me to highlight the fantastic points you made.
> Not all traffic goes through fiber - there are microwave links operating closer to the speed of light, though these are mostly reserved for high-speed trading. There's also satellite connections, but as long as they don't do satellite-staellite, they're slower.
That is a valid point. In that case, we have to fall back on the geofeed, WHOIS, or other methods of geolocation information. We are actively researching this area, though.
> There are middleboxes messing with traffic, especially TCP, which add delay.
This accounts for some problems but not all of them, as we have multiple servers running active measurements on individual IP addresses.
> If you rent servers in datacenters, you might not really know where they are. We had VMs relocated without our knowledge.
That is normal. At the scale at which we operate, server location validity is extremely important. We run daily checks and actively flag these issues. If things don't add up, we communicate with our vendors and try to understand whether it is a network-related issue or something else.
> Anycast prefixes have IPs in multiple locations.
Yes. With anycast IPs, we have hints of all their available locations, but when it comes to picking one, we default to the ASN-reported location.
> My experience was that with a lot of observation points, you could get within 10ms, 1000km in most places.
We have been significantly reducing the number of ASNs where we have high RTT by getting a server "networkly" close to them.
---
I understand that this is not the absolute best location system possible, but within the scope of our industry, we are miles ahead of everyone else. We are continuously investing in research and infrastructure to improve our data even further.
> there are microwave links operating closer to the speed of light, though these are mostly reserved for high-speed trading
This is so sad.
I think routing not being shortest path (nor being consistent) is the biggest issue with this method.
Are you sure it'd only be accurate up to 1000km? I'm not as experienced but would have assumed that by sampling a dozen times, you would have at least 95% likelihood of a 100km radius
> Key Advantages: [...] Can provide supportive evidence for VPN/proxy usage, when the latency is too high for all server locations
I'm reading through the description, but I'm having trouble understanding the difference between a client having a higher overall latency due to bandwidth/connectivity concerns (e.g. a 3G phone) versus using a VPN. Both would have increased timings and the clock skew would be similar. Would both would be considered too high for proof of location?
There are a lot of valid critiques already, but here's another:
This technique will have to allow for over-all slow connections. This connection latency could be caused by over-provisioned office connections, torrents, bad gsm reception, cheap internet or a cheap device.
What prevents a client from strategically delaying specific requests, to simulate a slow device in the target geography. AFAIT, this would be indistinguishable from the scenarios mentioned above.
Well, it is not just "can" be done, but we at IPinfo actively measure the internet and produce IP geolocation data. Sure, there are some limitations with satellite, microwave, and certain WAN-based connections, but it is the best solution for IP geolocation available right now, and we are seriously committed to it. Currently, we operate nearly 900 servers running ping, traceroute, and network measurement activity. Literally yesterday, we hit a milestone of having a server across 300 ASNs. We base our servers across diverse locations and networks. I think at this moment we have very few ASN where we do not have sub 10MS ping times.
If you have a question let me know.
Has this been tested, or is it just an idea. I imagine it would have some very serious limitations. Perhaps it could tell if you are likely in the US or Europe, but I doubt could get much more granular than that.
Starlink internet customers, and users of Apple's private relay (vpn-like service) would all be excluded?
Reminds me of the case of the 500-mile email:
Usefulness of proposed metrics aside, I can't wrap my head around proposed use cases there.
If you don't require proof of identification for voting then one local voter can vote limitless times. If you do require it, why don't you trust it? Surely an identification is enough too choose if someone could vote or not.
It could be a nice addition to some social networks like Mastodon, I suppose, if people wouldn't care enough to create puppet accounts just to swing a vote, and false rejections/positives wouldn't mean losing or gaining something meaningful. Other then that, I have no idea.
It's an interesting concept.
Re: "Cannot be manipulated unlike GPS signal derived coordinates, which can be altered by the user's device before relaying them to the server"
Is it possible to ensure that the data is not manipulated? If the user had to install a voting software package on their phone, then couldn't that piece of software take responsibility for pulling the co-ordinates from the device and encrypting it? I am assuming most modern phones are secure enough that the signal from the GPS that is made available to applications can be trusted but maybe I am wrong?
Re Starlink: Is it possible to trace your route through a specific satellite and to look up the location of that satellite? That seems like a relatively easy and secure check (aside from the VPN/Proxy concerns which feel like they would be a larger challenge in this scenario since I am assuming the delays through the satellites would be more significant than delays through fiber.)
Have you ever wondered why most studies on humans use college students as test subjects? The answer is that they are easy to survey. Obviously though that can skew results quite a bit because the population is really not all that representative of the general public.
This product will do the same thing: it will help narrow the field of candidates to those who are easy to locate. I guess people who do marketing might like this because look high quality online survey results! And the bias is hidden well enough to keep your job! But the reality is that this will affect the results in a meaningful way.
For example, my ISP doesn’t support IPv6 so my entire home network is served by IPv6 provided by Hurricane Electric via protocol 41. So depending on what this service does with it I would likely be disqualified since my IPv4 is in a different state than my IPv6.
Long story short, cool tech demo and product I would personally avoid using or recommending.
This feels grossly incomplete, and not a barrier to an attack of even remedial sophistication. ie, low latency from any given machine doesn't have any relationship to external controlling connections to the machine.
I also don't see anything addressing the "1 external IP for n number of people" being addressed.
It's also a bit bizarre to have multiple references to "the speed of light" when this wouldn't work for someone remote desktopping in
More than a decade ago I wanted to revenge my brother (something childish) and at that time he played online games. As packet loss would be too obvious and the games usually require low bandwidth the most viable fun option was to add some latency. You won't see this option in your usual router.
tc qdisc add dev eth0 root netem delay 250msOr just adopt eID. I just signed a petition to ensure free and safe abortion in the EU and I could sign with eID from over 20 nations. Get with the program.
Proof of location has been researched/studied for a while. There are systems that depend on a mesh of RF connected nodes and associated economic game (which could be replaced by some government authority) to ensure validity. E.g. https://foam.space/about
Without a good amount of peering, this seems unlikely to work. There is really no guarantee about where traffic will exit a user ISP's network and enter the next. On average, sure, it may take a reasonably short path, but it might also travel halfway across the continent to traverse an IX.
Isn't this trivially broken? I can't use a VPN, but if I log into a shell at Amsterdam and run the program there (say, Firefox in a remote X Windows context), then all the code they might need will execute there. If any user interaction is needed, this can be pre-scripted.
I'm not seeing in the proposal what is to prevent variable latency - from network congestion, route changes, quality of service differences, ISP peering arrangements, last-mile connection quality variations, and router queue delays - being interpreted as a distance metric?
It would be nice if there was a standalone POC for the geolocation. I only found the vote website. There, one can enable the latency geolocation feature - but it doesn't display any results (it shows latency to various servers but not any analysis thereof).
This space is pretty cool, I worked on a similar logic based on large samples of pings to the ip so you don’t have to worry about clients having to ping out. Obv you are subject to the accuracy of the ip representing their location
Are any major fiber routes hollow-core? HFC signals should be ~50% faster than traditional fiber optic cables, and that might be enough to throw off this data.
https://ipv4.games/ will show you who will win at your polls.
When i went to buy a SIM card I had to show ID. Is that the case in all America? Why not offload verification onto telecoms.
At least they're up-front about the viability of remotely controlled voting farms as an exploit.
An iot botnet + command and control infra cooks this entire idea.
4chan is going to love this.
How would this solution differentiate a slow connection and a VPN?
[dead]
[dead]
Fantastic, solves the issue of bots from foreign adversaries. Everyone complaining doesn't seem to get it, it doesn't need to solve all usecases, but solving this one usecase is great.
Conversely, can this be used to show that someone is NOT a chinese/russian bot? I've had enough with people accusing me lol.
IPs can easily be spoofed. Until someone hashes all IPs with physical GPS coordinates, this is simply not a proof.