RE: Determining Locale in a Browser for Web 2.0 Applications

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Apr 18 2009 - 09:40:06 CDT

  • Next message: Doug Ewell: "Re: Determining Locale in a Browser for Web 2.0 Applications"

    Christopher Fynn wrote:
    > Even though I have always had the preferred language in my
    > browser set to en-gb, for a long time Google thought I was in
    > Hong Kong and defaulted to a zh-HK search page. My guess this
    > was because my ISP was using a satellite that down-linked to HK.

    Given the information that Google's member gave here, the fact that it has
    constnatly ignored the HTTP headers means that Google has most probably used
    instead a for of IP-Geolocalization. The source of information is then the
    IP that your ISP provided you, that was taken from a block assigned to an
    ISP whose contact address was in Hong Kong, within the RIR's databases.

    If this hasd stopped now, may be this is because your ISP has changed its IP
    allocation policy, by allocating new blocks for your country instead of Hong
    Kong, even if the ISP still has offices in Hong Kong.

    Let's look at your IP, from which tyou are sending your message:
    202.89.26.71
    A reverse IP lookup, using DNS gives this name: cust71.fastlink.bt
    However the name is not very conclusive about the country. You need to find
    the actual country of the registrant for the domain. This info is not always
    provided (maintained secret by the registry). When ths happens you have to
    look for that information in the RIRs databases.

    From APNIC:

    inetnum: 202.0.0.0 - 203.255.255.255
    netname: APNIC-AP
    descr: Asia Pacific Network Information Center, Pty. Ltd.
    (...)
    descr: Australia
    country: AU
    admin-c: HM20-AP
    tech-c: NO4-AP
    (...)
    remarks: 202.123.0.0/19 transferred to AfriNIC
    (...)
    mnt-by: APNIC-HM
    mnt-lower: APNIC-HM
    changed: dbmon@apnic.net 20000725
    changed: hm-changed@apnic.net 20021001
    status: ALLOCATED PORTABLE
    changed: hm-changed@apnic.net 20050308
    changed: hm-changed@apnic.net 20060124
    source: APNIC

    inetnum: 202.89.24.0 - 202.89.31.255
    netname: FASTLINK
    descr: DrukCom Pvt. Enterprise,
    descr: 1 Norzin Lam, PO Box 810, Thimphu,
    descr: Bhutan, Internet
    country: BT
    admin-c: RD175-AP
    tech-c: RD175-AP
    status: ALLOCATED PORTABLE
    mnt-by: APNIC-HM
    mnt-lower: MAINT-BT-FASTLINK
    mnt-routes: MAINT-BT-FASTLINK
    (...)
    changed: hm-changed@apnic.net 20060224
    source: APNIC

    inetnum: 202.89.26.0 - 202.89.26.255
    netname: CUSTOMER-FASTLINK
    descr: FASTLINK-CUSTOMER
    country: BT
    admin-c: RD175-AP
    tech-c: RD175-AP
    status: ASSIGNED NON-PORTABLE
    mnt-by: MAINT-BT-FASTLINK
    changed: rinzy@druknet.bt 20061010
    source: APNIC
    route: 202.89.24.0/21
    descr: Route Object of DrukCom Pvt. Enterprise
    origin: AS38004
    mnt-by: MAINT-BT-FASTLINK
    changed: rinzy@druknet.bt 20060607
    source: APNIC

    route: 202.89.26.0/24
    descr: Route Object of DrukCom Pvt. Enterprise
    origin: AS38004
    mnt-by: MAINT-BT-FASTLINK
    changed: rinzy@druknet.bt 20061129
    source: APNIC

    Now with this info you know for sure who "owns" the IP, and for which
    country it was allocated (see "Country: BT" above, in the last "inetnum:"
    object that contains the "route:" field which indicates the main routing
    object through which your traffic can be interchanged with all operators,
    even if they don't have more direct private peerings with your ISP). The
    indication given also indicates that your IP is not portable (meaning that
    you are not the direct "assignee" of the IP and that is still remains within
    the realm of your ISP that assigns it to you according to its own policy, so
    you cannot keep that IP address if you change to another ISP).

    So Google can know that you currently live in Bhutan (and not in Hong Kong),
    only because this is what your provider, FastLink, has declared (and
    maintained accordingly in the IP routing tables for its routing AS). What
    has most probably happened is that FastLink has stopped assigning you an IP
    within a block declared for use and routing in Hong Kong, or it has modified
    its declared routing object with more precise info in order to optimize its
    cost on its own internal network, by allowing other ISPs to find any other
    convenient routes that can reach your ISP at the POP that is the nearest
    from you and costs the least to deliver finally to you by your ISP.

    In fact this is not a full proof: all that it indicates is that FastLink
    indicates that it can provide an economical interchange access point in
    Bhutan that does not require other ISPs to use inappropriate links to other
    points of presence. FastLink may still internally route your IP through some
    other countries where it also operates its network (but it will support
    itself the associated cost on its own network or with its own peerings).

    Well, such analysis has been true for quite long, until the ISPs realized
    that they needed to conform to national laws, and provide legal information
    about the location of their customers, so that content providers can manage
    the delivery of contents with restrictions of diffusion (for which they have
    to pay licences or rights, notably for TV and radio broadcasting, or VOD).
    If an ISP cannot provide such info reliably, the content providers would
    simply refiuse to deliver the content to that ISP.

    Given the importance, today, of the management of digital rights, as well as
    the importance, for legislators, in the tracking of criminals and thieves
    operating on Internet, it is critical to be able now to locate customers
    with a fast contact for this ISP in the same country as its customers,
    without adding more legal difficulties.

    IP-based geolocalisation is not very precise (it can still produce false
    guesses, and often it cannot even locate areas below the country level), but
    at least, from the RIR database, it should provide correct indication of the
    country, or at least the legislation applicable to the customer.

    In EU, there are many IP blocks that are not identified by a single country,
    but only to "EU" for ISPs that can operate in the single market of the
    European Union; the address of the ISP may be anywhere within the EU, not
    necessarily in the same country has their customer). In that case, the RIR
    database information is not enough, and Google certainly has to trust the
    reverse DNS resolution to find which country is applicable to you, if its
    succeeds (it should now in mst countries that have enforced some legislation
    against network abuses).

    This may not always work immediately (notably when ISPs are restructured
    across country borders, with affiliates being sold to a competitor still
    maintaing commercial activities in the same country: some IP blocks may be
    given in the transaction, but not reflected immediately in the RIR and DNS
    databases, but there are teams from both ISPs involved to ease the transfers
    of domains and customers, so this is not really a problem from a legal
    purpose, notably because the process is more or less warrantied by mutual
    contractual arrangements).

    If all this stil fails, there are other sources of information, and this
    means using the IP routing announcements between AS, because this is what
    really makes an IP routable. Then pinging with "iptrace" option can
    sometimes find another intermediate IP address of a upstream router used to
    reach you, and that has some IP geolocalisation info associated like
    indicated above.

    There still remains some margins of errors, because the net is extremely
    dynamic and must also adapt to accidental situations, where some routes
    become broken due to a link failure or saturation, or due to loss of power
    or failure in a router, or when a local server for an ISP needs maintenance
    and the service is maintained from servers in another area (possibly in
    another close country).

    IP-Geolocalisation however is not a good indicator for the effective
    localization of the contents on your web site.

    Notably, it does not indicate the language or script that is best for you,
    or even for the exact localtionwhere you live (within countries that have
    several official languages). Its best use for now is just for the management
    of digital rights, and for the management of network infrastructures and
    routings between various ISPs, or for the enforcement of applicable national
    legislations (or the specific local legislations within federal countries
    like US, Canada or switzerland, or within countries with overseas
    dependancies like France, that have local constitutions or local
    constitutional arrangements, or fiscal exceptions for their local markets).



    This archive was generated by hypermail 2.1.5 : Sat Apr 18 2009 - 09:44:07 CDT