[floil]

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.

[xg15]

Ah, so actually all of page isolation is about preventing Meltdown/Spectre or related attacks. I had thought only the first point was about that. This makes sense of course.

Thanks for the answer and for the awesome work in general!