Sort of. You measure the latency from the user to the proxy + the proxy to the site, so what you end up with is the approximate location of the proxy and a radius around it where the user could be. But the radius is liable to be 3000 miles, and you can't even assume the user isn't really closer to the proxy than that because the user could be using more than one proxy or anything else that adds fixed network latency (including on purpose to prevent this).
Which is the same problem with using it to determine if the user is "too far" from the server. You can get extra latency (and thus false positives) whenever there is bufferbloat or a lame corporate network that routes traffic from New York to New York via a network appliance in California or similar.
3000 miles is still a relevant clue if the target users continental location isn't already known. Additionally even in this very weak form it provides useful data for anti-fraud metrics. For example by payment processors like Paypal that may use [total latency minus ping latency] to feed a metric indicating possible proxy use.
But I also assumed an investigative organization that took the idea further would use the latency information with a map of latencies between major internet exchanges. This would increase accuracy and usefulness, though still the entire idea only works to provide indefinite clues
Assuming that the user only uses one proxy, you can use GeoIP to get his proxy location, and then if you account for the proxy-webserver distance, you can get a pretty accurate geolocation.
> Assuming that the user only uses one proxy, you can use GeoIP to get his proxy location, and then if you account for the proxy-webserver distance, you can get a pretty accurate geolocation.
A congested network link can easily add more than 100ms of latency due to buffering. At the speed of light that's thousands of miles.
You can't even say that if the latency between the proxy and the browser is only 10ms then the user is physically close to the proxy, because you don't know if the user is running the browser on a VPS with something like X forwarding.
Which is the same problem with using it to determine if the user is "too far" from the server. You can get extra latency (and thus false positives) whenever there is bufferbloat or a lame corporate network that routes traffic from New York to New York via a network appliance in California or similar.