I'm not entirely sure about this. The paper mentions that in Chrome and Firefox "different rendering processes handle pages with different effective top-level domain plus one sub-domain (eTLD+1)." (Meaning, windows in the same eTLD+1 group still share a process.) To proceed,
> "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."
This suggests that Safari/Webkit is even more hardened in general. It's only in the context of `window.open()` that this isolation strategy is defeated. Notably, `window.open()` somewhat implies a shared context between the calling window and the newly opened one, since both windows receive a direct reference to the respective other one. I can't see any description, how other browser engines would handle this differently and would achieve perfect isolation, or, in case these were explored in similar depth, might yield similar vulnerabilities.
Yes. Even without spectre, this would let anyone with any webkit exploit get secrets from any other website.
Browsers with sandboxed multi-process architectures have been around since 2008, precisely because experts realised that rendering engines are so complex they cannot reasonably be secured, so need to be sandboxed for protection.
Unfortunately, I suspect that security experts within Apple were well aware of this, but were overruled because iOS devices tend to not have much RAM, and the user experience would be severely degraded by doing proper process-per-origin isolation, due to RAM exhaustion.
Chrome on Android also opted not to deploy their version of full per-origin isolation for the same reason. However Chrome does create a new process for cross-origin navigation, which is sufficient to protect pages which disable iframe embedding. That's what Apple missed here.
I usually do it because I want to pose a question and then give one viewpoint of answer to that question, while leaving the floor open to other viewpoints/opinions.
If done well, it leads to a better comment-reading experience. Not sure I did it well in this example though.
It ends up looking like sockpuppetry gone wrong and I think it kind of gives you an excuse to pose the opening question in a (however inadvertent) flameframy, scarecrowy way.
No. On page 9, Section 5.1 they state that by default Safari will spawn one process per tab and they provide less consolidation by default than Firefox or Chrome. It is only window.open(), which is used to create popups, that was not updated from the old design that did not use isolation to the new model that does support isolation. The "security experts" at Apple were just too incompetent to audit their code base and fix all the known security holes.
I mean, this is not exactly shocking coming from the same company with "security experts" that released a version of macOS that allowed anybody to login to root with any password [1]. Their security review process is grossly incompetent. At some point you should stop believing the "security experts" who do the security equivalent of putting antifreeze into the ice cream because they ran out of sugar and the antifreeze tastes sweet so it must work just as well.
Isn't that shoddy security architecture 101?