The three data sources you mention are kept in the browser process (which is the privileged singleton process that spawns the sandboxed child processes that actually parse and execute web content). However the child processes can query and mutate them (to support e.g document.cookie). Those JS apis do work in iframes. In your example, we would create a facebook.com subframe process separate from the foo.com process for the main document.

You can see your example in action by enabling site isolation, visiting a page with a FB like button, and opening Chrome's task manager. You can even kill the subframe process, and it shouldn't take down the whole tab.

Great question.

Your intuitions are mostly right, in that the document blocking logic is related to CORS protection. In fact, when the document blocker sees a valid access-control-allow-origin header in a response, that's sufficient to allow it through.

However, there are a couple reasons though why CORS alone is not enough. First, the CORS checks (the ones that generate console warnings when they fail) are done inside the renderer process -- meaning some of the response data has already arrived in the process, and may be available for exfiltration by an agent able to read that process's memory.

Secondly, CORS only applies to cors-enabled requests (e.g. XHR and fetch). Our goal is to prevent, say, the HTML of your bank account details page or a similarly sensitive JSON-based API from arriving in any renderer process other than one dedicated to rendering pages for your bank's site. An attacker could point a script tag at the target resource -- script tags by default aren't required to go through the CORS dance (as an aside, <script crossorigin> exists, but I'm not entirely sure why). Since the attackers goal is just to cause the response to wind up in its renderer process memory, the attack still succeeds even if the JSON or HTML doesn't successfully execute as valid javascript.

So we need something stronger, which runs outside the renderer process. The idea is to look for responses that would necessarily result in an error in the context of any legitimate cross-origin use case (other than fetch/xhr, where CORS dictates what's legal). We need to block HTML, but allow stylesheets, images, and scripts. The blocking logic is really based on the substance of the http response, rather than what the renderer says it's to be used for, since the renderer is untrusted in this scenario.

JSON is a particular headache, since a subset of JSON is also valid javascript (dicts are syntax errors, but lists are we aren't), and as a result, JSON in the wild is often prefixed, and thus doesn't sniff as JSON. JSON also is often served with a JavaScript mime type.

An important takeaway for website authors is to serve any JSON or HTML with the appropriate mime type and the nosniff header.

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.

> don't set Access-Control-Allow-Origin (or only set it to a star)

Huh? These are two _very_ different situations. Not setting `Access-Control-Allow-Origin` would mean that no third party site can read data from your domain. Setting it to `*` would do the exact opposite, allowing any site to read data on the page.

It's also unclear to me how this relates to Spectre and Meltdown.

Setting it to star allows arbitrary cross origin access (star means 'any site' in this context). Omitting it is supposed to be the opposite. Important not to confuse the two!

Enabling site per process in chrome will give your users some protection of their data on your site, but only if your mime types are already correct. See the probably linked document for recommended headers.