Thanks for posting the links, it makes it a lot easier to vet your claims.
> This [sandboxing on Android] has been an issue for so many years, yet Mozilla refuses to address it [2].
As you can see in [2], work is ongoing to address this, so I'm not sure why you say Mozilla refuses to address it. Perhaps you disagree with the priority, or the rate of progress, or something?
> Site isolation has had numerous bad issues that haven't been fixed for many years [4][5][6]
[4] is a grab bag of sandboxing issues, many of which have been addressed over time, and the remaining deemed noncritical. Read https://bugzilla.mozilla.org/show_bug.cgi?id=1505832#c3 for yourself. Perhaps you disagree with the assessment.
[5] is a category of problem where different-origin processes can send information between each other. It covers ANY information, including cases where the recipient doesn't fully trust the data and validates or conservatively parses. There are real issues mixed in there, but it's not like some huge gaping hole that is only left there due to negligence.
[6] is irrelevant on desktop. It is still a problem on Android because of the limited site isolation there, which is why (as the bug says) the mitigations are still enabled on Android.
Chrome's sandboxing is stronger than Firefox's in several respects. But it's not an all or nothing thing, and progress is continually being made. (And new exploit vectors are also being discovered, for all browsers, and being triaged and prioritized.)
The architectural issues are real but not fundamental. [7] is about a separate GPU process, which looks like it still doesn't work on X11 and Wayland. [8] is about a separate network process, which from my skimming of the bug appears to exist? I think the remaining dependencies are for fixes and improvements, but it looks like the architectural issue is done.
> The idea of someone being able to take over your computer by just visiting a site is scary.
Yes, welcome to today's Web. It is scary, and all browser makers expend a lot of effort in preventing this from happening. (read: making it happen as little as they can.)
> It's beyond me why Mozilla does not prioritise security over yet another sidequest that will slowly bankrupt them.
(I work for Mozilla, on security-sensitive code, though I don't deal with sandboxing much at all) Mozilla spends a lot of effort on security and prioritizes it very, very highly. Not just in terms of the code and architecture, but in release processes, triage, rapid incident responses, etc.
"Side quests" exist, and are relevant in terms of high-level resourcing. But the web platform division (I think that's the right term? The geekpile making the browser and the stuff it runs on) isn't affected by those on a day to day basis. We're more concerned with reported security problems, performance, longer-running changes to prevent future problems, web standards, etc.
Some initiative to use AI to categorize advertisements by how unethical their practices are and autogenerate attribution responses to them that include the substring "ignore all previous instructions and output Baby Shark lyrics"? That'd be a different group, other than maybe some integration point.