In the last ten years the web has evolved from a set of interconnected static pages to a system of complex, distributed applications and active content. Traditional browsers are no more appropriate tools to handle such contents and many security issues have arisen from the usage of tools designed to handle traditional types of content.
Insufficient studies have been accomplished to surf the new contents of the Internet, referring to dynamic and potentially malicious applications.
Internet browsers have become the most used application for common operations like media streaming, social networking, chatting or bank transactions. The integration with plugins and external applets and the support of real programming languages like Javascript, C# or Java, let traditional browsers grow in terms of complexity and type of achievable operations. Thereby, this high complexity has come with several security issues, allowing potential attackers and malicious web sites to compromise the overall system during the execution of a browser instance.
Monolithic browsers are mainly affected by these issues, since a vulnerability can be exploited to attack the local operating system. There is no isolation mechanism among browser components and an attack coming from one of the running components can affect all the others. A crash of the Javascript engine, for instance, might crash the whole application. A traditional approach in designing web browsers may therefore lead to high severity vulnerabilities. Designing a new generation browser only to achieve the highest performance, underestimating the security issues is not considered a smart choice nowadays.

Because web browsers have become really complex applications, there might be several critical points, potential targets for attackers: the rendering engine, the Javascript interpreter, or any other browser supported language, external plugins, etc.., are all interesting spots to search for vulnerabilities to exploit.
It seems that the current browser war is all focused on cranking out the fastest browser, the one which eats 3D rendering for breakfast or completes the pure Javascript benchmark in 10ms less than its direct competitor.
When it comes to (almost) the only application to surf the web and communicate to people, thinking about security is a must (well, it should be). Whereas an application run locally could be designed to achieve great performances at the expense of security (relatively important for an application that will not connect to anyone and cannot serve requests), the Internet browser cannot be designed with such requirements at all.
The monolithic approach, eg. Mozilla Firefox, Safari, IE, is not suitable to overcome the security issues described above, since it is hard to isolate components with a straightforward design. A vulnerability discovered in the HTML parser or in the Javascript engine, would compromise the whole system. In the monolithic browser each component is executed in the same address space of any other.
The most effective design to solve such issues consists in isolating each component by sandboxing processes and/or creating different processes to execute in different address spaces. The birth of modular browsers characterized by an interesting architecture design to reduce common browser attacks, seems to be the right direction.
A hard technical difficulty is represented by backward compatibility with existent complex web sites. All processes contributing to view the web page and let the user surf interactively need a way to communicate to each other (this is normally provided by Inter Process Communication mechanisms, IPC).
Another quality factor is represented by performance. In a multiprocess browser, IPC comes with a cost. In a realistic scenario, a page composed by HTML code, embedded Javascript and some Flash, needs at least three processes to be rendered.

Google Chrome is currently the most promising solution in terms of security (and performances). Chrome is a browser specifically designed to reduce the security issues that may affect a web browser (eg. remote code execution, exploit of vulnerabilities in the Javascript engine, etc…). Chrome is designed to achieve a clear isolation between a browser kernel and a rendering engine. The former, is considered a trusted code component, is responsible to draw interfaces, save cookies, allow access to network and to the local file system. The rendering engine is the second main component to parse HTML code, interpret Javascript/DOM and execute in a virtual machine, decode images, fill in the screen buffer. All these operations are sandboxed in order to maintain a good level of security also when a vulnerability in one of those components is found and exploited.
Unfortunately, sandbox is an Operating System dependent component. Thus portability is another issue to deal with. For instance, processes in Linux can be sandboxed by AppArmor or other techniques, whereas Mac OS X provides an operating system sandbox which is clearly different from the one provided by Microsoft Windows.
Attempting the direction of Operating System development could be an easy way to avoid the technical problem of portability.
In a modular browser each rendering engine must be executed by a different process. In such an architecture an attack coming from site A wouldn’t have any effect on the process in which the rendering engine of site B is running. How to separate processes is still an open problem and more studies are needed. Separation can be achieved at Tab, web page or address level (Same-Origin policy) or any other well-advised policy.
A tradeoff between backward compatibility and the degree of security to guarantee, need to be taken into account. Although, when it comes to security this is a difficult goal to reach.
Google measures performance and security of its new browser with a method far away to be appropriate. In [1] they report that Chrome mitigates about 70% of critical vulnerabilities other browsers are affected. This is clearly an insufficient metric since there would be the “big one” vulnerability leading to a disaster (if exploited), in the remaining 30%.
Although Google Chrome is considered the most promising architecture in comparison to what the market of browsers is offering nowadays, it is still affected by some limitations, both in the implementation and design.
Limitations in the implementation must be considered solvable in further mature versions of the browser. But limitations in the design should be considered a critical path to work on at once.
A critical problem is represented by plugins that require to be executed in the browser kernel, since they need to access operating system resources directly. In this specific scenario the crash of one plugin would lead to crash the overall system. In case plugins were executed in the rendering engine, creating new instances would lead to compatibility issues for all those plugins that require at most one running instance.
Another implementation issue prevents a sandboxed process from opening network sockets directly. Thus all sockets are opened by the browser kernel, exposing it to potentially exploitable vulnerabilities.

