Google has announced the beta test release of its new Web browser, Chrome, and everybody’s talking about it. It’s time to talk about the implications this new browser may have for Web browsing security.

The appearance of the Google Chrome browser has caused quite a stir. Everybody’s talking about it, including a number of writers right here at TechRepublic. Most of what caught my attention was the security implications, of course:

  1. The multiprocess model of operation for browser tabs allows far greater partitioning of resources (see Google’s talk about “sandboxing”, for instance). If handled well, this may mean the end of cross-site scripting, many types of denial of service attacks on browsers, and certain types of buffer overflow attacks. Google rightly touts the shared-nothing approach to tab concurrency — and Google knows quite a bit about the benefits of shared-nothing architectures.
  2. The limited permissions and privilege separation model Google describes in its comic book about Chrome is a significant improvement over what other modern Web browsers use. Part of the reason for this is surely because such a model is easier to implement when each tab runs in its own process, but there’s nothing I’ve seen to suggest other browser developers could not have taken an approach to partitioning plug-ins and scripting the way Google says Chrome will do so.
  3. Some express concern over whether Google might collect data from users through Chrome, the same way it does so with its various Web services such as Gmail. This seems extremely unlikely, considering Chrome is 100% open source software, however — especially once it becomes available for open source OSes and gets included in their software management systems, because at that point our upstream software binary providers (the package and port managers for those OSes) will not be Google.
  4. On the other hand, Chrome represents a lot of new code. Sure, there are parts of it that are simply picked up whole from other open source projects (like the Webkit core of the application), and have thus been substantially stress-tested and secured, but there’s a lot of new code involved as well.
  5. V8, Chrome’s new JavaScript virtual machine, is of particular interest as new code — because it is a whole new implementation of JavaScript. JavaScript is, when sloppily used, one of the most problematic sources of security issues in most browsers (discounting issues specific to individual browsers such as ActiveX controls).
  6. On the gripping hand, V8 provides an excellent opportunity for new architectural security to be employed in the implementation of a browser’s scripting support.
  7. The fact that all the new code in Chrome is open source software that seems specifically designed to be reused in other open source development projects means that sussing out any security issues in the new code and fixing them may happen at record speed.
  8. As a brand new browser, Chrome lacks a lot of third-party software support enjoyed by other browsers. Some of that third-party support could include security benefits, particularly including examples such as Perspectives and other encryption related extensions to basic functionality.
  9. I can’t comment very thoroughly at this time on how well saved passwords are handled by Google Chrome, but it’s something that will definitely bear watching. Initial observations include the fact that Chrome “only displays one at a time when you ask it to, instead of all at once like FF” — to quote fellow TechRepublic writer Sterling Camden, of IT Consulting.
  10. Chrome’s “Incognito” browsing mode seems well designed, and — coupled with the strong data partitioning implied by its multiprocess tabbed browsing model — should offer significant benefits over the major combatants already involved in the browser wars in terms of secure browsing capabilities.

For a long time, I have thought about eventually writing my own Web browser. Since before Firefox 2.0 was released, I have been increasingly of the opinion there simply aren’t any modern Web browsers that are actually good — only some that are less awful than others. Some people complain that Google chose to create a new browser rather than contribute development to an existing open source browser like Firefox, but (like Google) I believe the changes needed to make a significantly better browser at this point involve changes so fundamental that they basically require starting over from scratch.

Probably the biggest change from the standard browser design model I had in mind appears to be the biggest that Google Chrome uses as well: multiprocess concurrency design. I’ve since come to think that perhaps the benefits I wanted from such a model could be accomplished with a multithreaded model, and people are already noticing the process overhead that contributes to a fairly significant memory footprint for Chrome — overhead that I would have sought to avoid by going with a multithreaded model instead of a multiprocess model. On the other hand, the development difficulty of achieving some of these benefits, especially the security benefits, is notably greater using a multithreading model rather than a multiprocess model.

All in all, it’s the multiprocess browsing model of Chrome that most interests me, and I will be watching as Chrome develops to see just how well it works out in the long run. I have high hopes that, before much longer, I may be able to replace my least-bad browser with one that is actually good.

. . . or at least less bad.