undefined | Better HN

0 pointslxgr1y ago0 comments

Safari definitely does use site isolation (if you check "Activity Monitor", you'll find Safari processes named after the sites they're displaying) in almost all cases.

window.open, in some constellations, is an exception, because the opening and opened sites have an explicit communication facility available to them, unless at least one of the two explicitly opts out of it. As far as I'm aware, Safari also correctly implements that opt-out.

The only thing that Chrome and Firefox seem to be doing on top of that, as far as I understand, is to actually enforce process-per-site even for sites from the same "browsing context group" (i.e. all that can hold programmatic references to each other, e.g. via window.opener), which requires using IPC.

0 comments

danans1y ago

> Safari definitely does use site isolation (if you check "Activity Monitor", you'll find Safari processes named after the sites they're displaying) in almost all cases.

From the FAQ:

"For leaking secrets, both SLAP and FLOP are confined to the address space they are trained in. As pointed out by iLeakage, Safari lacks Site Isolation, a measure used to enforce that two different webpages not from the same domain can never be handled by the same process. Thus, in Safari it is possible for an adversary's webpage to be handled by the same process (and thus address space) with an arbitrary webpage, increasing the attack surface including LAP- and LVP-based exploits.

On the other hand, although Chrome is equipped with Site Isolation, we demonstrate that it is not a perfect mitigation. We show the real-world existence of corner cases, where two subdomains of the same site can be merged into one process, again leading to LAP- and LVP-based attacks."

lxgrOP1y ago

Yes, in some special cases, which both embedded/opened and embedding/opening websites can avoid by setting the appropriate HTTP headers/HTML attributes.

Of course it would be better if Safari would do the same thing as Chrome and Firefox and just provide a separate process for all contexts, including those that can communicate per specifications. But there's something sites can do today to avoid this potential information leak.

danans1y ago

> websites can avoid by setting the appropriate HTTP headers/HTML attributes.

Individual sites plugging browser + CPU security holes seems like a violation of separation of concerns. Yes, I hope every bank out there puts this workaround into their site ASAP, but that's hardly a solution for the flaw itself.

lxgrOP1y ago

The permanent solution to the flaw is either a hardware/OS-side fix (i.e. disabling this particular kind of speculation via a chicken bit, if there is one), or Safari implementing site isolation in the same way Chrome and Firefox are already doing.

But as the former might well be impossible (at least without ruining performance or requiring a hardware swap), and the latter might take a while, websites should still take the precautions they can. It's a good idea for other reasons anyway: Why keep around an inter-context messaging mechanism you possibly don't even need?

1 more reply

j / k navigate · click thread line to collapse

0 comments

danans1y ago

> Safari definitely does use site isolation (if you check "Activity Monitor", you'll find Safari processes named after the sites they're displaying) in almost all cases.

From the FAQ:

lxgrOP1y ago

Yes, in some special cases, which both embedded/opened and embedding/opening websites can avoid by setting the appropriate HTTP headers/HTML attributes.

danans1y ago

> websites can avoid by setting the appropriate HTTP headers/HTML attributes.

lxgrOP1y ago

1 more reply

j / k navigate · click thread line to collapse