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.