Browser

The trouble with test versions

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.

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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.

  2. 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.

  3. 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.

About

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.

13 comments
apotheon
apotheon

The original article has been edited to reflect new information about how Google Chrome manages saved passwords.

Michael Kassner
Michael Kassner

Great post Chad, I know that Google has changed the EULA, eliminating the verbiage about copyright conflicts. I was curious if you had a serious look at the EULA and found any other issues?

kurt
kurt

Check out how many instances of chrome.exe are running on your machine. When you first open Chrome you have at least 2. Then open another tab and you'll have at least one more. Open enough tabs or new windows and you'll run low on resources. There is also a list of commands floating out there on the net that you can append to chrome.exe to do things such as turning off the sandbox, adding even more chrome.exe processes or one called -remote-shell-port. Sounds like and exploit waiting to happen to me.

apotheon
apotheon

Every tabbed browser consumes more resources when more tabs are opened. Every browser has execution options that change the way it behaves. This is not some kind of unique set of conditions that add up to a unique exploit or failure.

Tony Hopkinson
Tony Hopkinson

I was humming and ahing about trying it, you've convinced me, I'll let the less and more aware be guinea pigs for now. :p

apotheon
apotheon

I'm so glad you're leaving it to me to try to use it safely.

apotheon
apotheon

Google Chrome may (or may not) be more secure than other browsers in the long run. There's a lot of promise in its multiprocessor model, for instance. On the other hand, it's so new and untested that it just shouldn't be trusted as much as you may trust many other browsers yet. Come to think of it, you probably shouldn't trust your other browsers as much asyou do, either.

Jaqui
Jaqui

a fork of KHTML according to webkit.org. the KDE project is pretty good about security issues, in that they do work on keeping them to a minimum, so webkit started out with a solid base.

apotheon
apotheon

Yes, WebKit forked from KHTML. In my (limited) experience, with KHTML, WebKit is better -- at least in terms of rendering capabilities.

Jaqui
Jaqui

have a webkit browser to test it, webkit doesn't build on linux. [ really silly of them ] I know that KHTML works, though I've frequently seen browser issues with konq not knowing how to handle a file type when a link is clicked.. yet 2 seconds later it will load the html page just fine. khtml doesn't always render css right, which is a sticky point for all browsers.

The 'G-Man.'
The 'G-Man.'

and secure your connection and what your browser / system can be exposed to (by proxy and filter) and just a 'little less' about the browser security, no?

Sterling chip Camden
Sterling chip Camden

"Come to think of it, you probably shouldn't trust your other browsers as much asyou do, either." It pays to always be on your toes. But thanks for the heads up on a couple of issues I hadn't known about.

apotheon
apotheon

I'm glad to be of some help.

Editor's Picks