Can't shop for Windows Store apps using Chrome... But is Google being evil?

Here's a spot the difference for you - same URL to the Remote Desktop app on Windows Store, but one of these browsers is not like the others:

Strange - you can't "View in Windows Store" on Chrome?
OMG! Google is so evil! They are blocking access to the Windows Store on Windows 8!
Well, hardly. Here's an object lesson on why building an operating system and apps ecosystem is hard.

Protocols

I was alerted to this by a tweet from Charlie Kindel (an ex-Microsoftie): "#Win8Fail: Open a link to an app like this (thanks @timheuer) and there's no way to jump into the Store to buy it." (Charlie had included the wrong link in his tweet, so I haven't included it here.)
What transpired that, as shown in the screenshot above, in Chrome there's no button to jump to the store. Find an app you like when browsing in Chrome and you can't get to it in the built-in Store app. (Even if you set Chrome as the default browser in Windows 8.)
The problem here is that the way Microsoft has implemented the button is weird, and I'll come onto that in a moment. IE supports the weirdness, Firefox sort of supports the weirdness, but Chrome doesn't. Microsoft's server detects when the user is using Chrome and doesn't include the button in the markup. (The same trick that it plays if you're using an OS other than Windows 8.)
The point is, it's not Google being evil. Google's the one getting this right.
Back in the mid-90s when I used to do a lot of desktop development, I used to enjoy writing custom URI protocol handlers. The idea of these is that instead of just having http:, https:, and mailto: protocols on the OS, you can write your own - such as foobar:. Put that special, custom protocol in HTML and when the user clicks it, it'll run your app. No questions asked. Click - boom - you're in.
In this case, Microsoft is using a custom protocol with the name ms-windows-store, which happens to be registered by the Store app on Windows 8. When you press the button, a special URI using this protocol gets passed to Windows and the Store app is launched. Simple.
This approach never really gained favor - partially because it fell into that "Microsoft is the center of the universe" thinking that pervaded the late 90s, but also because it ignores the fact that such protocols should more properly be defined as RFCs and subject to proper scrutiny, as opposed to randomly smeared onto devices by OS and third-party vendors. It's a nasty malware vector because it creates a single hop from browser into OS and into a launched app. Not something you'd want.
But, in the new world of Windows Store apps, protocols are actively encouraged. There are protocols for bingsearch, bingmaps, bingweather and so on. The capability to easily add protocols (and it is really easy) is part of the Windows 8 design concepts that bend away from the iPad's silo-like nature. Apps should be able to care and share about each other. Protocols let apps invoke other apps in a way that's safe and trusted. That Bing Maps URI presented above lets an app invoke driving directions in one line of code. In that sense, it's pretty cool. Native app to native app protocol linking is helpful.
You can try it yourself if you have Windows 8, do Windows+R and paste in the URL bingmaps://open/?rtp=pos.51.99720_-0.74220~pos.51.99437_-0.72629&trfc=1". It'll open up Bing Maps with driving directions.
(Case in point - if you're running IE on Windows 8, that link will work. But it won't on Chrome. And it sort of does on Firefox.)

All pretty clever…

But on the web, this approach is essentially wrong.
What I don't like about this is that it has the feel of very old school thinking. Microsoft has a lot of very experienced and talented developers, but with experience comes an understanding of approaches which have perhaps passed their time. You don't build websites with proprietary dependencies like this baked into them. That's how we used to do it in 1998, not 2012. There's a lot of this sort of thing in Windows 8, particularly when you look at how developers are expected to build Windows Store apps. The old guard is very much back in power over there, and here's another example. Microsoft is a better company when it's driven to deliver to open standards and applies modern thinking.
Essentially, Google is right to disallow this sort of link. If you create a web page with the Bing Maps URI in it from above and click on it - it does nothing. And why should it - there's no RFC describing bingmaps, thus the browser should assume it's evil.
The proper way to do this, just to round off the discussion, is to register a content type (e.g. application/x-microsoft-store). The user would download a file with this sort of content type and open it - the Store would then run. Incidentally this is how the custom downloader for the Amazon MP3 store works. It can be done with a decent enough UX, too.
But what Microsoft does now is anyone's guess. When you've got one ex-Microsoft guy and one current Microsoft guy scratching their heads about why the button doesn't appear in Chrome, it doesn't bode well for the average user. And the problem can't be fixed without updating the Windows Store app that gets deployed along with Windows 8.
What do you think? Post a comment, or talk to me on Twitter: @mbrit.