ware.org have tools to help publishers remove their pages from the database if they have been cleaned after hosting malware. It is also possible for human errors to flag sites incorrectly, as in an incident in January 2009 that flagged all URLs as dangerous. 9 Such errors are typically fixed quickly, though, and safeguards can be added to prevent them from recurring.

These services also have false negatives, because not every malicious page on the Web can be cataloged at every point in time. Although Google and StopBadware.org attempt to identify as many malicious pages as possible, 10 it is unlikely to be a complete list. Still, these blacklists help protect users from attack.

conclusion

There is no silver bullet for providing a perfectly secure browser, but there are several techniques that browser developers can use to help protect users. Each of these techniques has its own set of challenges.

In particular, browsers should minimize the danger that users face using three techniques:

Reduce attack severity by applying ˲ the principle of least privilege in the browser architecture. This technique limits the damage caused when an attacker exploits a vulnerability.

Reduce the window of vulnerabil- ˲ ity by ensuring updates are developed and deployed as quickly as possible. This technique minimizes the number of vulnerable browsers an attacker can target.

Reduce ho w often users are exposed ˲ to attacks by filtering out known malicious content. This technique protects users during vulnerable time windows.

The Google Chrome team has focused on each of these factors to help provide a secure browser while preserving compatibility with existing Web content. To make Google Chrome even more secure, we are investigating further improvements to the browser’s security architecture, such as mitigating the damage that plug-in exploits can cause and more thoroughly isolating different Web sites using separate sandboxed processes. Ultimately, our goal is to raise the bar high enough to deter attackers from targeting the browser.

There is no silver
bullet for providing
a perfectly secure
browser, but
there are several
techniques that
browser developers
can use to help
protect users.

Related articles on queue.acm.org

Security in the Browser

Thomas Wadlow and Vlad Gorelik

http://queue.acm.org/detail.cfm?id=1516164

Cybercrime 2.0: When the Cloud Turns Dark

Niels Provos, Moheeb Abu Rajab, and Panayiotis Mavrommatis

http://queue.acm.org/detail.cfm?id=1483106

Phishing for Solutions

Kode Vicious

http://queue.acm.org/detail.cfm?id=1142063

References

1. barth, a., Jackson, C., reis, C., and Google Chrome team. the security architecture of the Chromium browser (2008); http://crypto.stanford.edu/websec/ chromium/chromium-security-architecture.pdf.

2. Douceur, J.r., elson, J., howell, J., and lorch, J.r. leveraging legacy code to deploy desktop applications on the Web. In Proceedings of Operating Systems Design and Implementation (2008).

3. Duebendorfer, t., frei, s. Why silent updates boost security. eth tech report tIk 302 (2009); http:// www.techzoom.net/silent-updates.

4. franco, r. Clarifying low-rights Ie. Ieblog (June 2005); http://blogs.msdn.com/ie/archive/2005/06/09/427410. aspx.

5. frei, s., Duebendorfer, t., and Plattner, b. firefox (in) security update dynamics exposed. ACM SIGCOMM Computer Communication Review 39, 1 (2009).

6. Google. omaha: software installer and auto-updater for Windows. Google Code; http://code.google.com/p/omaha/.

7. Grier, C., tang, s., and king, s.t. secure Web browsing with the oP Web browser. In Proceedings of IEEE Symposium on Security and Privacy (2008).

8. howard, M., thomlinson, M. Windows Vista IsV security (2007); http://msdn.microsoft.com/en-us/ library/ bb430720.aspx.

9. Mayer, M. “this site may harm your computer” on every search result. the official Google blog (Jan. 2009); http://googleblog.blogspot.com/2009/01/this- site-may-harm-your-computer-on.html.

10. Provos, n., Mcnamee, D., Mavrommatis, P., Wang, k., and Modadugu, n. the ghost in the browser: analysis of Web-based malware. In Proceedings of the First Usenix Workshop on Hot Topics in Botnets (april 2007).

11. reis, C. and Gribble, s.D. Isolating Web programs in modern browser architectures. In Proceedings of European Conference on Computer Systems (april 2009).

12. sandbox. Chromium Developer Documentation (2008); http://dev.chromium.org/developers/design-documents/sandbox.

13. Wang, h. J., Grier, C., Moshchuk, a., king, s.t., Choudhury, P., and Venter, h. the Multi-Principal os Construction of the Gazelle Web browser. Microsoft research technical report (Msr-tr-2009-16) 2009; http://research.microsoft.com/pubs/79655/gazelle.pdf.

14. yee, b., sehr, D., Dardyk, G., Chen, J. b., Muth, r., ormandy, t., okasaka, s., narul, n., and fullagar, n. native Client: a sandbox for portable, untrusted x86 native code. In Proceedings of IEEE Symposium on Security and Privacy (2009)

Charles Reis is a software engineer at Google working on the Google Chrome Web browser. he recently completed his Ph. D. in the Department of Computer science and engineering at the university of Washington. his research focuses on improving the reliability and security of Web browsers and Web content. Adam Barth is a postdoctoral fellow at the university of California, berkeley. his research focuses on the security of modern Web browsers, including their security policies, enforcement mechanisms, and security user interfaces. he is a contributor to the Chromium, Webkit, and firefox open source projects and is an invited expert to the W3C htMl and Web applications working groups. Carlos Pizano is a senior software engineer at Google working on the Google Chrome Web browser. his work focuses on security and sandboxing for Internet-facing applications.