A failure to abide by its own principles has made Google look like a bad guy.

Share this story

Google has two versions of Google Maps. Visit maps.google.com from a desktop browser and you'll get the desktop version, designed for large screens and mice. Along the top of the screen, you get Google's global navigation to let you pick between Maps, Images, Search, YouTube, and so on. On the left of the page, there's white space where search results and directions go. On the right, a large map.

But visit on a smartphone and you'll get the mobile version of Google Maps. This is slimmed down and designed for fat fingers on small screens; no global navigation, just a map occupying 90 percent of the screen and four finger-sized buttons at the top.

At least, that's what you see if you're using Safari on iOS, or Chrome, Android Browser, or Firefox on Android. Fire up Internet Explorer on Windows Phone, however, and you'll just get redirected to Google's mobile search page. This happens regardless of whether you have the browser configured to prefer desktop versions or mobile versions of sites.

Windows Phone users have noticed this, and they're not very happy. Widespread complaining around the Web reached a climax at the tail end of last week.

When quizzed about the block on Friday, January 4, Google's first response was:

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.

Google's response didn't, however, pass the sniff test.

First, it falls down on practical grounds. Windows Phone 7.5's browser is in most ways identical to the desktop version of Internet Explorer 9. Windows Phone 8's browser is virtually identical to Internet Explorer 10. The desktop version of Google Maps works just fine in these browsers. It's one thing for Google to say the mobile site isn't tested or supported in the mobile browsers, but the desktop version, at least, shouldn't be off-limits. The desktop version may not be ideal in a mobile browser, but it does work.

Microsoft's own statement on the matter makes this very point:

Internet Explorer in Windows Phone 8 and Windows 8 use the same rendering engine.

Blocking the phone browser but not its desktop sibling makes no sense from any technical perspective.

Making this point even more forcefully is the fact the blocking only occurs when you visit maps.google.com directly. If your browser is configured to request desktop sites, maps.google.co.uk serves up the desktop site to Windows Phone without complaint. If you have a direct link to a particular address then the link will work, too, with Google showing you either a mobile-oriented map page or a full desktop map page, depending on which kind of page your browser is configured to request. iFrames used to embed maps in other pages also work.

This means the sites for restaurants, museums, and other real-world attractions that link to or embed Google Maps to tell customers where they're located do work correctly, even on Windows Phone.

Further undermining Google's "WebKit" argument is the fact that Firefox on Android—which uses Mozilla's Gecko rendering engine, and not WebKit—isn't blocked. Google's statement makes a claim ("since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile Web") that doesn't hold true. Not using WebKit does not, in fact, prevent access to mobile Google Maps.

Enlarge/ Mobile Google Maps working fine, or at least adequately, in Firefox on Android.

On top of all this are experiments done by two developers who write apps for Windows Phone. The block on Google Maps is a very simplistic one. Every time a browser requests a webpage, it tells the server its name and version, a piece of text called the User-Agent. Google Maps is using this User-Agent to choose whether to deny or permit access to Google Maps.

This was demonstrated in two ways. Tom Verhoeff used the Fiddler proxy server to rewrite the User-Agent of every request made by his phone. He replaced the Windows Phone User-Agent with a Chrome User-Agent—at which point mobile Google Maps became available to his Windows Phone, and it basically worked just fine.

Microsoft employee Matthias Shapiro similarly showed the User-Agent was the only thing standing in the way of successful use of Google Maps. He wrote a basic Windows Phone app that embedded the browser. Apps that embed the browser have the ability to override the User-Agent the browser sends; in Shapiro's case, rather than using a Chrome User-Agent, he simply misspelled the words "Windows Phone" but left the User-Agent otherwise unaltered. Once again the site basically worked.

As such, it's clear that there's no sound technical argument for Google's behavior. It's possible—perhaps even probable—that the mobile version of the site has some nuances and features that only work in WebKit, so Google might have some basis for denying access to the mobile Google Maps to Windows Phone. This is still dubious—those WebKit-only features wouldn't work in Firefox either, but Google's not blocking access to that browser. But without thorough testing it's hard to know what will work and what won't, and Google may be unwilling to commit the resources to testing a minority platform.

