Tab Isolation

IEBlog

Windows Internet Explorer Engineering Team Blog

Tab Isolation

  • Comments 39

Tab isolation has recently become a more popular topic. This post is a quick survey of what tab isolation is, how it works, and what it provides.

What is it?

Tab isolation is a way to improve a browser’s reliability by containing the impact of a crash. Depending on how it’s implemented, tab isolation can also help contain some security attacks. There are two different implementations available today, each with different benefits.

In a tabbed browser without isolation, a problem in one tab can crash the entire browser. For example, a crash in a webpage in Firefox 3.6 or IE7 will bring down the entire browser. While modern browsers have features to recover tabs after a crash, the point of isolation is to contain the problem and prevent the browser from stopping. You can see a demo of this here (starting around 13:25). 

A Quick Historical Survey

On March 5, 2008, Microsoft released the first IE8 beta with Loosely-Coupled IE (or LCIE for short). This was the first mainstream implementation of tab isolation. On September 2, 2008, Google Chrome’s first beta released with “process isolation.” Mozilla Firefox has recently discussed an “Out of Process Plugins” (OOPP) or Electrolysis project aimed at isolating Firefox plug-ins, such as Flash, from the rest of the browser.

How do isolation approaches differ today in approach and benefits?

There are a lot of different subsystems in a browser to isolate from each other, and different ways to do it.

IE8 isolates the frame process (title bar, back button, address bar, etc.) from the tabs processes (that show web pages). If anything causes a site to crash (an extension like Flash, or the rendering or scripting engine, etc.), the frame and other tab processes will not crash. IE isolates the whole tab – all of its code, data, and extensions – to keep IE resilient to webpages with issues.

In addition to using multiple processes, IE8 on Windows 7 and Vista (and IE7 on Vista) sandboxes the tab processes in Protected Mode for security reasons. Specifically, tabs run without permissions to install software, modify settings, or change files of any user. Protected Mode provides defense in depth so that (in most cases) security vulnerabilities in the browser or an add-on (like Flash) cannot be exploited to harm the computer. Isolation makes this additional security possible. (Technically, there are several different types of isolation (process isolation, origin isolation, etc.), and of sandboxing (integrity levels, restricted subsets, DOM mirroring, etc.) as well.)

Chrome’s isolation is a bit different, factoring the different subsystems of that browser along different lines. From their documentation, they have separate processes for rendering, for the frame, and for add-ons (native plug-ins, not extensions). As with IE7, part of Chrome runs with lower privilege. Unlike IE (where page add-ons run in low), plugins in Chrome by default run with more privileges. As with any architectural difference, there are scenarios that are better in one architecture and worse in another. Theoretically, for example, a vulnerability in the Flash control running in Chrome does not have a defense in depth protection like Protected Mode to contain it.

Isolation is a super important part of modern browsers.  It’s essential for delivering a more reliable browsing experience. It can also improve security. Depending on how it’s engineered, it can also have an impact on compatibility with sites and browser extensions.

Andy Zeigler
Program Manager

  • Loading...