Google has improved the Site Isokation feature in the Chrome Chrome 77 web browser for Android and desktop.

Gogole launched Site Isolation in Chrome last year as a way to secure desktop browsers against the risk of side-channel attacks like Spectre. Today, Google announced further improvements that have rolled out in Chrome 77:

• Chrome for Android has enabled Site Isolation for sites where users enter passwords.
• On desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.

Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.
Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.

Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming "out-of-process iframes." Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.

Google says that for the most part, Site Isolation should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads.

In the future, Google plans to add support for more ways of detecting when a site should be protected by Site Isolation. For example, Google is working on allowing website operators to opt in any site to Site Isolation, without requiring user login.

On desktop platforms, Site Isolation in Chrome 77 now helps defend against stronger attacks. The initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.

For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.

In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:

• Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
• Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome's network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
• Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process's site lock.
  
• Cross-origin messaging: Chrome's browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.