Chrome's multi-process architecture provides many benefits for speed, stability, and security. It allows web pages in unrelated tabs to run in parallel, and it allows users to continue using the browser and other tabs when a renderer process crashes. Because the renderer processes don't require direct access to disk, network, or devices, Chrome can also run them inside a restricted sandbox. This limits the damage that an attacker can cause if he exploits a vulnerability in the renderer, including making it difficult for the attacker to access the user's filesystem or devices, as well as privileged pages (e.g., settings or extensions) and pages in other profiles (e.g., Incognito mode).
However, there is still a large opportunity to use Chrome's sandbox for greater security benefits: isolating web sites from each other. Chrome currently makes an effort to place pages from different web sites in different renderer processes when possible, but due to compatibility constraints, there are many cases in which pages from different sites share a process (e.g., cross-site iframes). In these cases, we rely on the renderer process to enforce the Same Origin Policy and keep web sites isolated from each other.
This page describes our "site isolation" efforts to improve Chrome to use renderer processes as a security boundary between web sites, even in the presence of Blink vulnerabilities. Our goal is to add support for a "site-per-process" policy that ensures certain renderer processes contains pages from at most one web site. The browser process can then give renderer processes limited access to cookies and other resources, based on which web sites have dedicated processes.
For the "site-per-process" security policy, we assume that an attacker can convince the user to visit a page that exploits a vulnerability in the renderer process, allowing the attacker to run arbitrary code within the sandbox. We consider attackers that want to steal information or abuse privileges granted to other web sites.
Here, we use a precise definition for a site that we use as a principal: a page's site includes the scheme and registered domain name, including the public suffix, but ignoring subdomains, port, or path. We use sites instead of origins to avoid breaking compatibility with existing web pages that might modify their document.domain to communicate across subdomains.
We consider the following threats in scope for the proposed policy:
We do not expect this policy to mitigate traditional cross-site attacks or attacks that occur within the page of a victim site, such as XSS, CSRF, XSSI, or clickjacking.
To support a site-per-process policy in a multi-process web browser, we need to identify the smallest unit that cannot be split across renderer processes. This is not actually a single page, but rather a group of documents from the same web site that have references to each other. Such documents have full script access to each other's content, and they must run on a single thread, not concurrently. This group may span multiple frames or tabs, and they may come from multiple sub-domains of the same site.
The HTML spec refers to this group as a "unit of related similar-origin browsing contexts." In Chrome, we refer to this as a SiteInstance. All of the documents within a SiteInstance are allowed to script each other, and we must thus render them in the same process.
Note that a single tab might be navigated from one web site to another, and thus it may show different SiteInstances at different times. To support a site-per-process policy, a browser must be able to swap between renderer processes for these navigations.
In addition, top-level documents may contain iframes from different web sites. These iframes have their own security context and must be rendered in a process based on their own site, not the site of their parent frame.
As described on our Process Models page, there are currently several cases in which Chrome will place documents from different sites in the same renderer process. This keeps Chrome compatible with documents that make script calls across windows, at least until the project tasks described below are completed. Some examples of cross-site pages that may share a process:
As a result of this progress, we have adopted a stricter security policy for certain types of pages, such privileged WebUI pages (like the Settings page). These pages are never allowed to share a process with regular web pages, even when navigating in a single tab. This is generally acceptable from a compatibility perspective because no scripting is expected between normal pages and WebUI pages, and because these can never be loaded in subframes of unprivileged pages.
To support a site-per-process policy in Chrome, we need to complete the tasks outlined below. These will ensure that cross-site navigations and script interactions will not break, despite having all pages from different sites in different processes. The master tracking bug is https://crbug.com/467770.
Monitoring the performance impact of Site Isolation on Chrome is a critical part of this effort. Site Isolation may affect performance in several ways, both positive and negative: some frames may render faster by running in parallel with the rest of the page, but creating additional renderer processes also increases memory requirements and may introduce latency on cross-process navigations. We are taking several steps to minimize the costs incurred, and we will use performance monitoring infrastructure to measure these costs.
As mentioned above under "Renderer Process Limit Policy," one of the primary tradeoffs we are making is that we will isolate only a subset of web sites. Most web sites will continue to use Chrome's current process model, while web sites that users are likely to log into will be isolated. This means that the vast majority of iframes will not require separate renderer processes. We also plan to reuse renderer processes for a given site across many iframes, reducing the number of processes required.
For monitoring our performance impact, we are using the Telemetry framework for Chrome. We plan to run existing benchmarks over both new and existing page sets, with and without the --site-per-process flag. This will allow us to compare metrics like page load time and memory usage with and without out-of-process iframes.
Status: The "page_cycler_oopif.typical_25" benchmark in page_cycler.py runs PageCycler over a set of 25 typical pages, and can be compared against the "page_cycler.typical_25" results. However, the OOPIF version of the benchmark is currently disabled due to crashes when visiting these pages, as tracked in https://crbug.com/463346.
For users eager to try site isolation before it is enabled by default, we have added two experimental command-line flags.
First, the --site-per-process flag starts to enforce the security policy described in this document. With this flag, Chrome 41 supports painting and simple input events for out-of-process iframes (such as this test page: http://csreis.github.io/tests/cross-site-iframe.html). This mode should only be used for experimentation and not normal browsing, as crashes are highly likely.
Second, the simpler --enable-strict-site-isolation flag forces a process swap on all cross-site navigations, even if this might disrupt valid script calls on some web sites. This mode also blocks access to cross-site cookies (unlike --site-per-process), which may cause compatibility issues with many web sites. Cross-origin iframes remain in their parent process, but because of cross-site cookie blocking, such pages are unauthenticated. This mode is effectively usable on most web sites today.
Updating Chrome Features:
Talks and discussion from January 2015.
The mailing list for technical discussions on Site Isolation is email@example.com.