> 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.
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.
> 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.
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.
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.
This is similar to the argument the failed experiment 4Chan showed the internet. Being fully anonymous, the best arguments don't rise to the top, bad actors lie and lie and when confronted with their lies, they just pretend to be someone else and lie some more. All completely anonymous online polls are effectively useless. It's nice to have some research in helping them be a little less useless.
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.
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.
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.
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.
It's really not. The microwave links got decommissioned everywhere because nobody NEEDS that higher fraction of lightspeed. High speed trading is the only field where saving a singular millisecond is economically rewarded. The links used by high speed trading are the only ones left.
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.
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?
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:
> 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.
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.
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.
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?
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.
We (IPinfo) run active measurements through our 900 servers and produce a standard IP geolocation data product. However, to my knowledge, we haven’t partnered with any organizations or institutes to support a project like this, although we certainly have the potential capacity to do so.
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.
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.
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.
The idea is to make things like petitions or demonstrations easier on a global scale and to also make voting data accessible for independent analysis, where further manipulation attempts can be identified and excluded.
My guess is that it's much cheaper to create 10000 fake accounts on facebook etc than to send 10000 requests from unique residential IPv4 addresses in a target country, which are also evenly distributed across Internet Service Providers and IP blocks to evade detection.
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.)
> Is it possible to ensure that the data is not manipulated?
I don't think one can place much trust in phones not being tampered with as they are frequently jailbroken. So you could supply fake GPS antenna data to the software or I believe you could in principle also put your phone in a metal box and spoof actual GPS signals into the box. Civilian GPS signals aren't encrypted, I think..
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
To get a hard to manipulate, representative sample of popular opinion it's not necessary to include everyone in the results.
Only if the sub-population sharing IP's is large enough and has systematically different opinions than the people who don't share an IP, then this method would skew the results in a certain direction and may not be useful for certain polls in those regions. But it may also be possible to adjust the results, if it is known which IP's are shared and which are not.
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.
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.
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.
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.
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.
> 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)
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.
1 reply →
> 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.
1 reply →
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.
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.
This is similar to the argument the failed experiment 4Chan showed the internet. Being fully anonymous, the best arguments don't rise to the top, bad actors lie and lie and when confronted with their lies, they just pretend to be someone else and lie some more. All completely anonymous online polls are effectively useless. It's nice to have some research in helping them be a little less useless.
3 replies →
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.
well yeah, that's against the point of "anonymity" ... you are feeding the app all the data it needs to fence you in.
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.
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.
You are describing an ideal use case for a botnet of compromised home computers. Should command a much higher premium than sending spam.
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.
2 replies →
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.
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.
It's really not. The microwave links got decommissioned everywhere because nobody NEEDS that higher fraction of lightspeed. High speed trading is the only field where saving a singular millisecond is economically rewarded. The links used by high speed trading are the only ones left.
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.
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
I don't think microwave is "closer to the speed of light" than.. light.
Electromagnetic radiation is about 1.5 times faster in air than in glass (depending on wavelength a bit).
1 reply →
> 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?
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'
> 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.
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.
1 reply →
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.
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.
> 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.
If only people with fast internet can vote, this is becomes a curious tool for voter suppression.
For example very slow ADSL connections or somewhere with poor phone reception.
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?
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.
> 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.
1 reply →
We (IPinfo) run active measurements through our 900 servers and produce a standard IP geolocation data product. However, to my knowledge, we haven’t partnered with any organizations or institutes to support a project like this, although we certainly have the potential capacity to do so.
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.
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.
Reminds me of the case of the 500-mile email:
https://www.ibiblio.org/harris/500milemail.html
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.
The idea is to make things like petitions or demonstrations easier on a global scale and to also make voting data accessible for independent analysis, where further manipulation attempts can be identified and excluded. My guess is that it's much cheaper to create 10000 fake accounts on facebook etc than to send 10000 requests from unique residential IPv4 addresses in a target country, which are also evenly distributed across Internet Service Providers and IP blocks to evade detection.
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.)
> Is it possible to ensure that the data is not manipulated? I don't think one can place much trust in phones not being tampered with as they are frequently jailbroken. So you could supply fake GPS antenna data to the software or I believe you could in principle also put your phone in a metal box and spoof actual GPS signals into the box. Civilian GPS signals aren't encrypted, I think..
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
To get a hard to manipulate, representative sample of popular opinion it's not necessary to include everyone in the results. Only if the sub-population sharing IP's is large enough and has systematically different opinions than the people who don't share an IP, then this method would skew the results in a certain direction and may not be useful for certain polls in those regions. But it may also be possible to adjust the results, if it is known which IP's are shared and which are not.
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.
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.
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
I love what Foam is/was doing. Unfortunately the project looks dead..
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).
I just released a demo here https://ip-vote.com/ui/geolocation
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.
Fortunately it is not. https://prepaid-data-sim-card.fandom.com/wiki/Registration_P...
With eSIMs, I think all you need nowadays is a credit card + billing address.
There are vendors that accept crypto as well, so not even billing information is needed.
I think you can still buy prepaid SIMs in the US without ID.
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.
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.
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.
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.
Did you read the article? It's not about using IP addresses...
1 reply →
IPs can easily be spoofed. Until someone hashes all IPs with physical GPS coordinates, this is simply not a proof.