W3C home > Mailing lists > Public > www-international@w3.org > October to December 2001

RE: Localized Web Advertising & IP tracking (was Re: bilingual websites)

From: Lenny Turetsky <LTuretsky@salesforce.com>
Date: Tue, 30 Oct 2001 16:52:52 -0800
Message-ID: <13A191251979D411A44000D0B76FDEE20405781F@samoa.internal.salesforce.com>
To: "'Barry Caplan'" <bcaplan@i18n.com>
Cc: "'www-international@w3.org'" <www-international@w3.org>
Barry,

I can't speak for mobile phone technology, as I know very little about it.
But I'm pretty sure that the situation is VERY different from IP and
associated protocols.

In the case that no VPN/dialup/etc. is used, the technique you described
might be useful.
But in the firewalled case -- the only one I was addressing in my post -- it
may yield misleading results.
And the problem is that it's virtually impossible to know whether a server
is accessed from behind a firewall. That's part of why firewalls work.

Let's imagine a multi-national corporation X, with three users. User1 is in
X's corporate office in San Francisco, CA, US. User2 accesses X's corporate
network via VPN from Tokyo and surfs our website through that VPN
connection. User3 accesses X's corporate network via local dialup in San
Francisco.

All three of those users will send their traffic through X's corporate
firewall, which is also in San Francisco.
Odds are that the firewall's IP address is the only one our server will see
for all three users, and when our server tries to ping/traceroute/whatever
back to that IP address, it will see a router in San Francisco.

So our server will believe that all three users are in San Francisco. But
User2 is actually in Tokyo.

Our server was correct about two of those users. But we have no way of
knowing *which* two users were the correctly located ones, which makes the
correct answers even less useful.

Sincerely,
Lenny Turetsky

-----Original Message-----
From: Barry Caplan [mailto:bcaplan@i18n.com]
Sent: Tuesday, October 30, 2001 11:35 AM
To: www-international@w3.org
Subject: RE: Localized Web Advertising & IP tracking (was Re: bilingual
websites)


Lenny,

The point is that the last available router is a strong indicator of 
location. We are not talking about pinpointing the office cube you are in 
here :)

Not only that, but if I ping a reachable ip address from a number of 
locations, I should be able to derive some location info from the 
traceroutes available as they pass though known routers in known locations, 
and gather some more info.

E.g, I might find out ping A from A1 and A2 . A1 passes through B 5 hops 
before A, A2 passes though C 1 hop before. That gives me a clue (and more 
detailed info is available in routing tables) that A is somehow closer to 
A2 than A1. Since the physical locations of A1 and A2 are known, then we 
are starting to hone in on something.

This is based on the principle that packet routes may travel all over the 
place, but routes from many distant points will eventually converge on the 
target, probably pretty rapidly. Studying these convergence patterns to an 
unknown point from and though known points should be able to tell you a lot 
about the location of the unknown point by turning up know points somewhere 
in the traceroutes.

BTW, I think land phones work analogously during the call set up phase. 
There is a real time route set up between he caller and callee, passing 
through the callee's local Central Office Switch as a last hop. Everything 
else before that is variable. If all I had was the routing information, I 
could pin your location to the area serviced by the CO, which is relatively 
small, on the order of a neighborhood. This is why directories of phone 
exchanges and their locations are useful in finding people by their phone 
numbers - each exchange is only served by one co (although a single co can 
serve many exchanges).

Another example: I participated in a search for a missing couple a few 
weeks ago. A single cell phone call had been made that we were told was 
relayed (last, well - only, hop) by a cell tower in Mountain View. That 
limited the search to the area served by that tower. So you can see that a 
lot of useful info can come from the location of the last hop, even if the 
ultimate destination is unknown.

Barry

At 12:04 PM 10/30/2001 -0800, you wrote:
>All of this is well-and-good. But only if the firewall between your website
>and the user's dialup connection allows things like traceroute, ping and
>other ICMP traffic.
>And, frankly, any firewall that allows such traffic isn't worth having.
>
>So, while this suggestion is great in principle, I don't think it would
work
>in practice because of the realities of modern firewalls.
>
>All you'll get is the traceroute back to that firewall or, more likely, to
>the last router in front of that firewall. Which leaves us right where we
>started. No?
>
>:(
>
>Lenny Turetsky
>Senior Member, Technical Staff
>i18n Man of Mystery
>salesforce.com
>The Landmark @ One Market
>Suite 300
>San Francisco, CA 94105 USA
>+1.415.901.5078
>lturetsky@salesforce.com
>
>
>-----Original Message-----
>From: Barry Caplan [mailto:bcaplan@i18n.com]
>Sent: Tuesday, October 30, 2001 10:57 AM
>To: Tex Texin; david@gallardo.org
>Cc: Thierry Sourbier; www-international@w3.org
>Subject: Re: Localized Web Advertising & IP tracking (was Re: bilingual
>websites)
>
>
>Tex,
>
>You put your finger right on the problem. But there is more data lurking in
>various routing protocols that I think can be used to ping your location
>even if you dial in while on another continent.
>
>Yes, you will have the same address. But a traceroute from a known location
>to your dial up (or vice versa) will be very different. for instance, the
>last hop would reflect the location of your dial up connection itself, not
>the location of Progress's IP addresses. If there were a table that had
>that device listed, and it's geo location, it would be a strong indicator
>that you are in the same location, or at least within the most reasonable
>phone rate selection.
>
>OTOH, if you dialed directly to the US instead of locally, this might not
>work. But I suspect the vast vast majority of folks are connected at any
>time are connected through a known, or knowable, machine somewhere nearby
>(in the routing table sense).
>
>The key is that it is not really the location of the owner of the ip
>address that matters (anyone can lie to the registry about that), but the
>location of the first or second hop that your packets travel to from your
>pc (or outside your lan) that matter in identifying your location.
>
>For instance, a couple of weeks ago there was a routing problem at my isp,
>isolated to my local pop dialup point. I sent the traceroute to the
>engineers and (long crappy service story omitted here) the engineers were
>able to say "you are in Palo Alto?" based only on that. Of course, I am in
>Mountain View, but that is a darn site closer (next town over) than
>networldmap, which suggested Redding CA for me.
>
>Best,
>
>Barry
>
>At 02:42 PM 10/30/2001 -0500, Tex Texin wrote:
> >I dial into my company network from all over the world. No matter which
> >contintent I am on, my IP address will look to have the same location.
> >Interestingly, we are headquartered in Bedford, MA and networldmap
> >thinks we are in Nashua NH.
> >My guess is one of our Nashua employees added the info to networld map,
> >either first or most recently, hence the determination that, that is
> >where I am from.
> >
> >Also, I think to the outside world all of our employees seem to have the
> >same IP address.
> >tex
> >
> >David Gallardo wrote:
> > >
> > > IP addresses are assigned in a pretty consistent
> > > manner with respect to geography. See:
> > > http://www.networldmap.com
> > >
> > > @D
> >
> >--
> >-------------------------------------------------------------
> >Tex Texin                    Director, International Business
> >mailto:Texin@Progress.com    Tel: +1-781-280-4271
> >the Progress Company         Fax: +1-781-280-4655
> >-------------------------------------------------------------
Received on Tuesday, 30 October 2001 19:53:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:58 GMT