Google blocks Windows Phones from accessing Google Maps site

Just hours after settling the FTC’s antitrust investigation of its business practices, Google has blocked all Windows Phones from accessing its Google Maps mobile site.  The move represents the latest move in an escalating war between Google and Microsoft.

Navigating to maps.google.com on any Windows Phone 7 or 8 handset now redirects to Google’s homepage:

Google issued a response claiming that WP devices wouldn’t work because the Google Maps mobile site was only “optimized” for the WebKit browser engine used by Chrome and Safari, and not Internet Explorer [note: Gizmodo’s assertion that the Google Maps mobile site has never worked on WP7/8 is incorrect]:

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.

This response is, however, problematic at best.  Read on after the break to see why.

1. Google is actively blocking Windows Phone handsets based on their user agent string

 

Web browsers identify themselves to websites via their user agent string, which includes information like the OS and browser name / version.  Google is specifically filtering for browsers that identify themselves as being Internet Explorer for Windows Phone, and redirecting them to the Google homepage instead of Google Maps.

To explore this further, we will use Google’s own Chrome browser (v23.0), running on Windows 8 Pro x64, and change its user agent string.

Navigating to maps.google.com gives the full desktop Google Maps site:

Next, we will change the user agent string.  To do this, pull up Chrome’s developer tools (either press Ctrl-Shift-I, or click the menu button -> Tools -> Developer tools), click the Settings button (a gear at the bottom-right), go to the Overrides tab, then check the User Agent box and select Android 4.0.2 — Galaxy Nexus.

This will automatically set the user agent string to:

Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/534.40 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.40

…as seen below:

Once you refresh the page, you’ll see the Google Maps mobile site:

Now let’s switch the user agent string to match a Windows Phone 8 device, in this case a Nokia Lumia 920.  Select Other… from the User Agent drop-down in Chrome developer tools, and paste the following into the textbox:

Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920)

Refresh the page, and you’ll see that even Google’s own desktop Chrome browser gets redirected to Google’s homepage if it identifies itself as a Windows Phone:

IE10 in Windows Phone 8 offers a desktop rendering mode (via the settings menu), in which it loads sites in almost exactly same way that the desktop version of IE10 would in Windows 8/RT.  To make this happen, the browser identifies itself not as a Windows Phone, but as a full Windows RT PC.  The sole difference is the “WPDesktop” tacked on at the end:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; ARM; Touch; WPDesktop)

First we will insert the normal Windows RT PC user agent string into Chrome:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; ARM; Touch)

Navigating to maps.google.com, we get the desktop Google Maps site:

When we add in WPDesktop at the end:

We still get the desktop site, which is not the case when actually using desktop mode on the phone.  This likely just means that Google is using more than just the user agent string to identify the browser.

Next we must address the possibility that Google blocks WP8 users from its maps because non-WebKit browsers are not capable of rendering its mobile maps site.

 

2. The Google Maps mobile site does work in non-WebKit browsers

 

Firefox, Opera, and even desktop IE10 (which has the same engine as IE10 on WP8!) can load the Google Maps mobile site (mostly) fine.

Here we’ll use IE10 (on Windows 8 Pro x64) to demonstrate.  By default we get the full desktop Maps site:

Now let’s change the user agent string to the Android 4.0.2 string we used in Chrome above.  To do this, either hit the F12 key or click the settings (gear) button, then select F12 developer tools.  Click Tools -> Change user address string -> Custom.  Paste in the string from above, add a “friendly name” for it, then tap Add and Set, then reload the Google Maps site.

You’ll get the mobile maps site (albeit with differently-finished buttons up top):

So Internet Explorer 10 is capable of handling both the desktop and mobile versions of the Maps site.

Firefox Mobile and Opera Mobile on Android are able to load the mobile Google Maps site.  If Google really were motivated by a desire to optimize its map site for each platform (and withdraw site access for a platform until an alternative’s ready), why is only the Windows Phone platform barred fro the service?

 

3. IE10 in Windows Phone 8 is fully capable of rendering Google Maps

 

Now let’s look specifically at the Internet Explorer 10 browser in Windows Phone 8.

While Windows Phones can’t access any US-based Google Maps site, there is one interesting side-note.  Google seems to have forgotten to block one scenario: accessing the Google Maps UK site through the phone’s desktop rendering option.

As a result, with desktop mode enabled (in browser settings), navigating to google.co.uk/maps yields the full Google Maps site:

The site is obviously not very touch-friendly on a phone-sized screen, but it appears to work fine.  The point is not that, absent the artificial blockage, the mobile Google Maps site would definitely work as-is on Windows Phone, but that the evidence seems to indicate that is likely the case.  Google’s explanation looks weak here.

 

4. It’d be quite hypocritical for Google to design its mobile maps site only for WebKit

 

Google paints itself as a champion of interoperable web standards, yet here it claims to have designed one of its core products specifically for one browser engine, incompatible with HTML5 standard-compliant browsers like IE10.  That’s the same behavior that Google (well, more so Mozilla with its Firefox browser) battled when much of the web had been designed specifically for Internet Explorer 6.

The advent of faster-moving standards was supposed to prevent this from happening again, not to enable the underdogs of yesterday to become the tyrants of today.

 

UPDATE (11/6/2013):

Facing scrutiny from around the web, Google has backed down.  In a statement to The Next Web, the company stated that Windows Phones had been blocked from Google Maps in a product decision that will be reversed:

We periodically test Google Maps compatibility with mobile browsers to make sure we deliver the best experience for those users.

In our last test, IE mobile still did not offer a good maps experience with no ability to pan or zoom and perform basic map functionality. As a result, we chose to continue to redirect IE mobile users to Google.com where they could at least make local searches. The Firefox mobile browser did offer a somewhat better user experience and that’s why there is no redirect for those users.

Recent improvements to IE mobile and Google Maps now deliver a better experience and we are currently working to remove the redirect. We will continue to test Google Maps compatibility with other mobile browsers to ensure the best possible experience for users.

The statement makes no more sense than Google’s earlier response — there have been no “recent improvements to IE” that would suddenly make it more compatible with Google’s map site.  Windows Phone 8’s browser, Internet Explorer 10, was announced in April 2012, and has been shipping since the OS launched this fall.

We don’t expect Google will optimize its Maps site in any way for Windows Phone, but it has at least now committed to removing the redirect.

 

UPDATE 2 (11/15/2013):

Google appears to have finally removed the redirect, so Windows Phone 8 handsets can now access the Google Maps site.  In our brief testing, the site seems to work fine– it’s certainly not pretty and has some UI glitches, but at least it’s usable in a pinch.