Notably, the paper suggests that Webkit is even more hardened:

> Taking this approach a step further, Safari follows a simple one process per tab model, where two web- pages are never consolidated into the same rendering process, even under high memory pressure and even if they share an eTLD+1 in their URLs. Instead, Safari spawns a new rendering process for each tab until the system runs out of memory.

It's only in the context of `window.open()` that this isolation strategy is defeated. Given that both the calling window and the newly opened window share mutual references to each other, isn't the next side channel attack lurking around the corner, even if these windows are rendered by separate processes?

The paper does imply that, but I would disagree that it is more hardened. I would guess that this strict process per tab model is Safari's attempt to get some degree of isolation despite not having true site isolation.

> Given that both the calling window and the newly opened window share mutual references to each other, isn't the next side channel attack lurking around the corner, even if these windows are rendered by separate processes?

Non-same-origin opener references only allow very restricted operations. It is possible that there are undiscovered issues, but it is a lot less powerful than running in the same process. It isn't like having a raw pointer from one window to another.

Hum, given that the Apple Silicon processors use unified memory and a general cache (and that some of their performance has been attributed to what was then deemed an innovative memory and cache architecture) and that this is in principle a cache exploit, there might be still issues…

The cache on Apple's processors are fairly standard (but implemented well)

Maybe, maybe not. Spectre-type attacks (of which this is one) rely on a shared address space (in other words: the same process). Meltdown can cross address spaces but the authors do not know of any such attacks on modern Apple processors.