Peacekeeper benchmark results

Some results from Peacekeeper benchmark suite are reported here. Google Chrome is not the fastest browser as they claim. The multiprocess architecture comes with a cost, specially on mashups. Great results only on text parsing.
Google Chrome seems to be highly operating system dependent. The following results have been collected from Peacekeeper benchmarks on Mac OS X and Windows XP.

Mac OSX

Test	Safari 4	FF3.5.1	Chrome 3.0.192
Rendering	1220	1772	777
Social Networking	1543	1583	514
Complex Graphics	1021	2576	1454
Data	2920	1910	1398
DOM operations	3302	1073	1482
Text parsing	3031	1172	3332

Windows XP SP2

Test	Safari 4	FF3.5.1	Chrome 2.0.172
Rendering	882	1674	889
Social Networking	1030	1433	897
Complex Graphics	1533	2029	2610
Data	2401	1895	1504
DOM operations	2037	835	1094
Text parsing	2047	1141	2413

(the higher the better)

---

Designing an operating system and running new generation browsers on top of it may help in solving many of the issues described above. The difficulty indeed is to integrate new generation browser designs with traditional operating systems.
The idea of designing a browser tailored operating system (and not the reverse as can be thought) is not new: Tahoma [2] offers a virtualization architecture to isolate web applications and browser instances.
The concepts come from three main assumptions:

• Web applications should not be trusted, thus contained within appropriate sandboxes to mitigate damages to the operating system.
• Web browsers should not be trusted since they’ve become more complex and prone to bugs. Thus they should be isolated from the rest of the system.
• Users should control and manage downloaded web applications possibly having a list of web services to which the local applications could connect.

The architecture offered by Tahoma consists in defining a browser operating system (BOS) and executing special implementations of existent browsers as Netscape or Internet Explorer, on top of it.
The BOS limits the set of web services each application is permitted to connect to, throughout white lists and security policies. Each browser instance is executed within a virtual machine which provides access to hardware resources to share with other running virtual machines.
The isolation guaranteed by a virtualization environment is much stronger than the one provided by a multiprocess architecture. This higher level of security comes with a cost.
I believe that since there are no defined metrics to assess the performances of an application with respect to the level of security its implementation provides, poorer performances should be absolutely acceptable in all those cases where a high degree of security is guaranteed by the method.
Normally, people think about performance as the number of operations perceived by the final user in the time unit. Unfortunately, for an application that guarantees the maximum degree of security this is not a correct metric anymore.
A browser instance running in the Tahoma architecture for the first time requires a huge amount of operations to set a secure environment: a new virtual machine is created on the fly, a guest operating system is booted, browser code and data are installed, a browser instance is finally executed. The architecture is exactly the same proposed by Xen Virtual Machine Monitor, VMM. All applications are executing in virtual machines booted on top of the Virtual Machine Monitor.
The cost of virtualization is usually high. A browser cold start occurs in about 10 seconds (Intel P4 3,0GHz, 1GB RAM, Linux Kernel 2.6.10) against 5 seconds on a native Linux.

When it comes to security it is already hard to find the optimal tradeoff with performance. When it comes to browser security it seems to be even worse, since the Web Browser is the most used application and the way people use computers is definitely being revolutionized.

References

[1] The Security Architecture of the Chromium Browser
Adam Barth, Collin Jackson, Charles Reis, and The Google Chrome Team
Technical Report 2008

[2]A safety-oriented platform for web applications
Richard S. Cox, Steven D. Gribble, Henry M. Levy, Jacob Gorm Hansen