|
Whenever Google does something new, it's big news, and the release of its own browser, Chrome, was no exception. As browsers are now the most common application interface, its security is a key feature and a critical factor in the search engine giant's success.
To enforce the principle of least privilege, Google has used a modular architecture for Chrome, with two major components running in different operating-system processes: a high-privilege browser kernel and a low-privilege sandboxed rendering engine. The sandbox aims to prevent the rendering engine from interacting with other processes and the user's operating system. The arrangement limits the damage that can be caused by an attacker who exploits a vulnerability in the rendering engine.
One of the major challenges for any browser's security architecture is maintaining compatibility with existing Web content. Google Chrome must support plug-ins, such as Flash Player and Silverlight, but these plug-ins are not designed to run in a sandbox. They require direct access to the operating system and peripherals, such as the user's webcam and microphone. This means Chrome can't currently run them in a sandbox. Compatibility challenges also exist when trying to enforce the same-origin policy, which isolates websites from each other. Chrome has to sometimes place pages from different origins in the same process.
Several of Google Chrome security features for Windows, have been introduced in recent versions of Microsoft's operating system, such as data execution prevention, address space layout randomization, safe exception handlers, heap corruption detection and stack overrun detection. However, Chrome's initial line of defense, like other browsers, is to check visited sites against antimalware and antiphishing blacklists, displaying a warning page if the site has been reported to StopBadware.org.
Elsewhere, Google has taken a non-intrusive approach to security. For example, Chrome automatically updates itself with minimal user interaction or disruption. This feature minimizes the length of time that users run unpatched versions of the browser and minimizes the number of vulnerable browsers an attacker can target.
Also, there is no Chrome equivalent to IE 8's cross-site scripting filtering mechanism or the NoScript Firefox plug-in that lets users choose which scripts on a site they want to run or block. Google feels that these features present confusing options that most users don't understand. Users therefore aren't given the option to turn off JavaScript; Chrome uses the sandbox option instead.
As you can see, Google has tried to make security simple for Chrome users, which is never an easy task as security is normally inverse to usability. But there are some areas where usability over security may have gone too far. By default, when there is secure and non-secure content on an SSL page, all content is loaded with no warning. Of more concern, is that automatic checking for server certificate revocation is not enabled by default -- this issue caused a problem recently for phones running Symbian's OS.
Right now, IE and Firefox are mature, fairly secure browsers while Chrome hasn't yet been thoroughly put to the test, so there's an argument for waiting for version 2.0. After that, unless Google comes up with something really new, I think your choice of browser from a security standpoint will come down to who is quickest and most effective at fixing any security vulnerabilities as they are found. Interestingly, Google has published the full source code for Chrome, possibly giving it the potential to be more secure than its closed-source counterparts as security researchers can spot and fix security vulnerabilities.
|
