For standard Safari (not technology preview) 17.0 on Ventura "Swap Processes on Cross-Site Window Open" is already enabled (and labeled Stable) for me. I did not enable it so it's possible Apple already enabled this and their description of how to enable etc. is out of date.

I also checked on my iPhone which I just upgraded to 17.1 and the flag is present and already enabled there as well.

Edit: Seems like I got confused by the other very similar feature flag as well.

They disclosed this vulnerability today but it appears the information on the vuln scare site is outdated. Bit sloppy.

I think users here, including myself, got confused because there is a feature flag that has a similar name.

"Swap Processes on Cross-Site Navigation" is enabled by default, but this paper recommends "Swap Processes on Cross-Site Window Open".

Also enabled by default for me on macOS 14.1.

Edit: It appears I confused it with a similarly named flag. It doesn't appear to be enabled on macOS yet by default.

I am on macOS 14.0 with Safari 17.0 and the feature is enabled by default.

It's unclear if they even reported this issue to Apple.

They reported it to Apple a long time ago, over a year I think. The problem appears to be that it's very hard to mitigate.

ETA: To be clear, this isn't me speculating. I spoke with one of the authors and asked this specific question. Apple hadn't shared the mitigation with them as of a few days ago.

Thank you. Do you know if lockdown mode / disabling JIT would mitigate the issue?

From what I’m told disabling JIT might do the job. With consequences to things breaking down.

Disabling JIT would make it substantially harder to exploit.

From the site (perhaps it was updated to include this?):

> We disclosed our results to Apple on September 12, 2022 (408 days before public release).

Interestingly, the YouTube videos are 13 months old.

That's when they reported it to apple.

It's been reported

>At the time of public release, Apple has implemented a mitigation for iLeakage in Safari

However the site gives no details on timelines or a report at all.

(edit) They have added a "When did you notify Apple?" to the FAQ.

Look at the faq

See edit.

I'm as confused about the mitigation status as others. However, the paper is clearer than the website:

> That is, while the speculative JavaScript sandbox escape is still possible, an attacker becomes limited to reading their own address space and therefore their own data. Finally, at the time of writing, Apple’s patch is publicly available [57] and is implemented in Safari Technology Preview versions 173 and newer [58].

[57] is https://github.com/WebKit/WebKit/pull/10169. At the bottom of it, an engineer continues to link ongoing hardening patches for window.open() + process isolation.

> Why has this been made public before a fix has been properly rolled out everywhere?

It looks like apple has had over 400 days to fix this. That's already more time than I'd have given them. It's far better that apple users are told what their risks are than to just leave apple users ignorant of the danger for another year+ by not saying anything while praying that nobody else is already aware of the flaw and quietly exploiting this.

I'm all for giving companies time to fix their bugs, but at a certain point it becomes more irresponsible to not inform the people impacted.

> Why has this been made public before a fix has been properly rolled out everywhere?

Because the last bastion of privacy and security have sat 400+ days on this without fixing it. I wouldn't blame the finders for making it public before the fix is rolled out, rather Apple for sitting on their hands for so long.

> This seems like a high severity issue, but the fix is behind a debug menu?

Presumably because fixing this required changing the processes model in WebKit, which means they are still testing the change before landing it for everyone.

> This also goes to show how the side channel mitigations are totally useless and we should stop pretending such attacks have been fixed. It is not safe to run untrusted code, no matter how you sandbox it.

All side-channel attacks have not been fixed, but I think it is inappropriate to call side channel mitigations useless. They significantly raise the bar for exploitation, much like seatbelts aren't "useless" even though people still die in car crashes. And I don't know about you, but I still drive cars even though I'd love to find ways to improve their safety.