It’s all have to do with resource management here.
It’s obvious that laying off people that were working hard at making more robust the flagship product of the non-profit wasn’t going to result in a an increase of security in this product. Could the whole lay-off have been prevented? That would require some number analysis here, and insights I lake.
Could at least some termination have been avoided? Freezing the income of the CEO until some agreed metrics improve, and use the amount thus spare to save some employ salary was certainly an option here, wasn’t it?
Claiming "think of my family, look how much more some other people earn elsewhere" while almost simultaneously (at organization level at least) putting so many people in a jobless position, that’s a rather bold cognitive dissonance to throw at the world to my mind.
If pointing out "odd financial priorities" of a non-profit is flame bait, one might wonder how humanity is supposed to mend all organizational dysfunctions it can ever fall into.
It’s pretty relevant considering the continued mismanagement of Mozilla.
Nobody would care about Mozilla in 2024 without Firefox, but Firefox development seemingly takes a back seat to a variety of other pet projects that Mozilla’s management tries (and keeps failing, over and over) to chase.
For example, they’ve been trying a pivot to become a community-focused privacy company the last couple of years, yet are fine with implementing ad topics.
AFAIK didn’t Safari advocate against it over privacy concerns? If so, what is Mozilla doing?
Or their partnering with a shady company for removing data from data brokers.
Before the privacy pivot, there was the “we want to make browsing better” pivot with their acquisition of Pocket that went nowhere.
From the outside Mozilla looks like a low-scoring charity grift you’d find on CharityNavigator with how far they deviate from the missions they claim to support.
Why managed when it could be in Rust and have both performance and safety?
The Servo shouldn't have ever been laid off. Yes, I'm aware a team is working on it now, but it isn't up to the same speed and enthusiasm as it was when funded by Mozilla, is it?
Having done concurrency in Java and Rust, my experience is that Rust's concurrency primitives are an order of magnitude better than Java's. I haven't tested C#'s.
C# doesn't have Send and Sync that is true. It frequently does not need either because it uses GC instead of affine types for automatic memory management. Synchronization is indeed "just don't write bugs", where Rust offers a massive upgrade, but .NET CoreCLR's memory model is more strict than C one, like object reference assignment having release semantics, so quite a few footguns are luckily avoided: https://github.com/dotnet/runtime/blob/main/docs/design/spec...
'&' and '&mut', however, are your 'ref readonly' and 'ref' respectively.
> At the end of the day web browser is just bunch of parsers and compilers working together
At the end of the day, OS is just a bunch of command lines being piped together. /sarcasm
Sure, you are just missing: rendering, layout, security, network traffic for sockets, low-level control over hardware, writing a decent enough VM, image processing, video playback, music playback, compression, decompression, self-update, decryption, don't forget add-ons people love add-ons, also add-on security and isolation, web edit and debug tools, network analysis tools, etc.
Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT? Same with crypto, sockets, compression, etc?
Video and audio I mentioned.
Extensions are tricky, right, but more from privacy standpoint cuz after all you can just expose too much
All the major browsers came out when Windows XP had substantial market share.
So browser vendors couldn't rely on the platform to provide up-to-date SSL support. Or MP3 support. Or MPEG-4 support. Or PDF support. This established the norm that browsers would ship their own video support, their own SSL support, and so on.
And Google realised they like the power this gives them - if Google wants to replace HTTP with QUIC or introduce a new video DRM standard, or a new video codec like VP9 - they don't need the cooperation of anyone outside of Google.
If Chrome bundles DRM support (allowing it to play Netflix), and its own HTTP/2 stack for speed - are you going to release a browser that's slower and doesn't play Netflix? Doesn't sound like a recipe for big market share.
Many of these components have been made part of the ecosystem long after they were introduced in Firefox. Also, the more platform-specific you go for each component, the more you're going to introduce subtle incompatibilities between Firefox running on different versions of Windows or in Firefox for Windows vs. macOS vs. Linux. Also, for a very, very long time, Microsoft had an extremely poor record in terms of security fixes. So what happens when you rely on a Microsoft http library and Microsoft takes a year or two to release a 0-day?
There are benefits to this approach, of course, but the costs would have been consequential.
Browsers are using new http features much earlier than they're available in the system libraries. Browsers supported http2 and 3 before they were standardised enough to include in systems. .net http client still can't even tell you about http2 early hints as far as I understand it.
It's going to be the same for crypto and compression. Systems don't ship with brotli for example. The battle tested implementations come to the browsers first in many cases - or at least they're battle tested at the point anyone starts including them in .net or Java.
> Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT?
Because modern browsers are essentially cross-compatible OSes.
> Throughout 2024, so far, Mozilla had to fix zero-day vulnerabilities on Firefox only once.
> On March 22, the internet company released security updates to address CVE-2024-29943 and CVE-2024-29944, both critical-severity issues
Vulnerabilities will be found in everything. Firefox is a fully internationalised application and it is FOSS. The team responsible for Firefox is doing a good job.
Sounds like Mozilla should invent a low level language with great safety guarantees, maybe even call it after some form of oxidation process[1]. Then make a browser engine called after a motor[2], and then NOT axe the team responsible for it[3].
A long time ago, the possibility of using Java or C# in Gecko (the core of Firefox) was pondered.
Java was rejected because of the huge memory requirements and the unpredictable (and sometimes lengthy) garbage-collection pauses.
C# was rejected because (at the time) it was too tied to the Microsoft ecosystem and there was no way to get it to build on all the platforms for which Firefox is available. I don't remember garbage-collection pauses being discussed, but they would also be an issue.
I think of browsers these days on par with OSes. I mean, they provide a runtime to execute binary code (wasm). They do process management and scheduling. They do a lot of things which up until 15 years ago, we thought bongs to the realm of Operating Systems.
And history has shown that when you need to do that kind of low level code, it's nigh on impossible to achieve acceptable results with a garbage collected language. Many people tried, none really succeeded.
It seems to me that both C#/Java have build their own niches and are hard to impossible to realistically use outside of them, such as to write a web browser.
That's not completely accurate. The plan is to use Swift for "security critical" areas like decoding data. It's unlikely core components like the layout/CSS engine will be converted to Swift.
> if it means some perf drop, modern hardware will get it back in X years
I think the unfortunate reality is that other browsers will also take advantage of that speed boost, sites will get even more bloated because they can and it will stay unusable for a long long time.
I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure).
Not sure why you think that WASM is less secure than JS though. Even if the WASM heap has internal corruption there's no way for this to do damage outside the WASM sandbox that wouldn't be possible in JS.
> I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C
Only parts of the browser are running in multiple small isolated WASM sandboxes, those WASM sandboxes are isolated from outside world about as well as if they would run in their own process.
Compartments of internally unsafe sandboxes are what we have now, with browsers employing native-code sandboxes and isolated renderer processes etc. It gets leaky.
Java applets didn't sandbox shit though, because you could call straight into your own native code via JNI (I know because I used exactly that approach to integrate a Win32 game client into browsers). The only thing that the applet launcher did was asking if it is ok to run the applet.
This is true, but adding a sandboxing to browsers has been a huge part in driving up the difficulty/cost of browser exploits, and driving down the frequency of their use.
And also we'll pay for a bypass of the wasm sandbox. (Actually, looking at our table, I'm going to try and get the bountyamount upped...)
https://4e6.github.io/firefox-lang-stats/
That's down from 12.49% at the peak in July 2020 so I assume the conversion work was halted after the layoffs in 2020:
https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9e...