X
Tech

Google expands Chrome's Site Isolation feature to Android users

Google also expands Site Isolation protections for desktop users.
Written by Catalin Cimpanu, Contributor
chrome-security-5c51bfbe60b25418cca7e783-1-jan-30-2019-18-18-36-poster.jpg

Google Chrome's Site Isolation security feature is now also available in a limited fashion on Android devices.

If Chrome for Android users visit a site where they enter passwords, Chrome will isolate that site from all the other tabs in a separate Android process, keeping the user's data safe from Spectre-like attacks, Google said today.

Furthermore, Site Isolation, which has been available for desktop users since July 2018, has also been expanded for Windows, Mac, Linux, and Chrome OS users, which now receive protection against more attacks than the original Meltdown and Spectre vulnerabilities.

What is Site Isolation?

Site Isolation is a Chrome security feature that Google started developing as a way to isolate each website from one another, so malicious code running on one site/tab couldn't steal data from other websites/tabs.

Site Isolation was developed to act as a second layer of protection on top of Same Origin Policy (SOP), a browser feature that prevents websites from accessing each other's data. Google developed Site Isolation because browser bugs often allowed sites to jump the SOP barrier and steal user data stored in the browser, created by other sites.

Chrome engineers started work on Site Isolation in 2017 and rolled out the feature to all desktop users with the release of Chrome 67 in May 2018, reaching 99% coverage by July 2018.

At the time, Google called Site Isolation a triumph despite Site Isolation not working at its full potential.

The feature's rollout came just in time to provide protections against side-channel attacks like Meltdown and Spectre -- two vulnerabilities that impacted CPUs, disclosed in early 2018, and which could allow attackers to jump the barrier between apps and steal data from Chrome.

While Site Isolation was never designed to stop CPU bugs, it did stop these types of issues; hence the reason Google opted to roll it out, even if it wasn't exactly how it originally envisioned Site Isolation to work.

But behind the scenes, work on Site Isolation continued after July 2018, with Google engineers building Site Isolation into the comprehensive security feature they originally wanted to create. Today, Google announced two major developements, along with future Site Isolation plans.

Site Isolation to roll out for some Android users

The first of these is that Site Isolation is now available for some Android users.

Google said today it enabled Site Isolation for 99% of the Chrome Android userbase that has a smartphone with 2GB or more of RAM.

On these devices, when users visit a site where they enter passwords, Chrome will spin that site into its own process, to protect the site and the user's data from Spectre-like malicious code running on other sites.

Site Isolation was added in Chrome for Android v77, released last month in September. Users who updated to this version and have a phone with more than 2GB of RAM have the feature enabled already.

When enabled, Google said it expects the Site Isolation feature to incur a 3-5% increase in memory usage.

Chrome Android users who don't own a device with enough memory, or users who want to use Site Isolation on all sites (not just those where they enter passwords), can visit the chrome://flags/#enable-site-per-process to enable Site Isolation at all times. However, Google said that this would also incur even a higher RAM overhead, of which users should be aware.

Protection against more attacks on desktop

But while Site Isolation is taking its first steps on smartphones, the feature is expanding on desktops.

According to Google, starting with Chrome 77 released last month, Site Isolation on desktops can protect users against more exploit types than the original support for side-channel (Spectre-like) attacks.

"Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process," Google engineers said today. "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."

Memory bugs and UXSS vulnerabilities have been used in the past. Attackers usually placed malicious code on sites that exploited these types of vulnerabilities. When a user accessed the malicious site, the exploit code would trigger, and extract data from other sites that had been stored inside Chrome.

Now that Site Isolation was expanded to detect and stop such attacks, Google says this won't be possible anymore, as each site's data (such as cookies and passwords) will be site-locked, and moved in a separate Chrome process altogether.

Memory and UXSS bugs that could bypass SOP won't be useful anymore. If hackers want to steal browser data, they'll need exploits that can escape the Chrome sandbox and jump to another OS process.

Furthermore, Site Isolation also prevents access to more data types, and not just passwords and cookies. Per Google, these are the user data categories that Site Isolation can now safeguard from malicious code:

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

Future plans

But Site Isolation still has a lot of room to expand before actual "site isolation" is achieved, at all levels of the Chrome codebase. The optimum scenario will be when each site runs in its own process and they can access only their own data.

This is not yet possible in Chrome because of Chrome's current architecture -- but this will change in the future.

Here are Google's future plans for Site Isolation:

  • Bringing these protections to Chrome for Android. This requires extra work to handle the case where only certain sites are isolated.
  • Protecting CSRF defenses. Sec-Fetch-Site and Origin request headers can be verified to prevent compromised renderers from forging them.
  • Protecting more types of data. We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
  • Removing exceptions. We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts, until they update to the new security model. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as harden other extension security issues. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a deprecation path.

All the Chromium-based browsers

Editorial standards