I think the key thing to keep in mind with this approach is that physical distance and network distance are only loosely related.
You can easily be next door to someone, and your packets go all the way across the country to get there.
I've definitely seen cases where my latency to two servers in the same building were wildly different, depending on the paths my ISP and their ISP(s) routed the traffic.
I'm about 22 ms roundtrip away from ISPs facility at the local internet exchange in Seattle. If a server is connected to that exchange, and traffic flows through the exchange both ways, I see ping times of about 22 ms. Sometimes, my ISP will send traffic through San Jose instead, but the server returns the traffic in Seattle, and that adds about 26ms, so I get a 48 ms ping. If both sides route through San Jose for whatever reason, I'll get 74 ms, which is close to what I'd get if the routing was sensible and the server was in the Washington, DC area. (You normally can't see the routing back from the server, but sometimes you control the server, too).
If I were building something like this, I'd want to try to determine how much of the latency was the user getting to where their ISP interconnects with other networks (or with multiple routes within their own network), and then where that interconnection location is. I'd guess you can get a pretty good idea of the interconnection location, based on reasonable network paths from there, but distance from the interconnection point is going to be tricky, most residential networking technologies add much more latency than the speed of light, so your upper bound of distance is going to be pretty far off. Of the roughly 22 ms I see to Seattle, about 20 ms is just coming from the DSL termination; when I had AT&T GPON, it added about 4 ms to my pings; that's a lot of distance.
You can easily be next door to someone, and your packets go all the way across the country to get there.
I've definitely seen cases where my latency to two servers in the same building were wildly different, depending on the paths my ISP and their ISP(s) routed the traffic.
I'm about 22 ms roundtrip away from ISPs facility at the local internet exchange in Seattle. If a server is connected to that exchange, and traffic flows through the exchange both ways, I see ping times of about 22 ms. Sometimes, my ISP will send traffic through San Jose instead, but the server returns the traffic in Seattle, and that adds about 26ms, so I get a 48 ms ping. If both sides route through San Jose for whatever reason, I'll get 74 ms, which is close to what I'd get if the routing was sensible and the server was in the Washington, DC area. (You normally can't see the routing back from the server, but sometimes you control the server, too).
If I were building something like this, I'd want to try to determine how much of the latency was the user getting to where their ISP interconnects with other networks (or with multiple routes within their own network), and then where that interconnection location is. I'd guess you can get a pretty good idea of the interconnection location, based on reasonable network paths from there, but distance from the interconnection point is going to be tricky, most residential networking technologies add much more latency than the speed of light, so your upper bound of distance is going to be pretty far off. Of the roughly 22 ms I see to Seattle, about 20 ms is just coming from the DSL termination; when I had AT&T GPON, it added about 4 ms to my pings; that's a lot of distance.