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.

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

For slow connections you can still make use Geo IP data (such as maxmind.com) to infer location, which should be quite reliable in most cases. You just cannot meet the stricter hardware location proof criteria based on latency. You may still submit a poll answer but it may not be included in the analyses, which require a higher degree of confidence for the location. For the objective of obtaining a hard-to-manipulate sample of popular opinion, this would only be an issue if people with slow connections give systematically different responses for a given poll. But this should then also become apparent when analysing the data and can be considered for any decisions derived from the poll.

Why is clock skew being used here at all? I'm confused why the client's clock is being trusted or consulted in any way for a measurement like this. I should probably click through and read the details.

ETA Ok, reading the code turned up not a lot of comments. But it did produce the following line. I hope that's for testing and not the actual nonce generation process:

nonce = 'ieoskirlyzauuv6ehdug8lift65fkrddeuu6f5z6ka'

No you read it right. The proposal is idiotic and Will resulted in rural voters being detected as foreign residents

> This technique will have to allow for over-all slow connections

I don't think the technique can accommodate that. But I would love to be proven wrong.

For example very slow ADSL connections or somewhere with poor phone reception.