> 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.
"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)
You just need _one_ device in the region, which can connect to the VPN or proxy service you were already using (the assumption seems to be that the attacker has a large number of IPs they can access through such a service). That device will get some added latency from going through the VPN/proxy, but because it’s physically close, the added latency will be small, probably not enough to reliably detect.
Does AWS Lambda count as a machine for these purposes? If so, you can get a nearly infinite number of them just by cycling a config param and casting another vote.
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.
Completely anonymous online polls are impossible, I'm thinking the goal is to have effectively non-publicly identifiable polling with the ability to disallow double voting. Seems absolutely trivial if Every Relevant Citizen was set up with their own API / digi-thumbprint.
While I don't mind 7 billion people knowing what I intentionally said publicly, I don't want 7 billion people knowing where I sleep or where I am at this exact moment.
Depending on the importance of the poll, one could definitely apply these other requirements.
By this logic every government gives a uniquely IDable device to its citizenry for engaging polls.
Besides ... if it was "important enough" to break, getting around geofencing etc. is a trivial/already solved part of this.
* 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.
> 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.
This is so sad.
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?
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'
The proposal has other flaws, but phone to tower latency isn't one.
Yep. Per the article (last point under "How it works"):
> Users with a high latency to all servers can be excluded from polls, as this is a strong indicator of a VPN/proxy usage
Something seems off about how they're measuring latency (which seems to be "fetch various AWS Lambda endpoints"), since their system seems to think that I have hundreds of milliseconds of latency even to the nearest AWS region (even though in practice it should be an order of magnitude lower), and multiple seconds to the other side of the world.
edit: well, if the slowness is just on last-mile delivery, then it should be a fixed amount of overhead added to each connection (rather than a multiplier). For instance, I have about 8ms of latency added by my ISP just by the first hop into their network. But it's that same 8ms overhead whether I'm connecting to a server on the other side of town, or on the other side of the world.
I don't see anything terribly idiotic in that.
edit: to be clear I think this is likely one of those solutions that creates more problems than it solves. There's a gulf of sympathy separating that from "idiocy," however.
If you have a question let me know.
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.
I don't think the technique can accommodate that. But I would love to be proven wrong.
Starlink internet customers, and users of Apple's private relay (vpn-like service) would all be excluded?
Care to elaborate? I don’t know why anyone would do this.
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.
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.)
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.
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
tc qdisc add dev eth0 root netem delay 250msPeople have been doxxed/compromised in the past by opening links or visiting sites from an adversary who used source IP to geolocate someone.
I can't see it being more than a verification of existing GeoIP databases and possibly a way to detect some VPN use.
Conversely, can this be used to show that someone is NOT a chinese/russian bot? I've had enough with people accusing me lol.
If crypto-scammers can bypass geo-restrictions for blogspam, I'm confident that state-level actors can do that even better for geopolitics.
...which is what fails via 100 methods. I personally can't believe this is omitting addressing the things that would basically ruin this.