Show HN: Improved passive TCP/IP geolocation(sheerun.gitlab.io)
sheerun.gitlab.io
Show HN: Improved passive TCP/IP geolocation
http://sheerun.gitlab.io/ping/
22 comments
Ran this about 10 times, it never once entered the correct hemisphere.
Hint: I don't live in the northern one.
Hint: I don't live in the northern one.
Keeps putting me in the middle of the indian ocean with high confidence. I'm in eastern Australia.
After jumping between Eastern US, Greenland and Finland, it's finally settled on Nigeria.
I'm in Sydney, Australia.
I'm in Sydney, Australia.
Sydney, same result here
(has HN ever had a Sydney meetup?)
(has HN ever had a Sydney meetup?)
Same, it put me in California, but I'm in ...Australia
I live in New Zealand and this thing thinks I'm somewhere in Western USA.
Same here, keeps thinking I'm in the Eastern USA though.
Throw more ping servers in Australia and it'll work :)
I'm in San Francisco. It failed to work that out but it at least figuring I was probably in CA.
Southern CA, for the most part (or at best the central valley).
That's underwhelming and I wouldn't call it "improved" in the slightest.
edit: on refresh it thinks I'm around the Azores or maybe the south coast of Greenland. Not impressed.
Southern CA, for the most part (or at best the central valley).
That's underwhelming and I wouldn't call it "improved" in the slightest.
edit: on refresh it thinks I'm around the Azores or maybe the south coast of Greenland. Not impressed.
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....
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....
No fancy timing. Just 404 requests on on random 3rd party proxy servers. You might fork and improve it :)
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.
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.
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.
Very interesting project though!
Very interesting project though!
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.
Hi, the author of original submission here.
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 :)
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.
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.
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.
Why not also include TTL field from IP header.
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)
It is close. Really nice effect and visual feedback while it is hitting each location.
This has apparently actually identified my antipode.
I also feel like circling entire continents doesn't count...
Not even the right continent for me.
It worked pretty well for me. The center of the circle was about a 45 minute drive to NYC.
Apparently Japan is smack in the middle of the Atlantic. Who knew?
A couple million people between me and the geolocation guess.
Can I assume this was meant to show my own location?
If so, I can assure you I'm not in India, Pakistan or Oman (or the middle of the Indian Ocean) as it suggested.
If so, I can assure you I'm not in India, Pakistan or Oman (or the middle of the Indian Ocean) as it suggested.
So far it's given me middle of the Indian ocean and north-west Africa. I'm in Australia.
EDIT: Now it's saying somewhere in North America
EDIT: Now it's saying somewhere in North America
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.e., the center points seem reasonable, but the size of circle is unreasonably small because it's obviously smaller than your actual precision.
Same here, I ended up ~2000kms away (at best) from the circle (from Bangkok)
The circle isn't confidency indicator but merely a visualization of latency to the closest server
The ping class likely needs to be scrapped to make this any sort of reliable.
Making a fake image request to these servers introduces a lot of very random sources of latency over what a typical ping would involve.
Making a fake image request to these servers introduces a lot of very random sources of latency over what a typical ping would involve.
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.
Circles don't represent accuracy, just the smallest latency
The VPN tests did have lower confidence, IE larger zones, but my end point was indeed in the circle. Pretty neat.