Google Blogoscoped

Wednesday, September 30, 2009

Mozilla vs Google Chrome Frame

Mitchell Baker, chair of the Firefox-making Mozilla foundation, argues against approaches like Google Chrome Frame (Google’s plugin for Internet Explorer that sort of turns IE into Chrome, giving the browser additional power in certain areas). She says:

Once your browser has fragmented into multiple rendering engines, it’s very hard to manage information across websites. Some information will be managable from the browser you use and some information from Chrome Frame. If the Smart Location Bar in the “browser” doesn’t show the sites you’re trying to return to, then you need to find a way to open Chrome Frame and search there. Your “browser” can no longer aggregate information for you across websites. This defeats one of the most important ways in which a browser can help people manage their experience.

For many people Chrome Frame will make the web even more unknowable and confusing. (...) [I]f you end up at a website that makes use of the Chrome Frame, the treatment of your passwords, security settings, personalization all the other things one sets in a browser is suddenly unknown.

Mitchell further talks about a scenario in which other companies release their own browser-within-a-browser plugins:

Imagine having the Google browser-within-a-browser for some sites, the Facebook browser-within-a-browser for Facebook Connect sites, the Apple variant for iTunes, the mobile-carrier variant for your mobile sites – all injected into a single piece of software the user thinks of as his or her “browser”.

It should be noted that similar is true for sites using Flash, too – Flash also won’t adopt all your native browser settings and auto completions and so on. And indeed, to some developers Chrome Frame may be most useful as a replacement for Flash, like for those who prefer working with JS-Canvas rather than Flash-ActionScript. The whole concept of plug-in technology, which Firefox voluntarily offers as a browser feature, holds the power to both add additional features, as well as cause new user confusion and even security risks. Neither Flash nor Chrome Frame should be chosen by web developers without careful consideration of the pros and cons of an additional layer.

Along these lines, Firefox developer Mike Shaver writes:

[T]he user’s understanding of the web’s security model and the behaviour of their browser is seriously hindered by delegating the choice of software to the developers of individual sites they visit. It is a problem that we have seen repeatedly with other stack-plugins like Flash, Silverlight and Java, and not one that I think we need to see replayed again under the banner of HTML5.

Mike continues to say that “It would be better for the web if developers who want to use the Chrome Frame snippet simply told users that their site worked better in Chrome, and instructed them on how to install it. The user would be educated about the benefits of an alternate browser”. On the other hand, many web developers may prefer easing the process for the user instead of educating them about browser soup wars & installations or showing old-school “best viewed in browser x” banners. Which approach truly is easiest on visitors may depend on the particular context of the web app and the web developers behind it. Right now, DHTML-Ajax, and if not sufficient then Flash, may often be the best to serve to users of more advanced apps, due to these technologies’ high deployment.

What are your thoughts on this?

[Via Spiegel.]

Advertisement

 
Blog  |  Forum     more >> Archive | Feed | Google's blogs | About
Advertisement

 

This site unofficially covers Google™ and more with some rights reserved. Join our forum!