
Passive TCP/IP Geo-Location - blaskov
http://geoloc.foremski.pl/
======
phire
I see the bug. If the ping times are high enough (~250ms) it will happily
create circles which exceed the area of earth, and the google maps API will
happily draw negative circles which exclude the user's likely location.

Really there should be a max function that shades the entire earth (or ignores
it since that result really can't tell you anything).

~~~
contingencies
If ping times are over 250ms the user's likely location is China (but could
also be online via satellite, or in space). Of course, if the user is in
China, Google Maps won't display.

~~~
maz-
Eh? RTT between London and Sydney for example is around 300ms and testing that
page, I see a 316ms RTT from Singapore (in London).

Theoretical minimum RTT's based on the speed of light for systems on the
opposite side of the world is nice and all but doesn't take into account the
realities of packet processing on the internet.

~~~
contingencies
Yes but speaking statistically, since virtually nobody lives in Australia or
London versus China, the user's likely location is China.

------
lucb1e
I did this a few years ago, a simple tool that pinged places all over the
world and calculated where you should be.

This only ever gets as close as your ISP, or perhaps a local routing center if
your ISP has multiple (mine has only one in Amsterdam, I live on the other
side of the country). This means it's less accurate than your typical GeoIP
database.

Edit: I'm no longer sure this is the same. The title mentions "passive", and
from another comment I understand that the author meant that you can find
someone's location if you are the man in the middle, observing traffic to
various places around the world. This is definitely something I had not
considered yet!

~~~
chias
It isn't passive. See lines 64-73 of the code [1]. This seems very similar to
what you describe, but rather than you pinging a bunch of places around the
world, it has a bunch of places around the world essentially pinging _you_.

If you check the HTML source, it's src'ing scripts from machines around the
world (I assume whatever host is being used, the author has spun up a VPN in
each of their data centers). Here's an example of one [2]. Each of these sends
you a constant value over and over again, and the server side measures the
latency, before finally reporting the average round-trip time to you.

