It's not about protecting the tabs from each other; when you separate the tasks into different containers, you can apply strong limits to what each can do, which makes it harder to "root the machine".

For example, see the Chromium docs: http://www.chromium.org/developers/design-documents/multi-pr...

I see, this is more about sandboxing the renderer. Not necessarily sandboxing the tabs. Right? Curious if one really required the other.

And, still, kind of amusing that the entire point of the browser is that it is sandboxed from the whole computer. Seems if we just restricted what the browser was capable of as a whole, we'd be there.

Trying to restrict the browser as a whole doesn't work for a couple reasons:

1. The browser as a whole needs to have permission to do quite a few things, including reading from and writing to the filesystem (for uploading and downloading files), talking to your system's graphical environment so it can display windows, and accessing arbitrary hosts on the network so it can access web servers. It's just not possible to meaningfully sandbox something requiring so much access. Individual browser components, on the other hand, can be designed to do very specific tasks and are thus easier to isolate.

2. You want to protect not only your system from a browser exploit but also other parts of the browser. A site that exploits a browser vulnerability shouldn't be able to read your cookies for another site.

These reasons imply that you need to focus on isolating and restricting components inside the browser instead of the browser as a whole.

Your last sentence is a better worded version of what I meant. That it is less that the tabs are isolated and sandboxed, and more that components of the browser are.

If you sandbox the whole browser, it can't actually do anything, including actually display the webpages or connecting to sites.

It is way harder to exploit a machine through a properly sandboxed process. Sandboxing restricts the process's access to filesystem and network. On Linux for example seccomp can restrict the number of system calls the process can make which further reduces the attack surface greatly. So to exploit a OS vulnerability through a sandboxed process you also need to exploit a vulnerability in sandboxing itself. That's significant.