2. It has to be built like a platform, not like a singular application. Once upon a time, the Web was a series of static pages, and the Web browser was an application that let you find and view those static pages. Times have changed, however, and now the browser itself plays host to many rich, Web-based applications. Thus, browser development should be treated more like operating system development. Some browsers -- Google Chrome, principally -- are beginning to make strides in this direction. (As my fellow CSIers, Kristen Romonovich and Robert Richardson, said from the get-go, Chrome is more a Windows competitor than it is an Internet Explorer competitor.)
3. It needs a modular -- not monolithic -- architecture. In a modular architecture, the browser is divided into at least two components -- generally speaking, one that interacts with the client machine, and one that interacts with the Web and operates from within a sandbox. The main benefit is that it's a great defense against drive-by malware downloads. If an attacker compromises the Web-facing component of the browser, they won't automatically gain full access to the client machine with user privileges. They'll only gain access/privileges to whatever the Web-facing component needs. Internet Explorer 8 (beta) and Google Chrome (beta) use modular architectures. The OP Browser still in development by researchers at the University of Illinois uses a more granular modular architecture that splits the browser into five components.
Yet monolithic architectures are used by all the major browsers today. (Monolithic architectures are kind of like real-estate brokers who represent both the buyer and the seller -- you just can't quite trust them.)
4. It has to support some sort of process isolation. In essence, isolating processes means that when one site/ object / plug-in crashes, it doesn't crash the entire browser.
The troubles with plug-ins are that they tend to run as one instance, so process isolation doesn't really work with them -- they're given unchecked access to all the browser's innards, and they tend to assume/require the user's full privileges. In order to allow plug-ins to run properly, Chromium (the modular, open-source Web browser architecture used by Google Chrome) runs them outside of the sandbox, and with the user's full privileges -- so the browser can't do anything to save the user's machine from malicious downloads through an exploited plug-in.
I'm still thinking some of this through, so do let me know if you disagree, see errors in my judgment, or think something else should be on this list.
Also: Should one browser be expected to do everything? How likely are you (and your users) to use one browser for everyday activities and another browser for more delicate activities?
We'll be devoting the next issue of the Alert -- CSI's members-only publication -- to browsers and other elements of client-side Web security issues. We'll also be discussing some of them during the CSI 2008 conference next month. On Tuesday, Nov. 18, Gunter Ollmann of IBM-ISS will present a full 60-minute session on "Man-in-the-Browser Attacks," and, also on Tuesday, browser security will be discussed during the Web 2.0 Security Summit, moderated by Jeremiah Grossman (CTO, WhiteHat Security) and Tara Kissoon (Director of Information Security Services at Visa Inc.).