The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.
For Developers‎ > ‎Design Documents‎ > ‎

Isolated Sites

Motivation

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.

How it works

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).

When you perform a top-level navigation to an isolated site, it will behave as if you are visiting it from a separate browser. Any state that would be used for browsing (cookie store, cache, localstorage, etc.) will not be shared with your normal browsing session.  This includes any subresource loads, subframes, or javascript XHR calls.  A dedicated renderer processes are used as well, so that any in-memory state is also isolated from your normal browsing session. This helps shield the isolated app from most known cross-origin attacks, from reflected XSS to full WebKit exploits.

As an example, suppose you have designated http://isolatedsite.com to be isolated and that http://isolatedsite.com serves the following HTML:

  <html><body><iframe src="http://thirdparty.com"></iframe></body></head>

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.

Requirements

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:
  • Cookies and Cache (via URLRequestContext)
  • HTML5 Storage (via DomStorage)
  • IndexDB (via IndexDBContext)
  • Filesystem access (via FileSystemContext)
  • AppCache access (via AppCacheService)
  • QuotaManager access (via QuotaManager)
  • DatabaseTracker access (via DataBaseTracker)
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.

Current State

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:
  1. Behavior when a site is "unisolated"
  2. UI and/or extension API for managing isolated sites.
  3. Behavior of general settings with respect to isolated partitions.  For instance, if you list and/or clear all cookies, what should happen?
  4. Behavior of session restore with respect to isolated partitions.
Comments