Google Maps: Misbehaving with UA Sniffing
Here’s the TL;DR: Google Maps sniffs a browser’s user agent string. If it finds Internet Explorer on Windows Phone, then it kicks it over to the m.google.com mobile home page.
So let’s be clear. It’s 2013 and one of the biggest companies on the internet is using a sniffer to redirect users on a browser and platform that it sees as competition.
Google’s general claim is that the mobile version of Google Maps is optimized for WebKit browsers (such as Google Chrome) and therefore Google doesn’t support non-WebKit browsers. Even though Google Maps works fine on Firefox mobile (which supports panning, but not pinch-to-zoom) and Opera Mobile (which sometimes supports panning, but not pinch-to-zoom), neither of which uses the Webkit engine. It even renders using Opera Mini, although I can’t get it do anything. I can’t test Internet Explorer on Windows Phone because I don’t have it.
I can, however, test Google’s browser sniffer by changing the user agent string in my browser to report itself as Windows Phone and watch my request for maps.google.com get redirected to m.google.com, the Google mobile home page. This tells me that Google isn’t performing feature detection (such as touch events or multi-touch support), but is instead damning the browser by name alone.
This is the lesson Google is teaching young web developers who don’t understand how flawed this approach is (contrary to its own instructions on best practices from less than a month ago). Google Maps happily lets me have a sub-par experience in Opera Mobile or Firefox mobile. It even lets me have a broken experience in Opera Mini. But Internet Explorer on Windows Phone? Google Maps just boots those users.
Reports I have read (and watched) on assorted articles online suggest that Google Maps works reasonably well on IE on Windows Phone (supporting panning and pinch-to-zoom). As such, I don’t buy Google’s argument that it wants to prevent users from having a poor experience—there is already evidence that a large number of users (more than use Windows Phone) are having a poor experience.
The mobile web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari. However, since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile web.
…Because we actively block them, should be how that quote ended.
So why is Google really doing this? Is it because it’s fun to pick on Microsoft? Is it because Google thought it could get away with it? Is it to make the Windows Phone experience less appealing than Android’s? Is it because Google doesn’t like Microsoft’s touch events specification (and how well it’s been received) at the W3C? Is it because of recent court cases between Google and Microsoft?
In this case I don’t much care. I care instead about the terrible example Google is setting for web developers.
- Google Maps
Has Never Been Accessible On Internet Explorer Mobile Now Blocked on Windows Phone (Updated), January 4, 2013.
- Now Google is blocking Windows Phones from accessing maps.google.com, January 4, 2013.
- Many Windows Phone users report being cut off from Google Maps (update), January 4, 2013.
- Google Maps never supported Internet Explorer on Windows Phone 8, and it likely never will, January 5, 2013.
- Shenanigans: Google Maps redirect issue on Windows Phones is a matter of competition, not compatibility, January 5, 2013.
- This is Why You Can’t Access Google Maps on Windows Phone, January 5, 2013.
- Google Admits It Was Deliberately Blocking Windows Phone Users From Google Maps, January 6, 2013.
- Google says Maps redirect on Windows Phone was a product decision, and will be removed, January 6, 2013.
- Windows Phone Doesn’t Support Google Maps Because Google Doesn’t Want It To, January 6, 2013.
- Google Maps, Windows Phone, and an avoidable mess, January 7, 2013.
My Related Posts
- Let’s Treat Old Browser Users Better, July 5, 2012.
- Another Anti-IE Gimmick, June 14, 2012.
- Exclusion Is a Feature Now, May 10, 2012.
- The Return of “Best Viewed in…”, March 4, 2012.
- Detecting Mobile Devices — Don’t Bother, October 11, 2011.