[IN PROGRESS]

I've wondered what the crossOriginIsolated property is on browsers and why it is only emitted when the properties Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy are set. After diving into it I've come up with what I believe is the reason. But first allow me to give a little context.

The internet was taken by storm when two vulnerabilities, Meltdown and Spectre, that affected nearly all devices online suddenly dropped. They are speculation attacks that can allow an attacker to read other process's memory and consequently allow data exfiltration. This process can be divided into two subprocesses, reading the data, and exfiltrating it.

1. Leaking private data into hidden CPU caches

2. Exfiltrate the data back to the attacker

This vulnerability is particularly dangerous for browsers as they constantly run untrusted JS when you visit a website. Before any of this, your bank.com tab could run on the same process as attacker.com if it was in an iframe or initiated as a pop-up. The Same-Origin Policy (SOP) would be the main defence against tabs reading confidential data from arbitrary tabs, however this being done via software checks inside the renderer, it proved futile against Spectre attacks.

Introduce Site Isolation.

Site Isolation is a large change to Chrome's architecture that limits each renderer process to documents from a single site. As a result, Chrome can rely on the operating system to prevent attacks between processes, and thus, between sites.

Diagram above shows Chrome's new feature handling process isolation

Browsing Context Groups (BCG)

A browsing context group is a unit consisting of: any set of windows, tabs, or iframes that can reach each other through DOM relationships (window.opener, window.parent, frames[], named-target Window.open, etc.). Crucially, all top-level documents within a BCG were historically eligible to share a process, because they can synchronously poke at each other through window.opener.location and similar accessors.

Cross-Origin Opener Policy (COOP)

COOP prevents a top-level site from being put in the same BCG as new windows it spawns (such as pop-ups). When this feature is enabled, the new window is unable to access certain DOM features such as window.opener.

Cross-Origin Resource Sharing (CORS)

CORS is a header-based mechanic which relaxes the Same-Origin Policy. It achieves this by having a whitelist of origins that is allowed to read responses from the host via JavaScript (CORS requests include using fetch() in JS).

Cross-Origin Resource Policy (CORP)

CORP header is similar to CORS in functionality, but instead of relaxing the SOP it restricts which origins can read resources that are not CORS requests (no-cors requests include loading resources via HTML tags <script>, <img> etc.). It simply declares who can embed the host's resources. The three settings for it:

• same-origin -- only the exact same origin can embed,
• same-site -- only the same registrable site can embed,
• cross-origin -- anyone may embed.

Cross-Origin Embedder Policy (COEP)

COEP prevents an origin from loading resources (such as images, fonts, JS etc.) that don't explicitly give permission via CORP or CORS headers. An easy way to think about it is that it asks the resource owner "Am I allowed to load/embed your resource?". The settings are:

• unsafe-none — the default; no extra restrictions.
• require-corp — every cross-origin requested resource must respond with a Cross-Origin-Resource-Policy header which grants permission; or be requested in CORS mode (eg. <img src="https://third-party.example.com/image.jpg" crossorigin>) and pass a normal CORS check.
• credentialless —