Chrome introduced Site Isolation to mitigate last year’s vulnerabilities in the range. Last month’s version 77 saw the Android app receive similar protections to the mobile counterpart Google detailing the security measure and future plans today.
Site Isolation allows pages in separate processes to stop malicious sites from stealing from open browser tabs passwords, cookies, and additional data. On Android, Google has to make an impact in how CPU, memory, and battery limit phones.
As such, a “slimmer form of mobile site isolation” protects only high-value pages where users sign in with a password. Banking, shopping, and other sensitive data are “rendered in its own dedicated renderer process, walled off from other sites,” while less critical sites that share processes.
Chrome has a list of the most frequently visited mobile sites. After the user detects a password interaction pages not covered by this crowdsourced directory are added.
According to Google, Site Isolation is a “behind – the-scenes architectural change that should not affect the experience for users or developers,” but there is a “3% -5% overhead memory in real workload” performance impact.
This password-based site isolation is now available on Android devices with more than 2 GB of RAM for 99% of users. Chrome allows you to enable “chrome:/flags/#enable-site-per-process” to protect all browsing, even if performance warnings are available. Google will take detailed potential mobile steps, such as requiring websites to opt in to Site Isolation and further optimizations.
Meanwhile, Chrome 77 now defends desktops from “significantly stronger attacks”:
Today’s current measures include:
- 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.