The desktop site is another matter entirely. Google already supports the Internet Explorer rendering engine on the desktop site. Mobile browsers that request the desktop site should be given access.

Google pulls a similar stunt with Gmail access. Windows Phone 8 can access the mobile and "basic HTML" versions of the site, but any attempt to access the full standard HTML desktop version reverts to the mobile site. This is in spite of the fact that the full version works fine in Internet Explorer 10.

Doing the wrong thing

Second, the claim that mobile Google Maps is WebKit-only falls down on philosophical grounds. In May 2011, Google claimed mobile Google Maps was "platform independent" and that "you will always get a consistent experience and the latest features [...] no matter what phone you use." The current behavior clearly contradicts that claim.

Broadly, the Web is built on vendor-neutral open standards. Requiring specific rendering engines is truly a return to the bad old days of "This site is best viewed in Netscape 4," and undermines the open intent of the Web. Parts of Google certainly understand this; Google developers working on Chrome and Web standards have supported Microsoft's efforts to produce interoperable spec and add interoperability features to WebKit. Microsoft, for its part, has implored Web developers to avoid treating WebKit as if it were the sole rendering engine on the Web.

Google's own guidelines for Web developers also warn that User-Agent detection is error-prone and liable to give users bad experiences. Instead of User-Agent detection, the company recommends the use of responsive design, a technique that uses CSS to alter page layouts to make them suitable for both mobile and desktop devices.

A plan to do the right thing

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.

This new statement implicitly contradicts the first, WebKit-only, claim. It acknowledges Google does, in fact, perform some amount of testing in non-WebKit browsers, and that mobile Maps isn't just for WebKit. It's also true that in Windows Phone 7.5, which uses Internet Explorer 9, panning and zooming the map content didn't work correctly. There is a legitimate issue there. This issue doesn't exist in Windows Phone 8.

The block is still in place at the time of writing, but assuming Google stands by its current statement, it should be lifted at some point and everyone will be happy.

Google making itself look bad

Nonetheless, the entire incident leaves Google looking tone-deaf, at the very least. If you're going to have "Don't Be Evil" as your corporate slogan, you'd better act holier than the holiest white knight if you don't want to look grossly disingenuous. The actions here were not whiter than white. The Windows Phone block is badly implemented, overly broad, and contrary to fundamental Web concepts, Google's claims about the mobile Google Maps, and Google's own published best practices.

Google's initial statement was untrue. It was perhaps approximately true, as it's certainly the case that WebKit browsers are the ones with the best support, but it wasn't actually true. If Google had truly been blocking every non-WebKit browser then its actions would still be disappointing, in the light of its recommendations to Web developers, but perhaps no worse than all the other companies that assume that all mobile browsers are WebKit.

But it wasn't; it was letting other browsers through the blockade, which in turn gave the impression that it was singling out Windows Phone for bad treatment. Which in fact it was, but probably for sound historic reasons (the mobile Google Maps site does work poorly with Internet Explorer 9) rather than any malice. Google's statement made its actions look worse than they really were.

Ultimately, Google could have avoided all the bad press and ill feeling if it had stuck to its principles. If responsive design and progressive enhancement—development strategies that make Web content available as broadly as possible—truly aren't viable for Google Maps then User-Agent-based redirections might be a necessary evil, but they should be narrow, accurate, and consistently implemented. Google's failure to do this, followed by its cack-handed PR response, has made the company the bad guy when it really didn't have to be.

141 Reader Comments

I thought the issue was that google maps used the webkit... version of touch (and mozilla supported it too) and microsoft went out with pointer events instead of touch events? Which is why you couldn't pan the screen. Wasn't this an article you featured kind of recently?

Well on my N9 (Also a Webkit Browser) Google flat out refuses to give me any maps experience. If I go to maps.google.com I get redirected to mobile.google.com. If I select "Classic" instead of mobile, I get the desktop google, with a maps link. Clicking on that, I get sent back to google.com.

I've got webkit so there is no excuse. Google is just being a shit-head.

