Forcing every website to adapt to a browser update is completely infeasible.
> 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).
We had the tech in the 80's for the browser to facilitate popup authentication with process isolation. It's this niche and esoteric tech called IPC[1], so niche that one really can't blame Apple for not hearing about it.
It truly boggles the mind as to how all the other browsers pull it off.
To be fair, there wasn't that much sensitive web content around in the 80s to leak (primarily due to the web not yet existing, nor browsers), so it's only fair that browsers didn't consider using IPC for site isolation back then.
The point of my rather facetious comment is that IPC a well known thing (I struggle to even call it "tech") that has been around for 30-40 years. I don't understand why Apple needs people to make excuses for them, but this excuse would render Apple vastly more incompetent than neglecting to separate browser tabs in 2025.
Browsers are incredibly complex, and moving them to an IPC model is not easy. Essentially, you need to ensure "same process like", performant JavaScript interoperability in some cases, often (but not always) due to backwards compatibility.
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.
How often do tabs really need to communicate, and when they do, does it really need to be as fast as possible. I would say slower and secure would be a better design philosophy, especially as tab interaction is generally rare, and low bandwidth
It's not used only for authentication, and figuring out what a website is trying to do heuristically doesn't sound easy either (although I believe Chrome on Android does just that, and enforces a site-locked process when they deem it important for security reasons).
But how much data are those popup based auth sending through? At the absolute most a few MB in a couple calls. Even if it's dramatically slower over IPC it's not going to cause issues.
Similar problem with third-party-cookies. They would make some auth cases easier and safer, but we shouldn't generally allow them because they are abused for tracking.
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.
> 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.
idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browser that can load almost nothing", and basically nothing in between. I had to stop using Firefox on my old ThinkPad because after opening a few windows, it churns the CPU so hard it's not usable for a solid minute+. Let that finish up, and I have to wait again if I dare to open another page. i5-3220m, 8gb of RAM (where the OS uses like 200mb of RAM)... there's no excuse for this to not be able to browse the web.
Some fun examples of "your browser is an OS on top of your OS":
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...
Every web developer is fine with 10% of the feature set, it’s just a different 10% for each dev. I am regularly annoyed by the inconsistent browser support for Web MIDI, something 99% of web devs probably don’t care about at all.
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.
Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)
Indeed. I work on the Firefox media stack and we have been grabbing wake locks when video playback is happening for a long time. Occasionally e.g. on some linux desktop variant this has malfunctioned and we're alerted in no time and fix it.
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).
Bless you. I was driven a little mad once trying to figure out why certain websites would steal audio focus away from music playing on my phone, it must have been some clumsy implementation of this.
> Now, video is done completely differently than it was.
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.)
> idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous)
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.
> The amount of obscure APIs being added just boosts the surface area for vulnerabilities
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 fully agree, as someone also doing Web development in a similar timeframe, for plenty of stuff we would be better with native apps talking over Internet protocols, no need to transform a platform for interactive documents into a OS.
Well, for better or worse, the web is an application platform these days.
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.
What? I thought Apple was trying to quietly kill pwas, probably bc they don't go thru their app store. And also bc if you make a good enough sandbox then you don't need to pay for "all the wooork we put in"
They certainly don’t have a lot of love for them as a first-class app development environment, but they are also their fig leaf of “open access” to the platform.
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.
The first two, screen wake lock and web serial have good use cases imo. I wouldn’t be surprised if some in-use assistive technology uses serial communication - think screen readers or custom input devices. Keeping the screen from locking is also useful from a purely accessible standpoint as well for users who move slower or need more time to read things.
That’s not a real choice though. All it takes is one website that is essential to me not supporting the secure mode and I’m forced to opt-out. The upstream website is making the choice for me.
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".
I mean, if all major browsers do it roughly once then users will complain to the few broken websites. They won’t even think to blame the browser if every other site works fine and the broken site is broken on all browsers.
Good luck trying to get Google or Microsoft to throw their paying enterprise users under the bus in the interest of slightly safer sandboxing defaults.
After building enterprise APIs for a few years, you’d be amazed at how hard it is to get companies to make even minor changes; backwards compatibility is key. Often it’s because they _can’t_ make the change themselves since they outsourced the code to a consulting agency. So they’d have to sign a new contract and get an agency to make the change.
They just won’t, and you’ll have a browser that people stop using.
It is probably outside the scope of what one company can do (although Apple is quite large…). But we need to fix our understanding of backwards compatibility. If a computer system provides the ability to keep doing something, but the way it provides that capability requires it to be insecure, then the system should not really be thought of as “backward compatible.” Because reasonably prudent people can’t actually keep doing the thing they were doing before.
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.
Announce what to whom? To the hundreds of millions of users out there that don't even know what a browser is, let alone why it's now talking to them about something called a "site isolation framework"?
I would guess you would use a deprecation message in the console? Like they have done over cookie changes, etc. A normal user would obviously not check the console, but the devs or admins of the site sure might.
That's assuming there's still a dev around that has knowledge of, or even access to, the source code of a given webapp depending on the legacy functionality.
Sure. I just got a vibe from this thread that breaking security changes in the browser is a totally unknown phenomenon, but we had changes to behavior from other origin headers, demanding ssl and changes to cookies. Somehow we survived. ;)
A lot of people did complain very loudly about enforcing SSL, and it took decades to get here. Same for cookies.
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.
> 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).