Personally, I have turned it on. The highly experimental language dates back for several years (I think there's been a patch to revise the wording). This mode

Personally, I have turned it on. The highly experimental language dates back for several years (I think there's been a patch to revise the wording). This mode is already launched for all extension content since mid 2017, so it is well exercised. I no longer consider it highly experimental. The things that we know don't with are listed on the originally linked page; memory usage surprised us by not being a worse regression than it was. The TLDR of site isolation is that the same origin policy is enforced at a process boundary, rather than relying on the rendering engine to keep the JavaScript contexts within a process (say, evil.com and its bank.com iframe) from accessing each other's memory. With site isolation on, we put the subframe in it's own process; the parent process can't, for example, read cookies for the child process's origin. This relates to the novel CPU vulnerabilities because, to quote the blog post today, "The primary ramification of Variant 1 is that it is difficult for a system to run untrusted code within a process and restrict what memory within the process the untrusted code can access." Site isolation was designed as a defense in depth against the type of renderer compromise that would give an attacker arbitrary code execution in the renderer process. Variant 1 gives attackers something weaker than that, so the protection works.