But... but... Google's motto is do no evil!! Clearly they cannot ever be the bad guy!

Google's motto is "Don't be evil" which is slightly different than "Do no evil".

So I guess you can do evil things without actually being evil after all.

If someone drinks alcohol once, he is not considered a drunkard. It is the repeated offence which makes such a person into a drunkard. Not being evil says the M.O. won't be evil, but that doesn't mean they won't mess up on occasion.

Just shows the way things are going.Everything is heading to the internet, without heading to the internet. It's heading to walled garden apps that have specific features, and you need an app for each platform to be able to properly use all features.

It is such a shame. I much prefer the design of the Windows Phone compared to Android or iOS. Both of the latter look really dated. My biggest issue is functionality and the loss of some apps that I can get easily on iOS and Android, Maps included.

I'm persevering with my Windows 8 phone regardless and will take the compromises while Google and Microsoft battle it out because the interface is so much nicer. I still use both iOS and Android on my other devices though, just not as my main device.

From Google's Code of Conduct:[quote]“Don’t be evil.” Googlers generally apply those words to how we serve our users. But “Don’t be evil” is much more than that. Yes, it’s about providing our users unbiased access to information, focusing on their needs and giving them the best products and services that we can. But it’s also about doing the right thing more generally – following the law, acting honorably and treating each other with respect.

...

And remember… don’t be evil, and if you see something that you think isn’t right – speak up!

Last updated April 25, 2012 [\quote]

Google do not treat Windows mobile users as second class Google users. That is it. I spoke up.

Google's behavior is the prototypical behavior you get from a company with monopoly power over a marketplace. I'm not going to shed a tear for Microsoft because of the way it continues to use its monopoly position in the OS to try to bludgeon its way into new markets - see Windows 8 - but I wonder if anyone there appreciates the irony of being bossed around by the search monopolist. Still, whatever schadenfreude there is to enjoy from this, Google's redirect is wrong and detrimental to users.

If responsive design and progressive enhancement—development strategies that make Web content available as broadly as possible—truly aren't viable for Google Maps then User-Agent-based redirections might be a necessary evil, but they should be narrow, accurate, and consistently implemented. Google's failure to do this, followed by its cack-handed PR response, has made the company the bad guy when it really didn't have to be.

This appears to be a good summary and a fairly level-headed conclusion from Peter, but I love that *this* is the corporate evil that's been exposed. Poor responsive web design. Truly a dark world we live in.

Whether or not you belive it's still effective as it once was, at least "don't be evil" is still working exactly as Paul Buchheit intended.

You mean the new Google-endorsed version (which they are trying to get into WebKit) that the W3C is taking forward in favor of the previous draft because Apple is playing patent hardball?

Seems odd that they wouldn't want to support that...

Only seems odd if you think an app like Google Maps can be fixed up in a day or two. There’s fixing, testing, testing, testing, fixing some more, testing, fixing an exotic bug that only happens on one out of 10 types of devices, then releasing it. Compared to that, they already had the other version up and running.

But dunno, could have been a too-low-marketshare decision? Whatever it was, people are demanding Google to provide engineering and QA efforts for free. Aren’t here other mapping solutions for Windows Phone?

I dunno if this is as it seems... I also can not access maps.google.com from chrome in android. though could from the stock browser...

Though it has worked fine in the past...

Chrome for android partially loads the page, but no map data... built in browser works fine...

Galaxy Nexus - stock 4.2.1

It works just fine on a Galaxy Nexus running AOKP RC1 (4.1.2) using a fully updated copy of Chrome, so maybe it's your data connection...

