Fixing Google geolocation screwups

A friend of mine lives in Alabama and has business service from at&t.
But Google thinks he's in France. We've checked for various
possibilities of VPNs and proxies and such, and it's pretty clear that
the Goog's geolocation for addresses around 99.106.185.0/24 is screwed
up. Bing and other services correctly find him in Alabama.

Poking around I see lots of advice about how to use Google's
geolocation data, but nothing on how to update it. Anyone
know the secret? TIA

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Thanks for sending this to the list: We have the very same issue as well (both IPv4+IPv6). If someone knows the magic button to solve this, please contact me as well.

The list on http://nanog.peeringdb.com/index.php/GeoIP is useful,
especially if several GeoIP databases return incorrect locations.

You might try here: https://www.maxmind.com/en/correction

-A

No, Google has their own internal system. Doubt MaxMind will help out.

This discussions and others like it may lead you in the right direction:
https://productforums.google.com/forum/#!topic/websearch/fkyem9xUKOQ

maxmind is the company that does it for speedtest.net

So if you've ever wondered why your IP blocks still show up as coming from your upstream and not you, well, that's why.

/hard_learned_trade_secret

I figure they all collaborate. I updated one of our IPs with MaxMind
and a few weeks later Google was fixed.

Of course that could be because half the staff here carry tiny
GPS-enabled Google location reporting devices in their pocket too...

-A

It wouldn't hurt to correct it with MaxMind (a great product), but you'd
probably have better results dealing with Google directly. If you have
Google Apps, you've got support, and that would be one way to go about
getting it addressed.

Blair Trosper <blair.trosper@gmail.com> writes:

MaxMind (a great product)

I've heard anecdotal accounts of MaxMind intentionally marking all
address blocks assigned to a VPN vendor as "open proxy" even when
advised repeatedly that the disputed addresses (a) had no VPN services
running on them either inbound or outbound, and (b) in fact were web
servers for the company's payment system, or mail servers for their
corporate email.

Kind of reminiscent of dealing with certain RBLs for whom "personal
beef" was enough reason to list an address. So, folks might want to
temper the "great product" comment with this anti-endorsement.

-r

We operate IPv6 tunnel broker tb.netassist.ua, so /48 from our /32 is
spread all around the world.
Google change geo of our WHOLE /32 from time to time to another cute
random place :wink: One time Google decided we are in IRAN and block a lot
of content as "not available in your country" o_O
Unfortunately, there is no "magic button" to fix it, as well as no human
contact in Google to discuss it. I'm still trying to find a good
solution, but not found it.

I would wonder if these apps didn't have issues that allowed web proxy to
the world. Maybe MaxMind is doing something wrong or maybe they're seeing
the result of malicious activities and classifying from that.

Do check:
http://tools.ietf.org/html/draft-google-self-published-geofeeds-02
That draft also contains folks to kick who wrote it.

Or more details on how SixXS uses that:
https://www.sixxs.net/faq/misc/?faq=geolocation

It is a hard problem unfortunately as there are a variety of reasons why
content owners perform Geolocation (language detection / Content
restrictions etc).

For most organizations "Geolocation" all comes down to "IP Protection"
(Stupid Property aka "Content", not Internet Protocol). Hence, if you
have a /32 IPv6 assigned to the Ukraine (which is already considered a
shady country by most unfortunately for you) and then start offering VPN
services, you'll likely just end up blocked in most of these "IP
protecting networks" as folks just think you are trying to circumvent
their great and awesome IP Protection strategies.

That stated, properly providing a WHOIS entry for each prefix
(inetnum/inet6num) is a good idea as that kind of indicates that that
prefix is fixed in that location and not just moving around.

As for Google, well, they have the method described above, but as they
are primarily a HTTP company, they could just detect Language setting by
the HTTP Accept-Language header. For YouTube etc they are in the same
boat as everybody else: IP Protection. (property not network).

In the end, having a prefix per country/region is the correct way to go.

Do make sure though that you do not show any foreign address in the
whois data (even if that is the correct entity that the prefix is
registered under) otherwise that whole prefix will suddenly be blocked
by for instance Netflix as "it is foreign"... Though Netflix always
considers VPNs as a bad thing, ignoring the fact that for some folks
that is the only real way to get a reasonable Internet experience.

That all said: Restricting content based on location is complete and
utter nonsense in 2015. The world is global, people want to pay for
content and the content owners just don't allow people to pay for it.

We all know what the end result of that is :wink:

Greets,
Jeroen

That all said: Restricting content based on location is complete and
utter nonsense in 2015. The world is global, people want to pay for
content and the content owners just don't allow people to pay for it.

Globalisation is for your corporate lords and masters to buy labour and raw materials where they're cheap.

If mere peons try to buy goods and services in the same way, expect to be crushed by the best legislation money can buy :frowning:

Regards,
Tim.

Globalisation only works if network abuse and network contacts follow best practice and engage.
Else trade blocks and network country blocks are done and remain in place until certain countries ethically/practically do the right thing.

Colin

That stated, properly providing a WHOIS entry for each prefix
(inetnum/inet6num) is a good idea as that kind of indicates that that
prefix is fixed in that location and not just moving around.

[skip]

Do make sure though that you do not show any foreign address in the
whois data (even if that is the correct entity that the prefix is
registered under)

Seems that it is contrary to each other :wink:

I thought to do something like automated whois query on tunnel
destination and put that (geo)data to each /48 inet6num tunnelled. But
as I don't believe it will help, so priority of that task is low and not
yet realized.

shawn wilson <ag4ve.us@gmail.com> writes: