Site Isolation has been gradually introduced to users of the Chrome browser over several months, and now Google has officially unveiled this important piece of tech.
To fix this problem, Chrome 67 adds by default a new security feature called Site Isolation, which limits each rendering process to a single site, which means you will have a chrome.exe process for howtogeek.com and another chrome.exe process for google.com, and so on.
To check whether this is enabled, or disable it should you choose (which we don't recommend), you can head to chrome://flags#enable-site-per-process in your location bar, and then set the toggle for Strict Site Isolation to either Enabled or Disabled.
Enterprise users may use policies to enable Site Isolation starting in Chrome 68 for Android, and there is also a manual option to turn the feature on right now.
In other words, on Windows, macOS, Linux, and Chrome OS devices, Chrome uses the security boundaries provided by the operating system to ringfence each domain into its own browser process. "Site Isolation does cause Chrome to create more renderer processes, which comes with performance tradeoffs: There is about a 10-13 percent total memory overhead in real workloads due to the larger number of processes". From there, timing attacks can be used to uncover the values stored in the memory meaning malicious code may be able to read any memory stored in its process' address space. However, the Site Isolation feature narrows the scope, limiting each renderer process to documents from at most one site.
When enabled, all navigations to cross-site documents cause a tab to switch processes and puts all cross-site iframes into a different process than their parent frame, using "out-of-process iframes". The first uses of out-of-process iframes shipped past year to improve the Chrome extension security model. Web browsers generally allow pages to embed images and scripts from any site. This would normally fail to render and not expose the data to the page, but that data would still end up inside the renderer process where a Spectre attack might access it. CORB tries to transparently block cross-site HTML, XML, and JSON responses from the renderer process, with nearly no impact to compatibility.
Reis said it generally shouldn't cause visible changes for most users or web browsers outside of a few known issues but still, that's a significant performance penalty, especially on a machine that may already be light in terms of RAM.
Site isolation is by far the most ambitious Spectre/Meltdown mitigation deployed by any browser maker so far. Those tweaks make it harder for malicious code to successfully pluck sensitive data out of restricted memory.