[HN Gopher] Proof of location for online polls
___________________________________________________________________
Proof of location for online polls
Author : c-riq
Score : 73 points
Date : 2025-01-14 20:31 UTC (2 hours ago)
(HTM) web link (ip-vote.com)
(TXT) w3m dump (ip-vote.com)
| jawiggins wrote:
| > 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.
| polon wrote:
| 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)
| comex wrote:
| You don't even need to gain control over a large number of
| devices in the region.
|
| 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.
| 85392_school wrote:
| If you're using a proxy, I don't think whether or not the
| source device is in the region changes anything. The only
| variance is in the time from where traffic exits the proxy
| to servers.
| banana_giraffe wrote:
| > Gaining control over a large number of devices in the
| target geographic region for submitting votes through those
| devices
|
| 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.
| ghayes wrote:
| Couldn't the "test" add some variety of math challenge, thus
| making a simple proxy insufficient. Obviously, this method
| would add more noise to the final calculation, but if the
| proxy would need to forward its data to the end-user machine
| to perform the math, then a simple proxy in this case
| wouldn't be sufficient.
| TrainedMonkey wrote:
| 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.
| c-riq wrote:
| 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.
| nine_k wrote:
| You are describing an ideal use case for a botnet of
| compromised home computers. Should command a much higher
| premium than sending spam.
| DeepYogurt wrote:
| For a motivated attacker its not that hard to add a few
| thousand raspberry pis to a residential internet network in
| most countries. Its really a quite practical attack when the
| stakes are governmental control.
| myself248 wrote:
| Or just compromise an entire ISP full of routers...
| kvdveer wrote:
| No need for lots compromised devices. Just a single device
| (probably doesn't need to be compromised) in IPv4 behind
| carrier grade NAT is typically enough to vary your IP, or
| plausibly reuse an IP.
| dheera wrote:
| 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.
| anilr wrote:
| 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?
| c-riq wrote:
| The goal is to easily get a representative and un-manipulated
| sample of popular opinion. To achieve that, it might be ok to
| discriminate against certain users who use connections which
| cannot prove their location, as long as it's not heavily
| skewing the results.
| raggi wrote:
| Tailscale uses latency to pick home DERPs and I am re-
| evaluating it as we observe what appear to be manipulated STUN
| latencies for users in Asia particularly in or close to China.
| The latencies are often raised to over 300ms to affect this,
| and steer clients toward the US west coast. The reason for
| these manipulations is unclear, but it's easy to speculate.
| mulmen wrote:
| > The reason for these manipulations is unclear, but it's
| easy to speculate.
|
| Care to elaborate? I don't know why anyone would do this.
| raggi wrote:
| This is tin-foil-hat speculation, but for example, if you
| observe a locality measurement protocol picking where it
| should connect to, but you already know all of the local
| sites of interest that are relevant, you might want to find
| remote sites of interest. If you manipulate the more open
| sampling protocol to lean toward that remote site, you can
| then observe where secured connections to which you're
| otherwise blind, connect to. Now you have new remote
| targets of interest.
| c-riq wrote:
| I tested it from my home and got a radius of about 200 km. But
| would be nice to get some additional validation. In any case
| it's not super precise but it adds more friction to
| manipulation and in conjunction with IP based geolocation and
| other things it may turn out to be useful for some parts of an
| online democracy.
| skaushik92 wrote:
| > 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?
| 38 wrote:
| No you read it right. The proposal is idiotic and Will resulted
| in rural voters being detected as foreign residents
| croshan wrote:
| 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.
| vitus wrote:
| > 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.
| jknoepfler wrote:
| 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.
| matthewdgreen wrote:
| 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'
| c-riq wrote:
| > 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.
| KaoruAoiShiho wrote:
| 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.
| kvdveer wrote:
| Yesterday I fought off someone/something doing Chinese language
| crypto-blogspam on my website. Ip-addresses were all unique
| (mixed ipv4&ipv6), but all were 'located' within 100km of my
| server in central Europe.
|
| If crypto-scammers can bypass geo-restrictions for blogspam,
| I'm confident that state-level actors can do that even better
| for geopolitics.
| engineer_22 wrote:
| 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.
| hnav wrote:
| I think you can still buy prepaid SIMs in the US without ID.
| madars wrote:
| Fortunately it is not. https://prepaid-data-sim-
| card.fandom.com/wiki/Registration_P...
| lotsofpulp wrote:
| With eSIMs, I think all you need nowadays is a credit card +
| billing address.
| dangoodmanUT wrote:
| 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
| mac3n wrote:
| 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.
| reocha wrote:
| I think routing not being shortest path (nor being consistent)
| is the biggest issue with this method.
| jampekka wrote:
| > there are microwave links operating closer to the speed of
| light, though these are mostly reserved for high-speed trading
|
| This is so sad.
| xethos wrote:
| Sure, but if it becomes ubiquitous, web devs will assume
| lower latency. That wouldn't make it _less_ sad, just makes
| different people sad - my first guesses are those at crowded
| areas with overloaded cellular connections, and Australians.
| nickdothutton wrote:
| 4chan is going to love this.
| paranoidrobot wrote:
| This is not a new idea, and I don't believe it will help the
| malicious actors of the world.
|
| People 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.
| INTPenis wrote:
| Or 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.
| kvdveer wrote:
| 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.
| SteveVeilStream wrote:
| 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.)
| cess11 wrote:
| At least they're up-front about the viability of remotely
| controlled voting farms as an exploit.
| brian-armstrong wrote:
| 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.
| ortusdux wrote:
| Reminds me of the case of the 500-mile email:
|
| https://www.ibiblio.org/harris/500milemail.html
| lesostep wrote:
| 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.
| dboreham wrote:
| 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
| tomtomistaken wrote:
| I love what Foam is/was doing. Unfortunately the project looks
| dead..
| ortusdux wrote:
| 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.
| IgorPartola wrote:
| 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.
| NoMoreNicksLeft wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-14 23:00 UTC)