Alpha and beta test releases of applications provide an easy way to get early, free access to new software. Google Chrome serves as an excellent example of how important it is to be very careful with testing versions of applications.
Google's new Chrome browser is big news right now. It seems like everyone has something to say about it — and everyone, including me, wants to give it a try. There are a number of reasons I will not use Chrome as my primary browser, however:
- The first reason is the most insurmountable and unignorable right now — the fact that only a Microsoft Windows version has been released at this time. My primary OS platform is FreeBSD.
- Several minor operating quirks, for which I have not discovered any work-arounds other than using a different browser, exist. One, for instance, is the fact that Chrome inserts "hard" linebreaks when submitting form data in a text area field.
- Being an early beta test release, there are, of course, some security issues cropping up. Some of them are actual design flaws — and such flaws may be significant enough that I cannot justify allowing myself to run afoul of them for my primary Web browsing activities.
In "What are the security implications for Google Chrome?," I made the point that "Chrome represents a lot of new code," and as a result of that fact, the potential security dangers of new and untested code will occasionally be realized in very real vulnerabilities. In time, one hopes, the vulnerabilities that arise will be fixed; discovery and correction of such flaws is part of the reason for a beta test, after all.
In the meantime, you have to be very careful — make sure you don't run afoul of those vulnerabilities in a way that can actually cause any damage to your privacy and your computer's security. Some of Chrome's vulnerabilities and weaknesses in design provide excellent indicators of the kind of measures you should take to protect yourself when using alpha and beta test software:
Not so much a vulnerability as a poor choice of feature design, Google Chrome's cookie handling configuration is less than perfectly conceived. For example, with Firefox you can configure it to require approval of every cookie you want by choosing "ask me every time" for the "Keep until:" configuration option. Chrome does not offer a comparable option.
Of course, this is more a matter of preference for long-term use than of security. The real security concern that should be recognized is that cookies should simply not be accepted at all in an early test version of a brand new Web browser. Until it has been extensively tested, the possibility of cookie management being improperly implemented so that data might be shared across domains is a danger to which I don't care to expose myself. Of course, this means I can't use Chrome to log into any Website where cookies are required for authentication (except in carefully selected test cases) — which means I can't really use Chrome as my primary browser, of course.
A download vulnerability in Google Chrome has been discovered, and it's getting a lot of attention. The problem is that Chrome may download something you don't want downloaded without checking to see if you actually want to download it. This particular vunerability isn't any kind of problem for me, personally, at all: an effective work-around for it is to simply configure Chrome to always ask where you want downloads saved because this gives you a chance to cancel an unwanted download — and that is one of the first configuration changes I make to any browser I use anyway.
The general problem this points out is that sometimes new applications automate things that should often not even be allowed in the first place — and there may not always be such an easy configuration fix for it as there is in this case. For this reason, when using a testing version, a new application should be "sandboxed" in some way so that the (likely inevitable) vulnerabilities of a significant collection of new code would not be allowed to affect the rest of your operating environment. This may mean running it on a separate testing system (which is effectively what I'm doing) or running it only within a strictly divided environment all its own, such as a Unix chroot jail. This, too, serves to make it very difficult to use Chrome as my primary browser.
Finally, there are reports that Google Chrome saves passwords in plaintext. This is, as any security professional should know, a colossal blunder for security software design. Saved passwords should not exist in a readable form in files on the hard drive; if stored at all, they should only be saved in an encrypted form. Because of the way Chrome offers to import settings from another Web browser, and doesn't let you pick and choose which settings to import, when installing Chrome you should simply refuse to let it import any settings at all — and, once it is installed, configure Chrome to "Never save passwords" for general use.
Such reports of Chrome's mishandling of passwords are apparently incorrect. In fact, it seems that Chrome uses an easily adjustable function to handle encryption, internally, judging by the linked review of the source for Chrome's password manager. This should come as a significant relief to anyone who has been using Chrome to access Websites that require a password, and allowing the browser to save those passwords. Still, Chrome has a lot of real-world testing to go through before I'd trust its password management too much, since it's easy to miss a bug that produces a significant vulnerability like this in early stages of development.
Because password management is so easy to get wrong for those who do not have extensive experience with such matters of security design in software development, the password handling functionality of a new test release of a brand new application should simply not be trusted. This is not necessarily a deal-breaker for using Chrome at all, but for those who are used to the convenience of secure and effective password management in a browser that saves passwords for us, this can make a new application available only as a testing release very inconvenient for everyday use.
Other potential dangers exist as well, including the possibility of improper implementation of SSL/TLS encrypted connections to secure Websites, cross-site scripting capabilities, and effective privilege separation. Nobody can really predict all the potential problems of a completely new application, such as Google Chrome today, which is why a simple remedy such as sandboxing the entire application is the only really effective solution to the problem of securing oneself from the vulnerabilities of a brand new testing release of an application.
The beta testing release of Google Chrome is worth trying out — but don't let yourself believe it should be used as your primary browser just yet. It's called a "beta" release for a reason.
Of course, Google calls pretty much everything "beta" even years after initial release, and not all of it is something that you can't safely employ for everyday use. As new as Chrome is, though, it has a way to go before it has been thoroughly tested enough to trust it as much as you might trust another browser.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.