Is security in Google Chrome flawless?

Google Chrome was built from the ground up to be a more secure Web browser, and Google and its Chromium developers should be applauded for the attention they have brought to browser security. Google deserves much credit for the wealth of security information posted on the Internet and on the Google Chrome blog, and for making Chrome's source code available for anyone to examine.

The security model Chrome follows is excellent. Chrome separates the main browser program, called the browser kernel, from the rendering processes, which are based upon the open source WebKit engine, also used by Apple's Safari. The browser kernel starts with all privileges removed, the null SID (a security identifier in Windows Vista that denotes the user as untrusted), and multiple "restrict" and "deny" SIDs enabled. On Windows Vista, Chrome runs as a medium-integrity process.

Every Web site is given its own separate rendering process, memory space, global data structures, access token, tab, URL bar, desktop, and so forth. Currently, Chrome will open as many as 20 separate processes, one for each Web site, and start sharing processes between Web sites after that. Rendering processes are highly restricted as to what they can and can't do. On Windows Vista, Chrome's rendering processes run with low integrity, much like Internet Explorer in Protected Mode. But Chrome actually uses Vista's mandatory integrity controls more securely than Microsoft does. For one, Chrome attempts to prevent low-integrity browser processes from reading high-integrity resources, which is not normally prevented. (By default, Vista prevents lower to higher modifications, but not reads.)

Both the browser kernel and rendering processes run with DEP (Data Execution Prevention) and ASLR (Address Space Layout Representation) enabled, and with virtualization disabled. Any supplementary browser add-ons are run in a separate, medium-integrity (or higher-integrity) process. This screen image shows the various browser processes and their security settings, as enumerated by Process Explorer on Windows Vista. Chrome even has its own Task Manager and internal page to show memory and CPU statistics. With respect to the base security model, Chrome is leading the pack. It's beautiful.

Interesting innovations

A slightly questionable choice is Google's decision to allow Chrome to be installed without requiring Administrator-level access. This can make Chrome installs difficult to manage in an enterprise environment, but Microsoft is encouraging this sort of behavior in all vendors (to prevent Windows system modifications). Chrome is just one of the first major apps to follow Microsoft's advice.

Chrome also installs the Googleupdate.exe application, scheduled to run automatically in Windows Vista Task Scheduler, which frequently dials home (although only when the user is logged on and the computer is idle) and checks for browser (and other Google application) updates, and silently installs them. This is a great way to keep the browser up to date (patches are currently applied more frequently than once a week), but it riles many security administrators because there is no notification of the outward-bound search, no notification of pending patches, and no approval requested for patches to be applied; plus, this behavior cannot be easily changed.

Another interesting concept is Chrome's virtual JavaScript machine, called V8. Google's Chromium team built its own virtual environment for all JavaScript execution. V8 even converts JavaScript code into native machine language (to speed up Web-page loading) and has its own memory garbage-collection processes, source-code inspector, and debugger. V8 significantly limits what can be accomplished by JavaScript against the user's system, including preventing the normal JavaScript pop-ups. In testing, Chrome did pretty well against pop-up ads but suffered from UI problems and slowness on some of the JavaScript modal tests.

Chrome has many standard security features, including a browser-session privacy mode (called Incognito); anti-phishing capability (called Google Chrome's Safe Browsing); one-button setting resets; forced file saves before launching; moniker handling (which helps thwart attempts to fool the browser into launching helper applications that can be exploited); and MIME content-type sniffing (which helps thwart attempts to fool the browser into downloading malicious content). Chrome actually has many more security features that I could go on about; so far, so good.

Questionable controls

But then reality hits hard. One of the most glaring lapses is the inability to disable JavaScript. Because JavaScript is involved with most malicious Web attacks, all of Google's competitors allow its use to be disabled globally, or per site or per zone (albeit Firefox requires a third-party add-on, NoScript, to be site-specific). The world has yet to create a virtual machine that was not able to be breached, so despite all the cleverness that went into V8, I cannot understand how Google committed such an oversight, even if the company is trying to promote JavaScript-enriched applications and sites. If a large JavaScript exploit happens against Chrome -- or rather, when it happens -- the only recommendation Google will be able to offer, it seems, is to stop using it.

Most user-selectable security settings are under an option tab called Under the Hood. It's when you first go here that you realize how little Chrome offers in the way of fine-grained security settings. The options are very sparse and often lack a secure default. For example, all cookie types (both first- and third-party) are allowed by default. This isn't surprising for a company that makes its living from ads. But even the third-party-cookie restricted mode allows the reading of any third-party cookie, which is almost as bad as allowing modifications. In another example of a poor default, HTTP data is allowed to commingle with HTTPS data in the same view, without warning to the user.

Another critical security feature that's missing is the ability to place different Web sites into separate security zones or domains. Most browsers provide at least two zones (Internet Explorer has five) or the binary ability to whitelist or blacklist sites. Chrome is also glaringly absent of enterprise management features. SSL/TLS (Secure Sockets Layer/Transport Layer Security) server revocation checking is enabled by default, but Chrome does not support the more efficient OCSP (Online Certificate Status Protocol) revocation-checking protocol, though all of its competitors do.

Google has also washed its hands of responsibility for the security of add-ons. Reviewers are very mixed on this approach. While it is true that browser vendors should not be ultimately held responsible for others' add-ons and applications, Chrome offers no add-on management. You cannot easily determine which add-ons will render particular content, nor easily disable them.

Many users are perturbed by the treatment of their own saved passwords. Chrome allows the current user to reveal the saved log-on names and passwords in plaintext with a few clicks of the mouse. This is convenient for the user -- and for anyone else who wants to learn all of the user's passwords and finds the computer left unattended for a few seconds. Internet Explorer doesn't allow this at all, and Firefox and Opera at least have the ability to assign another password to protect the saved passwords. On the Password Manager Evaluator testing Web site, Chrome scored the worst among all of the browsers I've tested (including Firefox, Internet Explorer, Opera, and Safari), passing only 4 of 21 tests.