Chrome Frame erodes IE from the inside: Can Google get away with this?

Yesterday's revelation by Google that its open source Chromium lab developers have been testing deploying the Chrome browser engine as an Internet Explorer add-on called Chrome Frame, and its subsequent opening up of that project to the public, is a surprisingly ballsy move from a company typically known for being cool, plain, and innocent-looking. Quite seriously, the complete engine is being offered as a downloadable add-on, with the promise that developers will be able to retool their sites to let IE users render them using standards accepted by developers rather than those deployed by Microsoft.

But that's not exactly what happens -- and in fact, that last phrase could apply in any number of cases to how the browser-within-a-browser actually works. First, for developers to be able to utilize these standards, they're being invited to include tags in their code that target a specific browser, such as <meta http-equiv="X-UA-Compatible" content="chrome=1">
But as you can plainly see, that browser isn't IE. It's Chrome, which means that Google Frame is actually an incentive to get more developers to target Google's browser specifically.

"When Google Chrome Frame detects this tag it switches automatically to using Google Chrome's speedy WebKit-based rendering engine. It's that easy," reads yesterday's blog post from a trio of Google engineers. "For users, installing Google Chrome Frame will allow them to seamlessly enjoy modern Web apps at blazing speeds, through the familiar interface of the version of IE that they are currently using."

But that's not exactly what happens. Chrome Frame doesn't completely replace the IE rendering system, nor does it give the user (yet) any option to do that -- at least, not an obvious one, though we're actively looking for a non-obvious one and we won't be surprised if we find it. You would think that, by "modern Web apps," Google would mean its own, naturally. However, our own tests clearly reveal that not even Google itself has utilized its own tag; if you launch Google Docs, for example, in Internet Explorer 8, the rendering engine will be IE8.

To overcome this little hitch, users themselves can trigger the Chrome Frame add-on by adding cf: as a prefix before the URL prefix, as in cf:http://spreadsheets.google.com... For our Google Docs test, we had to log in through the ordinary IE8 page, then hack the address line ourselves with the prefix to engage Google Frame. (One way to tell which rendering engine is responsible for what you're seeing is by right-clicking on a blank spot on the page. Chrome Frame's options only appear when it's in control.) But not even this method is foolproof: In Betanews tests this afternoon, we were unable to get Chrome Frame to load locally saved Web files, probably because the two browsers' protocols for local files (Chrome uses file:// with forward slashes, while IE reverts to the DOS-style filename with the backslashes) are incompatible.

We also noted that Chrome Frame didn't leave IE in good running order after returning to a page rendered by IE -- for instance, when pulling up a locally stored bookmark. IE frequently crashed, though was able to restart itself and pull up the crashed pages. Still, this leaves open the question of exploitability -- whether by crashing Internet Explorer, Google is actually creating a new security hole.

We also noted Chrome Frame expects to be Chrome -- it doesn't know how to respond to some user events in the context of a window other than Chrome. For example, dragging and dropping a page from the Desktop or an Explorer file listing into an IE tab that's being rendered by Chrome Frame, crashes Chrome, which responds with its "sick folder" icon reminiscent of old Macs. It does not crash IE, however; it still permits the crashed tab to be closed.

Until we discover, or someone kindly tells us, the secret to getting Chrome Frame to render locally-stored files, we can't test our complete Betanews browser test battery within Chrome Frame. We were able to obtain a few scores in some computational tests: In the SunSpider JavaScript benchmark, for instance, Chrome Frame in Windows 7 RTM posted a phenomenally high score of 58.32 on our index -- representing over 58 times the performance of Internet Explorer 7 on Windows Vista SP2, on the same physical platform. That was a surprise for us, since the most recent scores we'd obtained for the stable build of Google Chrome 3 was 49.76 on the same test. IE8 posted a 5.66 for the SunSpider battery.

In the Celtic Kane computational test, Chrome Frame posted an 8.94, compared to 9.22 for Chrome 3, and 1.97 for IE8.

What's even more curious than how well Chrome Frame performs is the subject of what Google may intend to do with it once it's done (if it's done). From a standpoint of pure user convenience, it appears much easier for folks who want to see Web pages rendered in Chrome, to download and use Chrome -- it's a free product, and there's nothing stopping them. It can import bookmarks from IE, and although it doesn't make use of IE's other add-ons, there aren't too many that are exclusive to IE anyway. So there doesn't really appear to be much of a value proposition in encouraging users to install Chrome Frame either as an alternative to Chrome, or as an add-on to IE triggered either by developers' tags or user influence.

But if Google Apps, including Docs and Gmail, or possibly the Google Toolbar add-on were to at some point include Google Frame, then the company might have a way to grease the wheels for Chrome to pick up a few more points in usage share. Google tools users would end up using Chrome, assuming its engineers figure out the "seamlessness" part. Yet that would be an uncharacteristically snake-like way for Google to begin marketing Chrome, reminiscent of when Apple iTunes users woke up one morning to discover they were connected to MobileMe.

Even as a simple experiment to "augment" the most widely-used browser by replacing it, the Chromium team's project does seem a little wanton, and appears to have taken Microsoft completely by surprise. Not only is there the issue of Chrome Frame's appropriateness, but also the legal issue of whether someone licensed to produce add-ons for a product may market an add-on that actually contains the competitor of that product, in essence or in its entirety.

Responding to Betanews' inquiry, Microsoft's corporate communications team has deferred comment on Chrome Frame, for now, to the Internet Explorer team which has yet to craft a response.