The Real GoogleOS?

So Google have announced Chrome, their entrant into the web browser circus. They are presenting Chrome as a complete reboot of the browser, which of course it isn’t. It is interesting, however, to speculate wildly about Google’s intentions. We shouldn’t, of course, discount their stated intent of ‘adding value for users’; a lot of features of Chrome are focused upon improving today’s browsing experience. See, for example, pop-ups that are modal only in their own tab, which is something I have been wishing for for ages. However, looking at the big picture, even from a viewpoint far removed, is good for a laugh sometimes.

Read on for some rampant speculation.

Back in 2006, there was a lot of buzz and hype around the possibility of Google producing their own operating system. People event went so far as to very obviously fake screenshots. This never made a lot of sense to me: Google are an advertising company, and an operating system doesn’t obviously afford them new vectors through which to make money. Lock-in to their own applications would have been difficult to achieve on any operating system based on Linux, and suddenly opening themselves up to the pain of support for the hardware forest would have required a serious investment. Google’s strengths are in web-based applications, distributed computing and huge-scale information processing, and a new Windows replacement doesn’t obviously allow them to take advantage of any of that.

So it seems clear to me that an operating system in the traditional sense would not be forthcoming. Instead, it seems that Google are aiming their sights at a level of abstraction above the operating system in a way that makes a lot more sense. Much of what Google say about Chrome makes it clear that they are really trying to force the web browser to evolve as an application hosting environment. The decision has been made: Javascript + HTML + client/server is a powerful enough programming model for the vast majority of applications that a user will, erm, use. By championing a process isolation model - which improves stability - and a faster Javascript runtime - which will improve performance - Google are trying to push their browser towards a general model of application hosting, in the hope that the other big players in the market will have no choice but to follow. Essentially, Chrome seems intended to provide developers with an abstraction amenable to writing the kind of applications that Google want them to write - web based, using Google’s infrastructure and advertising. Providing an abstraction for application development is exactly what an operating system does. Process isolation has long been understood to be a vital part of that abstraction - you don’t want somebody else’s application to be able to screw up your own. Adding that to the browser just makes it a more attractive target for your application.

We’re used to advertising on web-based applications; we’re less ok with it on the desktop (I recall a controversy over a company that offered free XP licenses in return for some 5% of screen real estate for advertising). Nowadays, we can run the vast majority of our applications inside the browser - office suites, photo manipulation tools, music players and so on. There’s little that the average user cannot do inside a browser, and therefore all that they do is susceptible to advertising.

Web browsers are already doing things that operating systems traditionally have done. They already have their own model of window management; Firefox’s graphical tab switcher is one great example of a feature lifted from a general operating system interface that’s made its way into the browser. In fact, tabs themselves are functionality that should arguably be provided by the operating system’s window manager. They provide a very limited filesystem abstraction through cookies, networking through HTTP requests and memory management through Javascript GC.

Next steps might involve a proper storage abstraction - maybe based on on-line storage such as S3. This might then lead the way towards a kind of browser virtualisation (which we already have to some extent because of our ability to log-on at any node) - although building Gears in to the browser gives similar functionality as well as the ability to seamlessly change the machine on which a lot of the code runs from the server to the desktop.

None of these ideas are new - the browser-as-os has been discussed as an idea for years, certainly since Sun tried to bet everything on thin-client based Java computing in the mid ’90s. What has caused the idea to gain momentum now? A lot of hidden factors are doubtless in play, but technologically I would argue that the rise of asynchronous HTTP requests through the AJAX model really opened up the possibilities for applications that simply weren’t there before, and moved the web away from the familiar but restrictive model of refreshing the page upon every request. This handed a lot of flexibility to the interface, and made some modes of operation practical. Since then, the browser has been moving towards becoming a general application runtime environment, to the point where Adobe can even make a on-line version of Photoshop work reasonably effectively. Silverlight and Flash are effectively trying to do their own thing, by prescribing a different application model embedded in a lightweight web-based host, but the aim is the same. However, given that they are so opaque to the browser it seems unlikely that they will take off as the de-facto app environment because it’s extremely difficult to build the user-side infrastructure that supports it efficiently. Pushing the general web page-as-application model makes all the sense in the world for Google, and Chrome can be read as a statement of intent.