Feels a bit overconfident - it was much better than the previous approach, and it got better over the iterations, getting very close - but however, 100% of the time my actual location was outside the circle.
I.e., the center points seem reasonable, but the size of circle is unreasonably small because it's obviously smaller than your actual precision.
I wonder if it connected to various servers using websockets and did some in/out message timing.
I think it needs to have some knowledge of backbones or something like.
Wonder if you had a bunch of signals, like telco, and timing informations, you could throw it into an ML tool and it could learn the backbone topology implicitly....
Will get a heck of a lot easier once the people at FaceBook, Google, Apple, NSA, et all get their way with IPv6.
And please don't try to tell me more about "privacy extensions". When I swim in a see of 4.3 billion address, I'm forced to share, leaving an undeniable possibility that I could be another person. While 3.4×10^38 identifiers could be so huge I never have the same address twice, the implementation does not guarantee that. Welcome to simplified tracking of users, advocated by the people that make money on tracking you.
it's far easier and more accurate to track someone based on browser fingerprinting and a few other features than any IP address -- period. IPv6 in no way makes this worse or better than IPv4.
The other website posted on HN yesterday was much more accurate in that it had very large error circle and I was within the circle. This one tries to be way to specific which you simply can't do with this technique.
It could be "Improved Improved" if they had a central server constantly polling the nodes in exactly the same fashion as this script does. If you know the distance from your central server to the nodes, you can use the rolling response times you're polling for to establish a baseline for the client to help factor out server load.
Tried 10 times from Victoria (State) Australia and it once got the continent correct but that was around 2000Km west of my location. The other times were way wide.
Latency is not an indicator for geographic anything. If this is just a fun hobby project, by all means go for it but don't expect it to be very truthful ever.
I like your idea, especially the number of servers you used. I'm only concerned that using a full HTTP GET to measure the latency (function request_image() in src/ping.js) makes the results possibly way more random than measuring the TCP/IP RTT server-side. That is, your method seems to measure the latency in higher net layer than TCP. Anyway, nice idea :)
For me it often comes close, but seems to be unable to converge on my actual location.
It always ends up stuck south east of it. I am in San Francisco.
The other passive geo system put a larger circle right around SF when I tried it.
My guess is that none of the hosts it pings are to the north or west of me, or that they stick the hosts on a grid that doesn't wrap around to the nearest location, so it is biased towards the east/south.
I can say for sure I am not in Chicago. But at least it got the right country. Incidentally at one point it circled almost my exactly location and then proceeded to walk elsewhere.
Update: I tried a second time. The second time it actually nailed my location pretty closely. The circle actually enclosed the state I'm actually in. The third time it was off again but at least close than the first.
The creator of the NLNOG RING did a very good job of this using all ~400 servers around the world, as an experiment. Was pretty accurate.
http://map.ring.nlnog.net/ (That triangulation service is now gone, I think)
I.e., the center points seem reasonable, but the size of circle is unreasonably small because it's obviously smaller than your actual precision.