All the other side channel magic presented here doesn't matter if the data you want to read is in a seperate process with sufficient separation from the "hostile" process in the address space.
By setting a different policy, sites can protect themselves against this.
I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a major performance hit, and I don't think any other browsers do it differently.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cr...
And yes, something like a webmail site should definitely be setting the header, or at lest these attributes for outbound content links.
I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a penalty can opt their sites into the "same process" flag if really needed.
> I can't imagine there are many sites passing significant amounts of data through this
This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
They just won’t, and you’ll have a browser that people stop using.
Of source, modern computers on the modern web don’t really provide the ability to do much at all in a reasonably prudent fashion, so it is all a bit moot I guess.
So yes, breaking changes for privacy/security reasons do happen, but they're very painful, and if there's a more secure alternative (in this case, still isolating communicating processes and providing communication via IPC, and providing an opt-out way of the legacy behavior), that's often the easier path.
It truly boggles the mind as to how all the other browsers pull it off.
[1]: https://en.wikipedia.org/wiki/Inter-process_communication
Firefox has shared a lot about their efforts in moving there. If you're curious, there are a lot of blog posts and internal design docs under their project name "Project Fission".
But yeah, the fact that both Chrome and Firefox have managed to do so does leave Apple looking slightly bad here.
Performantly implementing that API across processes is possible, but not quite trivial.
Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites.
And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
Some fun examples of "your browser is an OS on top of your OS":
The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake...
The Web Serial API provides a way for websites to read from and write to serial devices. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...
The Window Management API allows you to get detailed information on the displays connected to your device and more easily place windows on specific screens, paving the way towards more effective multi-screen applications. https://developer.mozilla.org/en-US/docs/Web/API/Window_Mana...
The Compute Pressure API is a JavaScript API that enables you to observe the pressure of system resources such as the CPU. https://developer.mozilla.org/en-US/docs/Web/API/Compute_Pre...
(my thesis is, not all web developers want this stuff, and usually when I talk to people in the industry they agree, it's excessive)
I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely.
There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.
Regardless of that, I do like the idea of PWAs getting access to a higher tier of web APIs, especially those increasing the attack surface, as “installing an app” makes even non-sophisticated users do more of a double take than “visiting a website” in terms of access to their system.
It would be easier to sandbox if there were fewer features of course, but in practice we rarely see exploits even in complicated low-level APIs like webgpu (which must be a nightmare to make secure given how many buggy drivers and different devices it has to support). So it seems like in practice we are able to sandbox these APIs securely, and having them provides an incredible benefit to users who are able to securely and easily run applications (how else do you recommend people do this on desktop platforms?).
I can't think of an analogy that doesn't come off crass.
I posit the likelihood the morass that is webgpu not having exploitable bugs approaches 0 approximately 25 seconds after the first public release of the code, if not months prior.
Its only when one of two things occur that publishing happens, basically: intelligent frustration, and "for the lols".
Someone hits a bug and gets pissed that the authors of the libraries blame everyone but the library authors. When working around the bug discover its not just a bug. Warn devs. Sometimes responsible disclosure means a quiet fix and then disclosure, but usually it means "here's the exploit they don't care ig"
If there's not enough curious people poking things, exploitable stuff could remain hidden too long.
There's an obscure use case for this called "Watching Video"
Which is a thing that happened long before Firefox 126, too. (Browsers have simply requested the screen wakelock themselves when a video was playing. So this API is mainly for use cases that aren't playing a video.)
The Wake Lock API is for other use cases, such as recipe websites, or other document for which you don't want the screen to go away / dim, the kind where you happen to need to look at the screen for long period of time without touching it/interacting w/ mouse and keyboard.
Prior to this API being introduced, websites used to play an inaudible/almost invisible looping media file to keep the screen awake. This has power usage implication, a small single digit number of watts (1 to 3.5 depending on os, hardware, mobile or not) is required to keep audio running (because of high priority threads, frequent wakeups, and simply because the audio hardware itself needs power).
One of those libraries source, for illustration: https://github.com/richtr/NoSleep.js/blob/master/src/index.j...
It’s often the ancient APIs from around 1995-2001 that are the most vulnerable ones, with information leaking across origins (like todays) needing hacky fixes to stay secure and compatible.
window.open(), target=_blank, cross site request forgery, etc.
IE6 from 2001 had a ton of these modern security issues, and Netscape before it probably had them too.
At that time there were tons of buffer overflow security holes so no on cared about side-channel attacks.
I am not a web developer but I completely agree with you. To me, adding more complex points of failure in humongous piles of code that we absolutely need to run in a modern life is not a great risk assessment. It’s like we never learnt from the security issues with the JVM.
I think they've gotten away with it because it's a pretty obscure setting and they say a bunch of things like "most users should not enable this, and if you do enable it you should expect things to break".
Here I would agree with you though.
If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory.
Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.
It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).
https://source.chromium.org/chromium/chromium/src/+/main:con...
If Chrome itself is not aggressive enough, try the "Auto Tab Discard" extension.
Safari on the other hand doesn't even have Tab Sleep for whatever reason.
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.
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."
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.
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.
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?
According to the site they informed Apple in May 2024. Should that not have been enough time?
Basically, there are three scenarios:
- Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via '<a target="_blank' ...>" or 'rel="noopener"' references etc.) – these are relatively easily isolated if the browser supports it at all. All major (desktop!) browsers now largely do this, including Safari.
- "Same browsing context group" (but different origin) sites. These can communicate via various APIs, and historically that was achieved by just letting them run in the same rendering process. But in the face of attacks such as this one, this can be insecure. Firefox and Chrome provide sandboxing via separate processes; Safari does not.
- Same origin sites (without any stricter policy). These can fully access each other's DOM (if they have an opener/opened relationship), so there's not really any point in having them live in different renderers except possibly for fault isolation (e.g. one of them crashing not taking the other down). As far as I know, all browsers render these in the same process.
Sites can opt out of the second and third category into the first via various HTTP headers and HTML link attributes. If we were to design the web from scratch, arguably the default for window.open should be the first behavior, with an opt in to the second, but that's backwards compatibility for you.
I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense.
Can you make a "Secure" CPU? In theory yes, but it won't be fast or as power efficient as it could in theory be. Because the things that allow those things are all possible side channels. This is why in theory the TPM in your machine is for those sorts of things (allegedly, they have their own side channels).
The harder question is "what is enough?" e.g. at what level does it not matter that much anymore? The answer based on the post above this is based on quite a lot of risk analysis and design considerations. These design decisions were the best balance of security and speed given the available information at the time.
Sure, can you build that theoretically perfect secure CPU? Yes. But, if you can't do anything that actually needs security on it because it's so slow; do you care?
The way this has been trending is that in modern systems, we try to move as much of the ‘critical’ security information processing to known-slower-but-secure processing units.
But, for servers, in virtualized environments, or when someone hasn’t done the work to make that doable - we have these attacks.
So, ‘specialization’ essentially.
So the Apple's argument that iOS can't have alternative browsers for security is a lie.
Security isn’t a one-bit thing where you’re either perfectly secure or not. If someone breaks into your house through a window and steals your stuff, that does not make it a lie to claim that locking your front door is more secure.
In any event, Apple’s claim isn’t entirely true. It’s also not entirely false.
Browsers absolutely require JIT to be remotely performant. Giving third parties JIT on iOS would decrease security. And also we know Apple’s fetish for tight platform control, so it’s not like they’re working hard to find a way to do secure JIT for 3P.
But a security flaw in Safari’s process isolation has exactly zero bearing on the claim that giving third party apps JIT has security implications. That’s a very strange claim to make.
Security doesn’t lend itself to these dramatic pronouncements. There’s always multiple “except if” layers.
Alternative browsers would introduce other security concerns, including JIT. It’s debatable whether that would be a net security gain or loss, but it’s silly to just pretend it’s not a thing.
Security as the product of multiple risks.
Discovering a new risk does not mean all of the other ones evaporate and all decision making should be made solely with this one factor in mind.
One could also talk about the relevance of a speculative attack that hasn't been abused for years. There can be multiple reasons for that, but we shouldn't just ignore the main design motivation of Apple here. That would be frivolous and that excludes serious security discussions.
Every major mobile and desktop OS other than iOS has supported it for over a decade. Apple is just using this as a fig leaf.
Well, at least in this case it would have greatly increased security (since it would have allowed the availability of actual, native Chrome and Firefox ports).
And otherwise: Does Apple really have zero trust in their OS in satisfying the basic functionality of isolating processes against each other? This has been a feature of OSes since the first moon landing.
We can still hate on Apple, it’s just more accurate to say they don’t trust their own app sandboxes to stand up to LLVM / assembly attacks from malicious apps with JIT access.
Any real-world examples demonstrating how it's insecure? Here and now it demonstrably decreases the security.
It's realistically just another way to ensure they maintain control over app distribution. Safari sucks for web apps. Third party browsers are just different shells over Safari on iOS. Apps built on things like React Native support hotfixing without slow app store reviews - but your app will be slow without JIT and rules force you to still go through reviews for feature changes.
There's no issue with any of this on Android.
> Considerations for Safari. We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari. On the contrary, we also reflect on [Webkit's memory allocator] libpas’s heap layout from Section 6.3, allowing sites to not only share processes, but also heaps. Partitioning JavaScript heaps by at least several memory pages per-webpage would prevent JavaScript strings from the target webpage from being allocated within the 255-byte reach of the LAP.
possible absent any performance concerns at all, yeah sure
I was actually thinking something more like a bytecode interpreter that runs one operation and then sleeps until the next full wall clock second, but yes, that's my point: If you don't care about performance, you can make process isolation safe very easily.
Even Chrome, which pioneered the "tab per process" model, didn't isolate same browsing group context sites for a long time, and still shares processes on Android as a resource optimization: https://chromium.googlesource.com/chromium/src/+/main/docs/p...
Firefox only released their "Project Fission" in 2021, i.e. three years after Spectre.