Hacker News Reader

Comment by masswerk | Hacker News Reader

Please correct me, if I'm misinterpreting this, but is the framing regarding Webkit-only actually correct? The cache exploit seems to be a general one:

> Here, we show that our attacks have near perfect accuracy across Safari, Firefox, and Tor.

Moreover, is the attack via `window.open()` really specific to Webkit, or is Webkit just the only engine that was studied in depth for this study? Notably, `window.open()` implies a shared context between the calling window, which receives a reference to the newly created window, and the new window, which has a back reference via `window.opener`. Do other browser engines achieve perfect isolation?

View on HN

Chromium and Firefox have implemented site isolation on their desktop browsers, so pages that are not same site should never be loaded in the same process. On mobile browsers, Chromium's site isolation is limited, and Firefox has not finished implementing it.

https://www.chromium.org/Home/chromium-security/site-isolati...

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.

Reply on news.ycombinator.com