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.
[Tomorrow: "How secure is Mozilla Firefox?" For more on browser security and protection against Web-borne threats, see Security Adviser and " Test Center: Browser security tools versus the evil Web." ]
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.)