(Though the desktop site redirects to the mobile site even if I press "request desktop site," which is always annoying -- if I click that I probably I know what I want, so don't redirect me!)

I dunno - I checked everything... Chrome on my Nexus running 4.2.1 will not load any map data.. stock browser will... I am just reporting what I am seeing - both stock and chrome would be pulling the same data...

But... but... Google's motto is do no evil!! Clearly they cannot ever be the bad guy!

Google's motto is "Don't be evil" which is slightly different than "Do no evil".

So I guess you can do evil things without actually being evil after all.

If someone drinks alcohol once, he is not considered a drunkard. It is the repeated offence which makes such a person into a drunkard. Not being evil says the M.O. won't be evil, but that doesn't mean they won't mess up on occasion.

I thought the issue was that google maps used the webkit... version of touch (and mozilla supported it too) and microsoft went out with pointer events instead of touch events? Which is why you couldn't pan the screen. Wasn't this an article you featured kind of recently?

If responsive design and progressive enhancement—development strategies that make Web content available as broadly as possible—truly aren't viable for Google Maps then User-Agent-based redirections might be a necessary evil, but they should be narrow, accurate, and consistently implemented. Google's failure to do this, followed by its cack-handed PR response, has made the company the bad guy when it really didn't have to be.

This appears to be a good summary and a fairly level-headed conclusion from Peter, but I love that *this* is the corporate evil that's been exposed. Poor responsive web design. Truly a dark world we live in.

I dunno, I think that's actually a pretty big deal when the Web is as important to your company as it is to Google.

We recently spent a week or two working on cross platform code for touchscreen events.

We encountered a few problems in webkit browsers, but they were surmountable. Firefox on android was completely flawless, it seems to be the most reliable touchscreen browser. Internet Explorer had huge issues and we still have not overcome some of them.

Some of the code we used, which was broken in windows, was framework code written by google and published as open source. We had to abandon their code, since it meant that every single link and button in our app failed to work at all in internet explorer running on a touchscreen. Two of us spent several hours trying to fix the bugs instead of abandoning the code but we could not find a way to make it work.

I trust google's statement that "last time they tested it" their maps software did not work properly on windows phone, especially since it has improved a lot in the latest version. And especially since there are so few windows phone users out there.

As long as they fix it soon I have no problems. Windows phone does have a pretty good browser (but still far more difficult than webkit or firefox as I have learned).

Supporting "every" platform should not be taken literally. There are hundreds of browsers and some of them really are difficult to support. The point is to support all the major browsers, and windows phone barely qualifies for that. I know for a fact that this comment box I'm typing into is an absolute pain in the ass to use on WebKit mobile. If Ars doesn't even bother to get their website working well on iOS, then it's a bit much to accuse google of not supporting windows phone.

I wouldn't be surprised if the reason it "mostly works" right now is because google has been working on making it work for months, but doesn't intend to remove the user agent sniffing until that work is completely finished.

JavaScript and HTML and CSS are full of assumptions that make absolutely no sense at all on a touchscreen. When Apple shipped the first serious touchscreen browser, they figured out ways to solve all of those problems. All WebKit browsers have apple's solutions and FireFox has implemented them too (and done an even better job than WebKit). Internet Explorer however, has done a poor job implementing these. Instead they've implemented draft standard specifications which did not exist a few years ago and are still only a draft today. Those draft standards are not anywhere near ready for prime time in my opinion - they are full of mistakes that need to be fixed first.

An obvious example is when you tap the screen it sends a "click" event. Simple right? Except when you tap the screen twice it doesn't send any click event for either tap, instead it zooms in where you tapped. This means when you tap once, it has to wait until the user does not tap a second time before sending the "click" event. You think your 3G/LTE connection is slow? More likely it's just this feature that makes pages appear to take a long time to load, and it's painfully obvious when a tap doesn't trigger any network activity. That's only one example of a problem we struggled to solve in internet explorer.

I find it more disappointing than anything. As a WP user, I really do love web apps since (as Elopp has recently noted), they have the potential to make app markets irrelevant (or more accurately, less of an issue). On the desktop ok finding them to be great, and am waiting for mobile to be the same way.

For Google, who has advertising as their main revenue stream, denying anyone a chance to use their services (and thus obtain not only advertising opportunities but more importantly DATA)? This move makes no sense to me. Not making specific apps for WP is one thing, but cutting off web app access that use standards like HTML? Thats ridiculous

I always understood Google to be like Visa - everywhere I want to be. As long as I have a modern enough browser and hardware, Google had something for me - entertainment, work, services, etc. I don't understand why they would start to change that when its worked out for them so well, that hardware/OS independence is one of their greatest strengths.