Last year, Google deployed Site Isolation in desktop versions of its Chrome browser as a defense against CPU side-channel attacks like Spectre. The technique renders websites in separate processes to prevent one from interfering with or snooping on another, augmenting browser sandboxing defenses.
On Thursday this week, the Chocolate Factory said it has activated the security mechanism in the Android version of Chrome 77, which debuted last month. The ad biz also extended Site Isolation defenses to protect against fully compromised renderer processes and universal cross-site scripting bugs on desktop versions of Chrome.
The Site Isolation in Android comes with some qualifications because the technique imposes memory overhead of about 3 to 5 per cent. So mobile devices must have at least 2GB of RAM to use Site Isolation, and even then, the defense is only activated when visiting websites with a login mechanism and only for 99 per cent of Chrome for Android users – 1 per cent of devices are excluded to provide a monitoring and performance baseline.
“Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation,” said Google software engineers Alex Moshchuk and Łukasz Anforowicz in a blog post. “That means the site will be rendered in its own dedicated renderer process, walled off from other sites.”
Users not content with devoting such a small portion of memory to better security can set a flag (via
chrome://flags/#enable-site-per-proces) to activate Site Isolation for all sites, not just sites with login forms.
Doing so is likely to bring Chrome for Android closer to desktop Chrome levels of memory overhead – 10 per cent to 13 per cent, as tested on Chrome 67, when Site Isolation is applied to many browser tabs.
Nix to the mix: Chrome to block passive HTTP content swirled into HTTPS pages
The desktop versions of Chrome have been beefed up to do more than just prevent data leakage from a render process. Site Isolation in desktop Chrome can now defend effectively even if an attacker is able to exploit a memory corruption bug in Chrome’s rendering engine, Blink.
It’s able to do so because Chrome’s browser process can identify the website associated with a given render process and can limit the cookies, passwords, and site data available, thereby preventing cross-site data grabs.
And that’s for the best. As Google observes, bugs in Chrome’s Blink engine turn up regularly, despite considerable efforts to avoid them, including fuzzing, bug bounty programs, and developer education. There were 10 potentially exploitable bugs in renderer components in Chrome 69, five in Chrome 70, 13 in Chrome 71, 13 in Chrome 72, and 15 in Chrome 73.
Beyond memory overhead, Site Isolation has implications for web developers in terms of how they craft websites. Google warns that the unload handlers – implemented to trigger a when a document or child resource is closed or unloaded – may not run reliably. Also, full-page layout under Site Isolation is no longer synchronous, which could mess up calculations pegged to not yet rendered page elements. ®