For browsing high value web sites (e.g., your bank account), Isolated Sites help provide stronger protection against cross-origin attacks, such as reflected XSS and CSRF. See this paper for more details: App Isolation: Get the Security of Multiple Browsers with Just One.
A user designates a set of URLs to be be an "isolated site." This can be done either via an extension API or via chrome://settings/content (still to be flushed out).
As an example, suppose you have designated http://isolatedsite.com to be isolated and that http://isolatedsite.com serves the following HTML:
During your browsing session, you directly visit http://thirdparty.com in a different tab and authenticate. Now Chrome has cookies for thirdparty.com in your general browsing session. However, within the isolated site, the http://thirdparty.com iframe on http://isolatedsite.com does not have access to those cookies, so you do not appear logged in. The iframe is loaded in the context of the isolated site, so it behaves as if it is on a different browser than your first tab. Conversely, any cookies set in the iframe inside the isolated site will remain attached only to the isolated site and not affect the state of the rest of the browser.
The browser process must create a partitioned view of the data based on the site that is requesting the data. This includes modifying at least the following objects to support partitioning the data:
For now, we are aiming to partition this data on a per-process basis. This may require Chrome to create a larger number of processes (rather than sharing processes when a limit is reached), but it is simpler than modifying WebKit to handle multiple storage contexts within a single renderer process.
Tracking bug here: http://crbug.com/69335
Cookies and Cache (excluding requests for media URLs) are already isolated.
HTML5 Storage is also isolated.
The rest are on track for m23.
Things that still need to be defined: