Google announced with Google Chrome 77 launch that site insulation was delivered to Android and additional protectors were given to mobile users when this feature was activated.
Following the disclosure of the Meltdown and Speculative execution vulnerabilities, Google quickly tracked a security feature named Site Isolation so that it was activated for most Chrome 67 users.
When disabled, site isolation causes any website you visit to be loaded into its own sandboxing system to restrict what resources and functions it can access. This prevents malicious Web sites from exploiting speculative performance vulnerabilities to access data loaded from another browser tab by isolating sites in this way.
In the image below taken from Google’s Isolation: Separation system for websites within the browser file, you can see that the Isolation of website is extremely effective at reducing known vulnerabilities of Meltdown and Spectrum.
All good things come at a price, unfortunately. If Site Isolation is enabled, more processes are performed and more space is used. As you can see from the picture below, this leads to a large increase in memory usage at certain locations.
Site Isolation Memory Usage
This is a worthwhile balance, however, between security and resource use.
Android gets an isolation slow page
Once Chrome 77 was released for Ios, Google snuck secretly into Page Isolation to shield mobile users.
Contrary to the desktop implementation, Android Site Isolation covers only pages you log on with a password. It limits the use of power on mobile devices with less space and CPU than a desktop computer.
“We wanted to ensure that site isolation does not adversely affect user experience in an environment with limited resources like Android,” Google said in a new blog post today.
“This is why, unlike mobile platforms where we’re isolating all pages, Chrome uses a slender form of site insulation to cover fewer sites to retain overhead low. More precisely, website insulations are only enabled for value-added sites where users sign in with a password.”
It also uses a crowded list of sites common to mobile users to often enter passwords and allows the features for those sites.
This functionality is currently available for 99 percent of Android users with more than 2 GB of memory, with one percent reserved for device monitoring and performance improvement. Google hopes in the future to add additional apps.
For users that want full Site Isolation security to be allowed on all pages, they should turn on the chrome:/flag/#enable-site-per-process switch, but expect Chrome to use larger mobile device assets.
Google says they plan to expand the isolation feature on the mobile site to allow users to select other sites that they are interested in, even if they do not sign in.
Chrome 77 offers Additional Security for Mobile
In comparison to Chrome on Ios, Google Chrome used Site Isolation for all pages beginning at Chrome 67 when deactivated by default.
Chrome 77 provides greater security to desktop users as Site Isolation now defends users from corrupted rendering processes. These processes are responsible for and display what occurs in a tab, such as turning HTML, CSS and JavaScript into a web page.
Sadly, they are also the target of memory corruption bugs which could lead to a code running in another tab. Google prevents this type of malicious activity from occurring with this new site isolation mitigation.
“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.”
By introducing renderer protection to Chrome 77, Site Isolation protects users from a variety of threats by restricting access to browser-used information. This includes the following protections, most of which are added to Chrome 73.
- Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site. This protection was added in Chrome 73.
- Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, Microsoft Office, Open Office, 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.
Google hopes that these new safeguards will be added to Android later.
In addition to the current safeguards, Google plans, in future, to further safeguard CSRF defenses, further data types and migrate existing extensions so that wide cross-site access is not possible.
Improved Bug Bounties for Page Bugs
For a limited period of time, Google also increases bug bounty awards for site isolation bugs.
In-scope bugs eligible for awards include:
- Bugs that cause the same system to commit two or more cross-site web documents. i.e. pre-site insulation force behavior.
- Bugs that cause data to be revealed across sites even if the bug assumes a affected renderer.
- Site Isolation data: cookies, saved passwords, localStorage, IndexedDB, HTTP CORB or CORP resources.
