Chrome didn't have this until 2018, as the parent link shows. This is not about multi-process architecture. Firefox is < 3 years behind, not 10, not 14.
Site Isolation launched in Chrome in 2018, but the work started in earnest in 2012 -- see the below check-in. The idea in Chrome dated to before the Chrome 1.0 launch; it was the subject of Charlie Reis's PhD dissertation and he interned on Chrome pre-public launch.
Site isolation proved to be the biggest refactor in Chrome's history, and was one of the motivating reasons for the webkit/blink fork. Making site isolation work touched a huge host of features, since handling iframes out of process has a way of making simple things incredibly complicated.
The example I always gave was: imagine how the "find text in page" browser feature would be implemented. With the entire document in-process, it was a simple for loop. With the document and its subframes sharded across multiple processes, it is now a distributed search problem that requires handling of out-of-order results and stitching them into a traversal order. What's more, to achieve Chrome's security goals, you want to avoid introducing functionality that would allow the [presumed-compromised] process of the outer document to query the contents of the inner document via the find in page feature. So you can't simply do this as a peer-to-peer query between the renderer processes; it needs to be coordinated by the main browser process.
I was wrong about the actual security policy, but multi-process is still a big security win.
And not so related to this, but from what I've heard about cracking competitions a few while ago, Firefox was not even included, it was considered too easy. Maybe my sources were just bad.
And I say this as a Firefox user for the last decade or more.
Chrome was a new project, and didn't have to deal with the legacy of being built on top of the same source code as Netscape Navigator. I do not understand why you are trying to make this out to bash Firefox like they aren't as competent by taking ~10 years to implement multi-process browsing after Chrome. Legacy software and patterns are truly painstaking processes to iterate on.
But yes Electrolysis is the initiative that you should have referred to in the original comment.
What's wrong with the web and browsers? It's honestly pretty incredible - we have a system where we can load and execute arbitrary code from any number of third parties near-instantly and it actually works and isn't a complete security disaster.
People object to the massive effort it takes to create or maintain a browser engine which can practically browse the modern web. We're down to 3 players now actually trying to do this (Mozilla, Google, Apple). It conflicts with the idea that you can fork software if you dislike what it's doing, because even starting from existing code, it would be a lot of work to keep up with changes so you don't get left behind.
So people imagine splitting off a simpler web, where the main focus is on reading documents, rather than interactive applications, and browsers could be much simpler. But it's pretty hard to see how this could actually work in practice.
There are many distinct PDF readers. Making a document browser shouldn't be more complicated than making a PDF reader. PDF readers is how it works in practice.
I guess the issue is that a modern web browser is a sandboxed application runtime which also happens to function as a document browser. It's been going in that direction for a long time (since webmail became common), and there are real advantages of the browser as a platform for applications - it's cross platform by default, and it has pretty good sandboxing.
So probably the most you can hope for is that we split the document part of the web from the application part, so that it's easier to make a viable document browser. But it's not clear what advantage this offers for anyone who's not trying to make their own browser. Security is probably much simpler for the document browser, but the logins and sensitive data you care about securing are probably in the application browser anyway. And we've spent the last 20 years blurring the lines between documents and applications (think of a Github issue page, for instance), so even if it was possible to access information as a pure document, there would be advantages to looking at it in an application browser.
Gopher is the opposite of new. Gemini is interesting for sure, but it's not an alternative to the web as they fully admit. It's an alternative to a subset of the web. Let's call it the document web. Blogs and articles and so on. But as entertaining as it is, it is a very very small subset.
Respectfully, you're failing to engage with the purpose of the project.
> it's not an alternative to the web
Right. You can't have a lightweight drop-in alternative to the web, pretty much by definition. Any platform capable of everything modern browsers are capable of, is by definition enormously complex.
> it is a very very small subset
That's not a flaw, it's a design goal. It isn't meant to be a half-baked portable GUI toolkit the way the modern web platform is, it's meant to be a simple and minimal format, stable and easy to implement. There are other formats somewhat like this in common usage, like man pages and, of course markdown.
That's the point. If you want the web, you need today's browsers. If you want a subset of the web, your "document web" for example, you can get away with something simpler.
https://www.chromium.org/Home/chromium-security/site-isolati...