Google charts progress in developing Site Isolation browser technology

Confining untrustworthy code

>

Google has outlined its progress in developing Site Isolation, a new browser architecture designed to defend against compromised renderer processes and related security risks.

Site Isolation locks each renderer process to a specific origin as well as filtering certain cross-site data from each browser process.

The technology, which is similar to the security mechanism of the Same Origin Policy, moves away from earlier browser architectures where different websites are run through the same renderer process.

Shared renderer processes have been considered risky since last year’s discovery of transient execution attacks, like Spectre and Meltdown, that can leak data via microarchitectural state.

In addition, the prevalence of private user data stored on websites means the risk posed by compromised renderer processes is increasing and therefore needs to be mitigated by tighter controls. These controls also prevent universal cross-site scripting (UXSS) vulnerabilities. 

Put simply: it is no longer safe to render documents from different websites in the same process.

Architecture update

Site Isolation, the initial version of which shipped to desktop users with the release of Google Chrome 67 in May 2018, offers a mitigation for process-wide attacks through a form of sandboxing technology.

During a presentation at the Black Hat Europe conference in London earlier this month, Google software engineers Nasko Oskov and Charlie Reis offered an update (PDF) on the development of its Site Isolation technology.

Asked to explain the technology, Oskov told The Daily Swig: “Using separate processes for different websites lets us put a sandbox boundary between them.

“This means that compromised renderer processes will have a harder time accessing data from other websites.”

Measuring performance

While the majority believe that Site Isolation will negatively impact performance, according to Oskov, the effect of running separate processes is not especially high. Performance, in fact, was found to increase in certain situations.

“Generally, we saw only small changes to page load time (2.25%) and input latency, and the total memory overhead was 9-13% in practice,” he explained.

“At the same time, it made some things faster, like allowing a page to stay responsive even if an ad or other iFrame was slow.”

Figures on performance impacts of Site Isolation can be found in Section 5.3 of the paper (PDF), which was submitted to the Usenix conference back in August. Oskov said that compatibility challenges with existing web content are also getting addressed.

Refining the tech

Work in developing Site Isolation remains ongoing and a number of bypasses have recently been resolved, with some of the issues having been made public.

Oskov explained: “We have recently fixed Site Isolation bypasses in a variety of features: Payment Handlers, AppCache, WebSockets, Blob URLs, etc.

“That means it is now harder for a compromised renderer process to attack other sites using these features.”

In September, Google's commitment to refining its browser technology was seen with the roll out of Site Isolation to Android mobile users via Chrome 77.

“Since the Usenix paper, we have launched a form of Site Isolation on Chrome for Android and strengthened a lot of the compromised renderer defences,” Oskov concluded.

YOU MIGHT ALSO LIKE Google extends Site Isolation security feature to Chrome for Android