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

A bit aggressive. No, wouldn't connecting to a slow 3g tower affect ping times to all global servers proportionately?

The proposal has other flaws, but phone to tower latency isn't one.

> No, wouldn't connecting to a slow 3g tower affect ping times to all global servers proportionately?

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.

If eliminating signal from malicious, remote actors is more valuable than preserving signal from rural areas, which may very well be the case depending on the application, then adopting this might solve a real problem for you.

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.

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'

> Why is clock skew being used here at all? You're right, it's not actually necessary to use the client clock at all. It was easier to implement it that way initially and I kept it in the description and didn't think about it again.. Thanks for pointing that out. Since all timestamps are measured, the calculations can actually also be made afterwards without using the client clock timestamps at all. However this may add a bit more noise. > not the actual nonce The nonce can only be used once so it's ok to share it afterwards.

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.