[1]:
[http://geoloc.foremski.pl/tcpinfo.go](http://geoloc.foremski.pl/tcpinfo.go)

[2]:
[http://46.101.226.53/DE_Frankfurt.js](http://46.101.226.53/DE_Frankfurt.js)

------
aw3c2
> This website demonstrates IP address geo-location by passively measuring
> TCP/IP round-trip times of web requests made to a few servers spread around
> the world.

I don't get how that could be called passive. This is making your browser
issue requests or am I missing something?

~~~
HowardStark
I believe the author's point was you could determine the location by
monitoring other applications and their network calls.

That being said, I highly doubt there are many requests being made to
Bangalore, India and this appears to require requests to a wide array of
locations all over the world.

~~~
lucb1e
Aside from the disproportional amount of traffic going to America (I'm from
Europe), there was still a significant portion of traffic that went all over
the world when I last checked for my private traffic.

Additionally I once made a map of destinations from our school's "security
lab" network. This is 30 minutes of traffic:
[https://snag.gy/aJqrg2.jpg](https://snag.gy/aJqrg2.jpg)

The map is a modified version of the one generated by Wireshark (circles are
proportional to the amount of data going from/to that IP address). It seems to
use Maxmind's GeoIP database.

------
IshKebab
The ping times seem sensible, but I can't work out any correlation between
them and the map. Just seems like a random collection of circles...

~~~
whorleater
I assume each circle has a radius proportional to the rtt, thus the area in
which the circles overlap is roughly where you should be. The limited amount
of servers + wide range of rtt gives a massive margin of errors, but this is
probably easily improvable through some extra servers and some kind of knn-ish
analysis.

~~~
planetix
Well in my case somehow javascript places Singapore circles center to middle
of Indian ocean close to Antarctica. San Francisco and Bangalore are in South
America.

~~~
chinathrow
That's not an inclusive circle, it means anything within the circle is _not_
reachable within the RTT reach of ie. Bangalore or Singapore.

------
abpavel
Delay component of the round trip time contains sum of: 1\. delays in buffer
queue 2\. serialization delays 3\. processing delays 4\. propagation delays
While propagation delay usually makes up the largest portion, it is not always
the case. Furthermore, the routing efficiency varies widely, depending on IX
peering and INET upstream arrangements of your ISP. It also helps to know the
topology of the underlying physical networks, or at least major POPs.

This is like measuring intensity of the Sun with the naked eye.

------
nebulous1
I think there's a bug in the circle placement. They don't appear to be correct
for me. I'm assuming they're supposed to be centred on the locations listed.

~~~
chronial
I though that too at first, but they are correct. It looks like this because
these are circles on a globe. The outline of a very big circle around a
location is the same as the outline of a small circle around the point on the
opposite side of the globe.

Look at the color-tint to find out what is inside and what is outside a
circle.

~~~
nebulous1
Ah yes, I see. My ping times to Singapore are so bad that it looks like a
circle over Columbia/Ecuador, ie the other side of the globe, but what looks
like a circle is actually what's outside the circle.

------
cyphunk
While GeoIP databases might be more accurate this method _may_ in some
situations provide location information of users behind proxies. lame self-
reference, discussion on the topic:
[https://deadhacker.com/2011/03/13/predicting-location-of-
one...](https://deadhacker.com/2011/03/13/predicting-location-of-one-hop-
proxy-users/)

~~~
zrm
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.

~~~
Tinyyy
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.

~~~
zrm
> 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.

------
weberc2
This is wildly inaccurate. I'm in the U.S. (not even a southern state) and it
thinks I'm somewhere well off the coast of Peru. Perhaps my results are
atypical, or there's a rendering problem? Perhaps this could be improved with
more servers and a better algorithm for resolving the times?

~~~
nickodell
Actually, what it's trying to tell you is that you're _not_ in Peru. If you're
220 ms away from Singapore, you must not be in Columbia, since a speed-of-
light transmission would take longer than that to make a round trip.

For me, the most specific fix is provided by New York and San Francisco.
Together, they can tell that I'm somewhere in the US, Canada, or Mexico. (But,
of course, you could have figured that out from GeoIP.)

~~~
weberc2
Ah yes, that makes more sense. Thanks for the help. :)

------
Svenskunganka
Don't forget that this is a proof-of-concept and is not meant to be an
reliable solution for you to replace GeoIP with, but rather a concept to play
with thoughts.

The first thing that comes to mind would be combining this with peer-to-peer
pinging - which if the swarm is big enough could potentially provide a fairly
decent geolocation mechanism.

------
rmdoss
Really cool tool.

If he added a few more servers and set a max ping rt it would become a lot
more accurate.

And it doesn't really replace geoip, but implemented correctly can be used
very affectively for latency based routing (similar to what AWS has).

------
alpb
Honestly this does not seem to be a very smart thing to do at all. Your ping
times is probably just going to reveal on which coast of US you are on (unless
you're speedtest.com or something like that).

If you want city-level accuracy, at least in US, just use geo IP lookup:
[https://geoiptool.com/](https://geoiptool.com/) This finds my city perfectly,
unlike the link above (which says I'm somewhere on US West coast).

~~~
tedmiston
How does Geo IP Tool make these predictions? Like, where is the data it's
associating my IP with coming from or how are they obtaining it?

~~~
pyvpx
they start with WHOIS data and add what they can from there to improve
accuracy. Quite a few residential ISPs register blocks of IP addresses
(subnets) to a city, town, neighborhood, etc.

------
kerkeslager
Little Snitch[1] does a very good job of preventing this sort of attack. Even
if they give names to the servers that make me think they're something I want
to allow, the time I spend clicking the "Allow" button is well outside the
margin of error of the latency measurements. I'm in NYC and the tool places me
in Frankfort, Germany.

+1 for Little Snitch.

[1]
[https://www.obdev.at/products/littlesnitch/index.html](https://www.obdev.at/products/littlesnitch/index.html)

~~~
nathancahill
Yes, I use and love Little Snitch too, but don't you have a rule that says
Browser = Allow all?

~~~
kerkeslager
Nope.

It only took me a few days to work out whitelists/blacklists for the sites I
use often, i.e. most citicards.com subdomains get an "allow" but
cardoffer.citicards.com gets a "deny". On other sites I come across it's
usually trivial to whitelist the domains that provide their functionality, and
most adservers and tracking servers I've already blocked.

Given browsers are the main place I get tracked, putting an allow all for my
browser seems to defeat the purpose.

That said, it was pretty annoying the first few days.

~~~
nathancahill
I see. I use uBlock Origin for the browser, and Little Snitch for application
level connections. Similar strategy though, starting with deny all, and
gradually building a whitelist to get sites functional.

------
dzhiurgis
I have a question about geolocation when using Google Compute. All of the
geolocation services identify my server as US based, when in fact it is
located in asia (ping and traceroute reveals).

Was wondering perhaps HN big heads can explain it to me:) I suspect it is
somehow related to how Google operates its SDN and that IP is assigned to
massive AS block.

Nevertheless, I think there is a decent performance risk when CDNs serve from
US based cache rather than local.

~~~
jimktrains2
GeoIP databases work based on the _owner_ of the IP address. The owner can
cooperate with a geoip database and provide more granular locations for the
blocks they use. Others, like Google apparently, don't and as such, you'll
show up as the registered address for the allocated block.

------
mkj
Nice idea. Digitalocean's Singapore routing seems a bit terrible. From Perth I
get 50ms to a hop in Singapore (aarnet), but the endpoint is >100ms!

------
dewyatt
Seems a bit off for me in Virginia, USA.

[http://imgur.com/TblQSSu](http://imgur.com/TblQSSu)

~~~
gkfasdfasdf
Looks about right, the circle around Columbia is not shaded inside - that is,
the center of the circle is on the other side of globe. So Virginia lies in
the most heavily shaded region.

------
xfour
Smart, but I don't know how granular you could get unless you had known
servers at every possible datacenter.

~~~
chinathrow
Just use a CDN with decent edge coverage. I'm sure those results can be
improved drastically.

~~~
planetix
You did notice that the backend code is Go code snippet that needs to run at
the end points?

~~~
chinathrow
So? I'm sure some CDN out there allow you to run your own code, hence it could
be more granular (as OP was interested in).

------
sheerun
I've created slightly improved version here:
[https://news.ycombinator.com/item?id=11993451](https://news.ycombinator.com/item?id=11993451)

------
xg15
I'm not impressed so far. The demonstrator on the linked page found out that I
live... somewhere in Europe.

You could get a more precise location by simply reverse-DNSsing my IP address.

------
SimonSelg
Works for me! Correctly identified my location as Germany.

------
avodonosov
my result: [https://snag.gy/4X5ZyN.jpg](https://snag.gy/4X5ZyN.jpg)

~~~
SomewhatLikely
I think that means you're in Europe.

~~~
avodonosov
I am. How do you see this?

~~~
jimktrains2
The circle around the Indian Ocean, and the 2 near/over South America are
inverted. _Inside_ the circle is where you aren't. As such Europe is the place
where all circles overlap.

------
Canada
Tried with Tor. Not even close.

------
rocky1138
Am I looking at the area in which the majority of circles intersect, a la
Venn?

~~~
planetix
Intersect? In my case they intersect in a weird way:
[http://i.imgur.com/eFqyCEq.png](http://i.imgur.com/eFqyCEq.png) Those circle
centres don't even look right.

~~~
andyfleming
It's obvious. You are either in the Pacific Ocean or the Atlantic Ocean!

------
rad_gruchalski
So it approximated me being in Frankfurt. Not bad, just about 100 miles away.

------
sgt
Not very accurate - got my location incorrect by over 10000 km.

------
VoidWhisperer
I apparently live in the middle of the Caribbean. Ha. I wish.

------
sergers
earlier it had me in California/Oregon.

now it shows me in Ecuador?

i am actually on west coast canada

------
formula_ninguna
it even doesn't show a continent properly where I am .

------
necessity
Only works if JavaScript is allowed by default.

~~~
kpcyrd
The demo, yes. The attack, no.

------
mSparks
this puts me in one of about 6 locations in the world each with an accuracy of
several thousand kilometers. probably because i suffer from quite unpleasant
packet loss. but not convinced it works.

~~~
milcron
Some of the circles are inverse circles. I thought it was inaccurate at first
too, until I realized the India result was telling me "you're NOT in Peru".

~~~
mSparks
Just done it from the office. I'm definitely "not" in the ocean.
[http://i64.tinypic.com/28ujms7.png](http://i64.tinypic.com/28ujms7.png)

~~~
milcron
Lol! Looks like this is saying:

Green: Not in the Indian Ocean.

Blue: Not in the Pacific near Ecuador.

Yellow: Not in the Southern hemisphere.

Red: Somewhere in Europe, Greenland, North Africa, or Svalbard.

In your case, the red circle is the only one that really matters. Yellow took
a tiny slice out of it near Iraq.

