Mozilla wants web users to be targeted with online advertising and/or pay for online advertising not Firefox development.
Mozilla is an online advertising advocacy project. Just try suggesting to anyone from Mozilla the idea of web without ads. They will be 100% opposed, unwilling to even consider alternatives, as if they are being paid to defend this pro-advertising position. They are indeed being paid indirectly from the coffers of an advertising company.
"Free and open web" apparently means web open for advertising. The presence/absence of advertising on the web is a non-negotiable. Mozilla insists advertising is a must-have.
Why was the original internet free of ads before it went public. Are there more important uses for a computer network. ISPs privatised the financing for the network. We pay for internet. It is not free. Funding from advertising has never been a necessity.
>But Mozilla argues advertising is 100% essential.
Citation needed. I realize they get a ton of money (probably most of their funding in fact) from Google, but still have they actually made such a statement? For now at least, they support ad-blockers a lot better than Chrome (because of Manifest v2).
While it doesn't directly say it, their acquisition announcement for Anonym (an ad/tracking company) comes about as close as you can by saying Anonym believes it (and implicitly they support the viewpoint)[0]:
> Anonym was founded with two core beliefs: First, that people have a fundamental right to privacy in online interactions and second, that digital advertising is critical for the sustainability of free content, services and experiences. Mozilla and Anonym share the belief that advanced technologies can enable relevant and measurable advertising while still preserving user privacy.
Which completely ignores non-profit uses of the web, which is interesting since they're a non-profit and all.
They've made similar statements in the past[1]:
> Advertisements pay for all those “free” services you love, as well as many of the products you use on a daily basis — including Firefox. There’s nothing inherently wrong with advertising
Which is of course true because they don't accept donations to fund Firefox despite people complaining that they want to be able to make such donations for years.
> even consider alternatives, as if they are being paid to defend this pro-advertising position.
There's no way they would manage to exist like a business with a multi million dollar a year CEO without all that sweet Google money. So they are totally beholden to advertising straight from the top down. It doesn't even matter who is at the top, the whole step setup guarantees it'll be one of the big business players.
Basically when they moved Firefox from a foundation to a corporation, this was pretty much inevitable. They don't even want our petty donations anymore. We can donate to the foundation's pet side projects but not too Firefox.
I shit on Firefox every damn day, but that's because I'm a tech-brain(rot) weirdo. Truth is I absolutely love it. Firefox, or one of its derivatives, is the main (often times only) browser on every device I own. I literally wouldn't buy a device if I knew I couldn't install Firefox.
Right now, our options are a world without Firefox or a world where Firefox is supported by the dominant market player. Maybe that changes in the future? Maybe it doesn't. But a chance for a future that isn't just the children of KHTML can't happen if Firefox doesn't exist.
The obvious Apple in the 90s comparison comes to mind.
It is, but we don't really know anything about Ladybird at this point. I hope for the best and wish Kling nothing but success. They have shown themselves as an exceptional and committed developer.
I hope for a future where I've got even more options, but right now, it's a baby project. Getting standards-compliant rendering working is step zero. Things like site isolation, hardware video acceleration, and extensions that have enough access but aren't running wild with permission are really where a browser in the modern world shows its metal. Not to mention multiplatform support.
An OS isn't just a kernel, and a browser isn't a just rendering engine.
Hey, ex-Mozillian here. For the old alt OS people, also an ex-NetPositive dev.
With that context, I'm on board with not giving money to Mozilla Corp. Late last year I cancelled my subscriptions to Pocket, the VPN, and recurring donations.
That said, I recommend that you support Servo instead of Ladybird.
Reason #1) C++ is just dumb in 2024 and choosing it is a big red blinking sign that the devs make bad decisions. Now they're considering a rewrite in a better language? So, starting again from scratch... No thanks!
Reason #2) Given the track record of the main author of being an ass to people who aren't willing to be marginalized, I don't have high hopes that he can lead anything as complex as a competitive browser. No, Serenity OS is nowhere near the same level of complexity thanks to el GOOGs insistence that the modern web includes every API found in OSes. Serial port access, really?
Anyway, please don't just jump on a hype train. Fund Servo.
How is Servo going these days? I didn't even know that Servo was still active, but judging on the blog (https://servo.org/blog/) it looks like a lot of recent development has been happening. Maybe it would help if Servo had an active browser implementation (beyond the downloadable shell).
> Reason #1) C++ is just dumb in 2024 and choosing it is a big red blinking sign that the devs make bad decisions. Now they're considering a rewrite in a better language? So, starting again from scratch... No thanks!
Because modern C++ (e.g., using std::unique_ptr with std::make_unique() and RAII wherever possible) is safe enough, is getting safer with each iteration, is easier to learn for someone who already knows C or older (pre-11) variants of C++, and offers greater compatibility with the billions of lines of code already written in C and C++.
> Reason #2) Given the track record of the main author of being an ass to people who aren't willing to be marginalized
I was hesitant to even mention this, but not having to deal with demanding, danger-haired political agitators wielding their CoCs is enough of a reason for me to avoid Rust completely.
The inability to fund Firefox development is completely baffling to me. The finances seem pretty obvious: Open up a fund for Firefox donations. Hire contractors under the non-profit to work on Firefox. When you have enough to pay a full time developer, hire one under the non-profit. Rinse and repeat.
If, as some claim, there isn't ever enough money to really fund development, fine, they've now proven that. But not even allowing it as a possibility is completely insane!
I'm left in a position where I'm assured repeatedly that the best way to fund Firefox development is to pay for a side project I have no use for like Pocket or their VPN and then hope that that payment doesn't get consumed paying for said side project or future side projects.
OP's thoughts were mine the day that the LBI was announced: finally there's a non-profit that is actually committed to maintaining browser diversity. It's just a pity that it's one that's starting from behind and not the existing non-profit whose browser at one point enjoyed a majority market share.
They may be starting from behind, but a clean slate might be to their advantage. It takes a distinguished dev to jump into an old, large scale project. Firefox and Chrome definitely meets both of those factors.
Brendan Eich might not be the perfect CEO. But still I think he would have done better than Mitchell Baker did. He's interested in technology in a way in which she isn't.
The business model for FirefoxOS didn't make sense, just like the business model for WebOS didn't make sense. Android was cheaper than free to put on phones because Google was willing to share search revenue with carriers. They would not have done that on a FirefoxOS phone before it reached scale, nor would Microsoft, which was pushing its own phones.
I don't buy it. Apple owners pay premium prices for a perception of increased safety and convenience. I feel that way about what WebOS was. There is always market space available for a device people want.
HP played musical CEOs - 3 in less than a year - and one decided they shouldn't be in the phone or PC business. People loved the phones which were objectively years ahead of Android or iOS. It was not a product failure, but one of management.
People loved the phones, but they didn't buy them. The carriers didn't want to sell them because they don't get paid on the backend. As I said, the business model doesn't work.
FirefoxOS was simply dumped too early. You need TIME to advance in an established market and they simply didn't give it time. They wanted results within a year or two, but growth occurs organically in an occupied market.
In India, an entire telecommunications company was forced to use a fork - KaiOS for Reliance Jio phones because FirefoxOS was abandoned.
FirefoxOS was a terrific idea, but the baby needed time to grow up to teenage level, but was murdered soon after birth
A leader should unite an organisation. You can't lead an inclusive organisation and then cause divisiveness.
And don't forget, these things are not just cosmetic. Not being able to get married could lead to some serious consequences when having kids (e.g. a lesbian couple) and one partner dying.
Personally I would not have pushed to fire him, no, and I'm very pro-LGBTQ+. It was only a small donation compared to how much he makes and the legislation was easily defeated. But I don't work at Mozilla.
> And don't forget, these things are not just cosmetic. Not being able to get married could lead to some serious consequences when having kids (e.g. a lesbian couple) and one partner dying.
That is not true. California had domestic partnerships with identical rights and responsibilities as marriage starting in 1999. Eich opposed applying a term that, in his view, carried religious import. That's all.
Yes. Brave's crypto scam is a problem, and they've done some very controversial things in that regard. Like taking "money" on behalf of sites that didn't even participate.
Yes. The purpose of Mozilla Org, from the perspective of the people paying for it (Google), was to kill Firefox. Mitchell Baker got rewarded because she did her job.
I don't think he would've done things differently really. He was also part of the same old guard and wasn't exactly aiming for some radical changes inside Mozilla. Imo one of the only things that could've made Firefox more relevant would've been to focus on an electron alternative, especially early on in 2013-14 as it would've been an entirely new "product segment", which could've made Firefox the standard engine for a lot of apps. But there's no indication that anyone high up at Firefox wanted to do something like that. It's a non-profit and non profits are rather conservative, for better or for worse.
Yeah I heard about it, but I don't know why they gave up. There's a lot of stuff that could be done to improve on electron (especially back then), and Mozilla was in a nice position where they controlled their web engine (as opposed to electron), so they could've made a very solid product... anyways that's not happening now...
Edit: okay from what I understand in the blog, one of the reasons for abandoning it was that it was hard to keep up with the electron API changes and keep it compatible. That just goes to show that they were completely outplayed early on, otherwise they wouldn't have had to play catch up by merely being an electron shell around Spider monkey...
>But Tofino is dead (long live the Browser Futures Group!), and Electron compatibility isn’t essential for a viable Gecko runtime. It’s also hard, since Electron has a large API surface area, is a moving target, requires Node.js integration (itself a moving target), and is designed for Chromium’s process architecture, which is substantially different from Firefox’s.
He would have at least avoided getting distracted by every single liberal cause that popped up along the way and kept his focus on technology. You can complain about Brave's crypto stuff, but at least it was trying to solve a real problem with internet monetization instead of being whatever Colorways was.
Sure but that's just a symptom not a cause. Even without making Mozilla turn into a regular non profit that just happens to have a browser project (as opposed to a browser project non profit), the strategy they had just couldn't work.
Every monetization attempt failed (even with stuff centered around "privacy", a niche where Firefox is well known). I've seen numbers that indicated that the Mozilla foundation donations are almost equal to what they profit from their commercial products.
> Every monetization attempt failed (even with stuff centered around "privacy", a niche where Firefox is well known)
Again, though: they have yet to try the obvious, which is allowing people to donate to Firefox.
I have zero interest in supporting all the random distractions that Mozilla engages in, but if they gave me a donation box for Firefox specifically I'd set up a recurring payment today.
They can't in good faith claim to have tried every monetization method when they have never let users earmark funds for Firefox.
This is misleading. Firefox does not have a CEO, Mozilla does. The Mozilla CEO/chairperson is responsible for many more projects than just increasing the market share of Firefox — whether nerds on Hacker News think that’s what Mozilla should be doing or not is another conversation.
Sure, but their main project still is Firefox, by far. That's the project that has the most impact too.
How successful are they with their side projects, anyways?
$75 million per year from subscriptions and ads, according to their latest report (2022 for some reason). Another commenter did some quick math to try to prove that donations were fruitless and found that Firefox could reasonably expect to replace that revenue with a donation box:
According to this comment† from the very same post on Reddit:
> [Mozilla] in 2018's cash flow was negative ~1 million dollars while in 2022 it actually profited ~167 million.
A reply to that comment‡ states the following:
> Also important is that if you look at their annual reports, while it's still the most significant revenue source, the percentage of revenue coming from search engine royalties (i.e. Google) has been steadily going downwards. Instead revenues from their other services (VPN, Pocket, etc) had been increasing steadily.
And indeed we can verify those numbers on Wikipediaᵃ, where we see "Revenue derived from Google" trending downward every year.
So it seems she's been A) successful with continuing the search engine deal with Google; and B) increasing revenue from their other services (VPN, Pocket, etc.) so that Google's contribution to the revenue pie chart slowly shrinks over time.
I would imagine that there is caution about becoming beholden to user donations to continue operations. Such a situation would give users a measure of effective voting power in the development of the browser.
If you were starting a project from scratch I could see that as a valid concern, but the current world is one where 80% of the funds to pay for Firefox comes from Google. No one can seriously argue that becoming beholden to your users is a worse situation than becoming beholden to your primary competitor.
I don't think so, but close. I think they're indirectly paid by Google to keep Firefox around as a token competitor for antitrust purposes. I'm sure that's what the "search deal" is really about. Because Google already owns the search market, they don't have to pay for it.
However with falling marketshare there comes a point that when that won't fool regulators anymore. And then there's no point for Google to keep paying.
It seems more likely to you that Google isn't serious about Chrome's dominance than that they're totally serious about it and are using Firefox as a guard against antitrust and using their funding of Firefox as leverage to get Mozilla to cave?
That's the same situation basically any for-profit company with a paid product is in, is it not? If people don't like your product or don't see a future in it they will be less willing to pay for it (or donate for it). How is that bad?
You can fund Firefox by pooling money and pay a developer or a company like Igalia to implement a feature you want. It's not trivial, but given the number of people on HN that claim they would pitch in, someone should really try that.
Folks on HN are good to talk the talk but not really to walk the walk. Not only they could give to developers or company like Igalia but they could also get a Firefox Relay/VPN subscription. They don't even need to use it and their money is going to be 100% profit for MoCo. Also, if we are realistic, the total money in donation that Mozilla could get would probably represent a drop in the ocean compared to their annual budget and the amount of money you need to develop a (complete) browser. It's way more complicated than creating yet another chrome skin.
If you can provide a citation for this claim I'd get a subscription today. I don't pay for their side projects because I don't want them to take it as a signal of demand for VPNs, but if it's truly 100% profit I'd be willing to risk it.
> Also, if we are realistic, the total money in donation that Mozilla could get would probably represent a drop in the ocean compared to their annual budget and the amount of money you need to develop a (complete) browser.
People keep saying this, but given that it's never been tried you have no proof. And even if it were, what harm is there in opening up one more option for those of us who want to be really clear about what we're paying for?
> If you can provide a citation for this claim I'd get a subscription today. I don't pay for their side projects because I don't want them to take it as a signal of demand for VPNs, but if it's truly 100% profit I'd be willing to risk it.
Fair enough. They publish their annual financial report but it isn't splitted per project so it's hard to know for a fact with the public information we have access to. However, it isn't unreasonable to think that at the very least a percentage of the smaller products revenues are reinjected elsewhere in the organization (e.g Firefox) since the goal seems to be to diversify their income sources.
> People keep saying this, but given that it's never been tried you have no proof. And even if it were, what harm is there in opening up one more option for those of us who want to be really clear about what we're paying for?
It's been tried over and over in the FOSS community. Few projects are able to get decent money with donations (e.g. Thunderbird). However, it's nowhere near the complexity of a web browser.
For example, Thunderbird made almost $7M (USD) in 2023 for an average of $20 per donation which is 350k users out of 20M monthly active users [1]. Firefox has 10 times that number of users so we could estimate that they'd make $70M/year. That's far from $500M/year they're doing right now.
$70m is just $5m shy of their entire "subscription and advertising revenue" line item, with none of the extra cost of getting that revenue. Your back-of-the-napkin math would suggest that donations could render all of Mozilla's for profit side projects unnecessary and allow them to focus that energy exclusively on the browser. What's not to love?
As I said above, if it's a failure, fine, at least they tried. Knowing that it's possible to replace the side projects with a better model why would they not at least try?
I don't want a single feature, I want a guarantee that Firefox will receive consistent maintenance over time and won't be influenced by Google's opinions about what the web should become. A small monthly donation helps with that in a way that feature sponsorship doesn't.
Yeah right, you're basically talking about a fork because nobody can force upstream to go along with your plan. There are already several forks of Firefox. We don't need more.
I'm saying you can't independently fund whatever features you desire without a fork, because upstream is under zero obligation to accept your contribution. They may have a conflicting vision of where development needs to go, or simply be unwilling to assume the risk of taking your contribution.
Mozilla isn't incapable of funding Firefox. It's just that they get most of their funding from Google, and thus they will never be allowed to break free or dominate the browser market again. That is, unless Google gets out of the browser business, which will probably never happen.
There must be some sort of cultural virus attached to Firefox that it has to make money as a commercial entity. Firefox was born from Netscape, a for-profit closed-source project, and while they lost the closed-source aspect of it, the executive class at Mozilla don't want to give up the for-profit segment.
Why is Ladybird getting so much attention. Has anyone herd of servo? They're trying to offload css rendering to the gpu. That could be a big deal in the long run.
Although I am stocked about the new browser getting all the attention it deserves, isn't chromium still the most secure browser to use? How long will Ladybird take to be as secure as chromium?
Hello friend! Thank you so much for donating to support Ladybird!
We believe the world needs a truly independent web browser.
That's why we are funded entirely by voluntary donations, and we intend to keep
it this way forever.
Make sure you sign up for our newsletter below if you'd like to receive
monthly updates on our progress!
Second this. I'd much rather see more funding for a safer and secure browser than yet another browser that will have the same C and C++ memory corruption vulnerabilities again.
> However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
So it looks like there's a plan to refactor away from C++ as it spreads its wings. I'm in favour of people funding any browser engine with a realistic shot at viability.
I think Ladybird and Servo are exceptionally interesting projects and am so happy they exist. Despite being my daily driver, Firefox has its problems, and they regrettably mostly stem from the Mozilla foundation. Supporting a future with an ecosystem of FOSS browsers that aren't owned by an advertising company is very exciting.
Not only that, but Servo is only receiving less 3000 USD/month in donation, less than their goal of 10k/month, and much less than what they deserve if consider Ladybird is receiving millions.
would be neat if ladybird ended up depending on and helping fund servo. that would fit both projects' missions - servo could continue focusing on the rendering engine and ladybird could get to outsource effort on that part of the code.
I know they didn't do this on purpose and it was because it started as part of SerenityOS, but I'm unexcited by this project because it's written in C/C++.
Rust was literally invented to solve the security and concurrency issues inherent in using C/C++ for a browser engine. You could argue that's the one use-case where it is objectively the best language to use. It's so valuable for that purpose that every large company has rewritten at least some crucial components in Rust.
I also think Rust will be one of the only languages strict enough to enable the use of AI-generated code without compromising security. I certainly don't want AI-generated code for high-security applications, but there's nothing we can do to stop it at this point.
I believe the team has said they are currently evaluating different languages, though they have not divulged which ones. From the FAQ on the Ladybird website:
"We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages."
I assume it's either Rust or Jakt (the latter a language in development by the Ladybird lead dev), though I suppose Swift might be on the table.
Creating a new language is almost as insane as building a browser engine. I do not expect this to become a viable browser regardless, but I guarantee it'll fail if they use their own new language for it.
I do like Rust, but I've only come across a few "higher profile ish" projects. None were really that important or useful that I actually bothered to remember them.
I only left them off because we’re talking about size here, and I don’t know how much code that actually is. I am a Windows user, so I’m quite excited to have Rust in my kernel! But as far as I know it’s just one small bit, with more to come!
You're replying to Steve Klabnik, co-author of the Rust book [0] and (previously) a core team member for years. If he says it's been used on big projects I'd be inclined to believe him.
Note that it's likely that some of the biggest applications aren't public and so even if identified you couldn't actually count the lines yourself.
> I've only come across a few "higher profile ish" projects
Of course, your mind is biased towards things that have existed for years before Rust gained traction. Those codebases aren't necessarily going to be rewritten overnight (if at all) in Rust. Others have mentioned it, but tech companies are writing foundational software with Rust, check out Cloudflares repository list for example:
Friends of Mozilla certainly control Rust, and it is not outside the realm of possibility for Rust to switch to an awful license. It may be a bit much to suppose that Rust devs would sabotage Ladybird but certainly there is a potential conflict of interest that should be looked at.
>At this point, Ladybird has no competitors because it is not much more than a hobby project. It isn't usable yet.
Whether or not it is usable is a temporary technical issue. It absolutely is a contender for mindshare. Lots of people want a browser that isn't controlled by a nefarious advertising megacorp, and Firefox is about the only game in town. That is hopefully going to change.
Anyway, it would be a good thing anyway because "friends of Mozilla" are likely some of the most dedicated FOSS people working in software.
> it is not outside the realm of possibility for Rust to switch to an awful license
It is absolutely outside the realm of possibility. It is as impossible as Python or any other major language doing it. Millions of lines of Rust are in production at for-profit and non-profit orgs, as well as in FOSS projects.
Even if they did it, Rust would be immediately forked and continue as it was before under a different name.
> Whether or not it is usable is a temporary technical issue.
I disagree. It is a long-term technical issue, because every viable browser engine so far has had many millions of person-hours put into it. Ladybird isn't close and likely never will be.
> Rust was literally invented to solve the security and concurrency issues inherent in using C/C++ for a browser engine.
Are most browser vulnerabilities not still found in engines like V8? Rust can help with something like last year's buffer overflow in libwebp (although that's overkill when a project like https://github.com/google/wuffs exists), but I'm unclear on how it gets you a better JIT.
AIUI, Servo has been a failure because Rust is not very good at this problem domain. Browsers have to deal with circular references and this is easily handled in C++.
Hopefully someone who knows more will explain this better
if you ever write the words "unsafe" in a rust codebase, and you are not directly needing to poke bits on some hardware, you are doing it very, very wrong.
good link you shared. i personally always went with option 2 he presents.
This kind of dogmatism is why people think Rust will be impossible to adopt. All `unsafe` means is that the code inside the block doesn't have Rust's guarantees and should be inspected extra carefully by hand, much the same as you'd ideally inspect every single line of C. If sprinkling `unsafe` everywhere allows an organization to quickly adopt Rust's guarantees elsewhere and they're aware of that caveat (hard not to be given the naming) that can only be a net improvement over doing the entire thing in C.
You can always go through and systematically remove unnecessary `unsafe` later if needed, but there's no need to do so upfront if that would prevent adoption.
My concern with Ladybird is the long timeline to deliver the alpha version. I think the development strategy should be discussed in the community because there could be good ideas to speed up the process.
Hopefully, but you can only hope. My fear is that when people are crunching the numbers at Mozilla they'll see that Pocket (or whatever) is doing well and funnel resources to that, unable to distinguish between people who like Pocket and people who just want to help Firefox out.
Giving me a donation box to pay for Firefox means that I can be very confident that they are getting the right message from my dollars. But for some reason they are very reluctant to do that.
Without signing in to a Google Account, Chromium does pretty well in terms of security and privacy. However, Chromium still has some dependency on Google web services and binaries. In addition, Google designed Chromium to be easy and intuitive for users, which means they compromise on transparency and control of internal operations.
ungoogled-chromium addresses these issues in the following ways:
- Remove all remaining background requests to any web services while building and running the browser
- Remove all code specific to Google web services
- Remove all uses of pre-made binaries from the source code, and replace them with user-provided alternatives when possible.
- Disable features that inhibit control and transparency, and add or modify features that promote them (these changes will almost always require manual activation or enabling).</i>
If you were to fund, say chrome, you might waste your money.
Might be similar to funding firefox, which has lots of telemetry baked in. Unless you could fund a "no-telemetry firefox", or a version of firefox with easy to implement self-hosted firefox sync and auth.
Another comment brough up memory safety. I'm surprised myself that the project is moving forward without using a memory safe language at its core. A browser is a huge attack surface and all the example I know point to a necessarily enormous code base.
I understand the project started as a hobby, and anyone who wishes to be involved has their own prerogative, but I'd have a hard time getting behind it myself.
> How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language?
It turns out actually pretty effectively? There are going to be more bugs and boundary issues of the OS, but memory unsafety isn't some goop that oozes into your runtime.
My point is, people act like anything built with non memory safe languages is shit ever since Rust became the Jesus. We have the actual operating systems written in C, working ok. It is fine.
Yeah maybe Rust would be better but it is not a magic bullet and memory safety comes with many caveats in design of the code and possible performance issues when you are building something low level like a browser.
Right, or equivalently, you can rely on the million eyeballs and the million developer-years poured into those OSes, while developing your project with a much smaller team.
In many cases, you'd need to escape the browser before exploiting the OS itself. Security is not an all or nothing, layers and layers are effective at mitigating or increasing the time it takes for exploit to work. For instance ASLR is absolutely not a bulletproof solution, but many exploits are order of magnitude more complex to execute when enabled.
In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
My remark was a little more abstract and frankly, absurd though.
I mean, the most memory safe language will invoke syscalls. It will ask for memory pages and stuff. If we assume the app is running on a pile of shit because the OS is written in C, how can we be sure that the language is memory safe?
I understand the value of memory safe languages but people bashing on C/C++ code does not make sense to me when everything is essentially running on C. That’s all.
> In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
This made me curious about something. Has there been many exploits stemming from JavaScript engines? I honestly do not know but as far as I can tell, most of the issues originate from faulty image decoders screwing up memory and tls implementations etc.
A memory safe language may force you to think about memory safety, but it can also work as a straightjacket that makes it more difficult to think about other security issues.
No, because the memory safety part comes at a cognitive cost.
You may be right if you're talking about a GC'ed language, which gives memory safety and at the same time frees up the developer's mind. But if you're talking about constructs like borrow checkers then they do add cognitive load that is perhaps better spent elsewhere.
I've not found this to be my experience; if anything, working in Rust has freed me to think about other aspects of security in my project since I don't need to spend all my effort applying extra tools to find segfaults. Do you have an example?
The developer of curl has done an analysis of what percent of his CVEs would have been avoided in a memory safe language. I think the answer was a bare majority.
Why build a new browser in C++ when safer and more modern languages are available?
Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.
However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
It’s not as simple as “just” using a memory safe language.
The languages that are memory safe either impose too much of a straightjacket to be productive (Rust), don’t give you a GC or a memory safe way of writing one (Swift, Rust), or give you a GC with the wrong semantics (Java, Go, etc). Yes, the browser needs to have a GC. No, there’s no way around that.
I’m not saying it can’t be done - but there are good reasons to stick with C++ to get this job done. Not an ideal situation but it’s where the world is at.
Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.
GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.
It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references).
The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics.
So, maybe there is code out there where the GC can be an island. The browser is not that.
Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API.
And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
Doesn't Rc already demonstrate that kind of accounting?
You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.
A type system can let you say things like “make sure someone finds out when I assign this pointer”. But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes). GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).
> But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes).
I can't figure out exactly what you mean here. Temporary pins on the stack should be fine, and I don't see why anything else would be necessary.
> GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).
Doing heap allocations through the GC doesn't sound very hard. And why does it need to be below the type system?
Maybe instead I should ask you what the already existing GC libraries for Rust get wrong? Do they require users to be unsafe or do something to break safety? Are they unusable to implement javascript?
> I can't figure out exactly what you mean here. Temporary pins on the stack should be fine, and I don't see why anything else would be necessary.
The browser has a whole native heap (i.e. C++ objects, in current impls) that participates in the JS GC heap as follows:
- If the C++ object is referenced from C++ or from JS, it must be kept alive.
- If the C++ object references a JS object, then the JS object must be kept alive, so long as the C++ object would have been alive per the previous rule.
- It's possible for an object reference chain like JSobject->C++object->C++object->JSobject, and let's assume there are no other pointers to the C++ objects, in which case the last JS object should kept alive by GC only if the first JS object is alive.
- It's possible for dead reference cycles to exist like JSobject<->C++object, in which case both should die.
This requires that C++ has the ability to place references to JS objects in C++ fields.
This is where pinning comes in. It would be quite simple (and memory safe) but also totally incorrect (i.e. massive memory leak) to say that if a C++ field points to a JS object, then the GC just sees that field as a root. This is what I mean by pinning. (Note that "pinning" has many meanings in GC jargon; I'm using the Hermes version of the jargon. I guess I could have said "strong root" or something, but that's weirder to say.) This would be wrong, since it would not allow us to collect the dead cycle at all. Dead cycles are a common case in the browser. It would also cause other subtle breakage.
So, what the browser does instead is to have the C++ heap participate in GC: every C++ object that could possibly store a reference to JS objects anywhere can respond to GC callbacks asking it to account for all of those references. And, every C++ object needs to have a story for being referenced exclusively from JS, exclusively from C++, or a combo of the two. And the C++ code needs to be able to participate in whatever barrier discipline is necessary to get generations or incrementality or concurrency that the JS heap wants.
There are different ways to do this. Blink's Oilpan is probably the most principled, and that's basically a whole GC-for-C++ framework - very complex stuff. So, tons of inherently not-memory-safe code on the browser side just so it can do business with the JS heap.
I'm trying to figure out where our understandings differ, since that generally sounds familiar and reasonable to me. I guess you're assuming the callback/accounting code needs to be unsafe or able to violate the GC's preconditions? But I don't see why you assume that. As part of the GC, build some data structures that can handle that accounting and present a safe API, then use those data structures anywhere you don't want to create a root. When the browser code accesses the contents, barriers can be applied automatically.
The hard part of using a data structure like that is giving it ownership of the data and control over destroying it, but Rc does that too, doesn't it? That kind of thing is why I mentioned Rc. The difference between Rc and GC is much more in the behind-the-scenes tracking than in the API it gives.
> I'm trying to figure out where our understandings differ, since that generally sounds familiar and reasonable to me. I guess you're assuming the callback/accounting code needs to be unsafe or able to violate the GC's preconditions? But I don't see why you assume that. As part of the GC, build some data structures that can handle that accounting and present a safe API, then use those data structures anywhere you don't want to create a root. When the browser code accesses the contents, barriers can be applied automatically.
If this code was all written in Rust, I could imagine there being almost no uses of `unsafe`, except for one: the thing where the GC decides to delete an object.
But this means that all of that code that isn't marked `unsafe`, but instructs the GC about what objects to mark or not, is really super unsafe because if it makes a logic error in telling the GC what to mark then the GC will delete an object that it should not have deleted.
So, the problem here isn't that you can't wrap the unsafe stuff in a safe API. The problem is that even if you do that, all of your seemingly-safe code is really super unsafe.
> The hard part of using a data structure like that is giving it ownership of the data and control over destroying it, but Rc does that too, doesn't it? That kind of thing is why I mentioned Rc. The difference between Rc and GC is much more in the behind-the-scenes tracking than in the API it gives.
The difference between RC and GC is exactly in the fact that the API they give is radically different. And that the behind-the-scenes tracking is different, too.
It's totally valid to tell RC "I want to point at this object so keep it alive".
But that's not the API that the GC will give you, unless it's a pinning API. The API where you tell the GC "keep this alive" will prevent the deletion of the garbage cycles I mentioned earlier.
So, the GC (in the case of something like a browser) gives a different API: one where user code either marks something, or not, at its discretion. There's no easy way to make that safe.
> But this means that all of that code that isn't marked `unsafe`, but instructs the GC about what objects to mark or not, is really super unsafe because if it makes a logic error in telling the GC what to mark then the GC will delete an object that it should not have deleted.
By putting it in a GC structure, it would be giving ownership to the GC, and would borrow it back to use. So whenever it's not borrowed, it's safe for the GC to delete it. And the GC won't delete anything outside of its control.
If you have a logic error and prematurely delete, then attempting to borrow the object will return None, which is still safe.
> It's totally valid to tell RC "I want to point at this object so keep it alive".
> But that's not the API that the GC will give you, unless it's a pinning API. The API where you tell the GC "keep this alive" will prevent the deletion of the garbage cycles I mentioned earlier.
The idea is that any pointing/pinning you do while manipulating an object would be a borrow on the stack. As soon as the function returns, there's no pinning.
So there's a few things that exist in this system:
* A GC-object references another GC-object, keeping the target alive while it is alive. A GC-object can be created by either Rust or JS. The loop you describe would be made up of GC-objects, so it would be straightforward to collect.
* A non-GC object has a permanent pinning reference to a GC-object. These are rare and purposeful.
* (Optional) A non-GC object has a weak reference to a GC-object, which can be collected at any time.
* Rust code has a temporary pinning reference to a GC-object on the stack, while traversing/manipulating it, and it goes away as soon as the function exits. It won't pin too long because the release is automatic. It won't free prematurely because the GC code knows the borrow is happening.
Yes you can donate to Mozilla Foundation. But no guarantee any such donation will actually fund Firefox development, as opposed to some completely unrelated non-technical project of theirs.
And in fact their FAQ for donations doesn't even mention Firefox under their "How will my donation be used?" section:
At Mozilla, our mission is to keep the Internet healthy, open, and accessible for all. The Mozilla Foundation programs are supported by grassroots donations and grants. Our grassroots donations, from supporters like you, are our most flexible source of funding. These funds directly support advocacy campaigns (i.e. asking big tech companies to protect your privacy), research and publications like the *Privacy Not Included buyer's guide and Internet Health Report, and covers a portion of our annual MozFest gathering.
I doubt this will work. Web browsers have an insanely large scope. Building a general purpose competitive web browser takes hundreds of full time engineers.
I can't imagine you can fund such a thing with donations.
You can tell they are a fly by night meme enterprise for not starting from a Mozilla fork.
Be realistic. For all bad mozilla foundation/corporation/toppahs did, the code is still open source and relatively free. If even something called IceWeasel almost had a shot at forking, the bar is pretty low.
Andreas has been doing this for a long time. The difference is that now he is openly shifting focus from the OS to the browser.
Having a fully new codebase implementing the web is a great thing.
IceWeasel was a completely different thing mainly based around mozilla trademarks for logos/names that clashed with the FOSS policies of linux distros when shipping non-upstream binaries.
I think it was meant to be a recovery project first, hobby second, community third. Then ladybird started showing more potential so his focus shifted there.
Sorry if I don't understand what you meant to ask.
A unix like os with user interface from the windows 2000 era that he could use as his daily driver at some point (instead of Linux). He said as much in some podcast I can't remember (probably cppcast).
That's what I don't quite get. I'm really wary of a "from scratch" web browser at this point. I looked at their project and their main selling point is that they're building both the rendering engine and the JS runtime from scratch "Driven by a web standards first approach" - what exactly does that mean? Firefox has always had that approach and web standards are more complex than they've ever been. I don't understand why not using code from other browsers is supposed to be a selling point when all the major browsers have open source rendering engines and runtimes and there's independent runtimes being built like Bun that they could use.
We're talking decades of features they have to support - unless they're planning on strategically dropping support for older unused/deprecated parts of the standard? Even in 2008 Google made the decision to use Webkit for their browser because they understood what an enormous undertaking it would be to write their own rendering engine. That was 16 years ago.
> I don't understand why not using code from other browsers is supposed to be a selling point when all the major browsers have open source rendering engines and runtimes and there's independent runtimes being built like Bun that they could use.
Th selling point is to have multiple implementations of browser engines. Currently we have three (gecko, webkit and blink, where blink is based on webkit and webkit is based on khtml). If you consider how much of the modern world is based on browsing standards it seems pretty self-evident to not have it depend on a few corporations.
Bun is a wrapper around JavaScriptCore (the JS engine used for webkit just like v8 is used for blink or node), so not at all an independent JS runtime and is not at all a browser.
> We're talking decades of features they have to support
If this is proven not to work because the standard has grow too big as you imply then we should absolutely look into either dropping old standards or slowing the pace we introduce new standards. This project is a litmus test for the web.
Seriously, why isn't there a legitimate Mozilla fork we can fund instead? There are a lot of addons that will take decades to emulate, like Sidebery, the main reason I switched to Firefox and am staying on cool until a good fundable Firefox fork (like Vivaldi for Chromium).
Mozilla wants web users to be targeted with online advertising and/or pay for online advertising not Firefox development.
Mozilla is an online advertising advocacy project. Just try suggesting to anyone from Mozilla the idea of web without ads. They will be 100% opposed, unwilling to even consider alternatives, as if they are being paid to defend this pro-advertising position. They are indeed being paid indirectly from the coffers of an advertising company.
"Free and open web" apparently means web open for advertising. The presence/absence of advertising on the web is a non-negotiable. Mozilla insists advertising is a must-have.
Why was the original internet free of ads before it went public. Are there more important uses for a computer network. ISPs privatised the financing for the network. We pay for internet. It is not free. Funding from advertising has never been a necessity.
But Mozilla argues advertising is 100% essential.
>But Mozilla argues advertising is 100% essential.
Citation needed. I realize they get a ton of money (probably most of their funding in fact) from Google, but still have they actually made such a statement? For now at least, they support ad-blockers a lot better than Chrome (because of Manifest v2).
While it doesn't directly say it, their acquisition announcement for Anonym (an ad/tracking company) comes about as close as you can by saying Anonym believes it (and implicitly they support the viewpoint)[0]:
> Anonym was founded with two core beliefs: First, that people have a fundamental right to privacy in online interactions and second, that digital advertising is critical for the sustainability of free content, services and experiences. Mozilla and Anonym share the belief that advanced technologies can enable relevant and measurable advertising while still preserving user privacy.
Which completely ignores non-profit uses of the web, which is interesting since they're a non-profit and all.
They've made similar statements in the past[1]:
> Advertisements pay for all those “free” services you love, as well as many of the products you use on a daily basis — including Firefox. There’s nothing inherently wrong with advertising
Which is of course true because they don't accept donations to fund Firefox despite people complaining that they want to be able to make such donations for years.
[0] https://blog.mozilla.org/en/mozilla/mozilla-anonym-raising-t...
[1] https://blog.mozilla.org/en/mozilla/the-future-of-ads-and-pr...
> even consider alternatives, as if they are being paid to defend this pro-advertising position.
There's no way they would manage to exist like a business with a multi million dollar a year CEO without all that sweet Google money. So they are totally beholden to advertising straight from the top down. It doesn't even matter who is at the top, the whole step setup guarantees it'll be one of the big business players.
Basically when they moved Firefox from a foundation to a corporation, this was pretty much inevitable. They don't even want our petty donations anymore. We can donate to the foundation's pet side projects but not too Firefox.
Google funds Firefox and Mozilla knows its purpose is to prevent regulators to looking at Chrome the same way they did at Internet Explorer.
People always say that like it is a problem.
I shit on Firefox every damn day, but that's because I'm a tech-brain(rot) weirdo. Truth is I absolutely love it. Firefox, or one of its derivatives, is the main (often times only) browser on every device I own. I literally wouldn't buy a device if I knew I couldn't install Firefox.
Right now, our options are a world without Firefox or a world where Firefox is supported by the dominant market player. Maybe that changes in the future? Maybe it doesn't. But a chance for a future that isn't just the children of KHTML can't happen if Firefox doesn't exist.
The obvious Apple in the 90s comparison comes to mind.
> But a chance for a future that isn't just the children of KHTML can't happen if Firefox doesn't exist.
TFA is about one such chance (and why it might be more donation-worthy), no?
It is, but we don't really know anything about Ladybird at this point. I hope for the best and wish Kling nothing but success. They have shown themselves as an exceptional and committed developer.
I hope for a future where I've got even more options, but right now, it's a baby project. Getting standards-compliant rendering working is step zero. Things like site isolation, hardware video acceleration, and extensions that have enough access but aren't running wild with permission are really where a browser in the modern world shows its metal. Not to mention multiplatform support.
An OS isn't just a kernel, and a browser isn't a just rendering engine.
Hey, ex-Mozillian here. For the old alt OS people, also an ex-NetPositive dev.
With that context, I'm on board with not giving money to Mozilla Corp. Late last year I cancelled my subscriptions to Pocket, the VPN, and recurring donations.
That said, I recommend that you support Servo instead of Ladybird.
Reason #1) C++ is just dumb in 2024 and choosing it is a big red blinking sign that the devs make bad decisions. Now they're considering a rewrite in a better language? So, starting again from scratch... No thanks!
Reason #2) Given the track record of the main author of being an ass to people who aren't willing to be marginalized, I don't have high hopes that he can lead anything as complex as a competitive browser. No, Serenity OS is nowhere near the same level of complexity thanks to el GOOGs insistence that the modern web includes every API found in OSes. Serial port access, really?
Anyway, please don't just jump on a hype train. Fund Servo.
Where is said track record of the main author being an ass to people who aren't willing to be marginalized, or anything along those lines?
> Please don't jump on a hype train
> Give capital to another project because C++ is "dumb" and Rust is not.
I applaud you for disclosing your biases at the top but I was so hoping the disclosure wouldn't be a spoiler for the rest.
> Given the track record of the main author of being an ass to people who aren't willing to be marginalized
That’s a quite strong accusation without any evidence.
How is Servo going these days? I didn't even know that Servo was still active, but judging on the blog (https://servo.org/blog/) it looks like a lot of recent development has been happening. Maybe it would help if Servo had an active browser implementation (beyond the downloadable shell).
What's the context for #2?
> Reason #1) C++ is just dumb in 2024 and choosing it is a big red blinking sign that the devs make bad decisions. Now they're considering a rewrite in a better language? So, starting again from scratch... No thanks!
Because modern C++ (e.g., using std::unique_ptr with std::make_unique() and RAII wherever possible) is safe enough, is getting safer with each iteration, is easier to learn for someone who already knows C or older (pre-11) variants of C++, and offers greater compatibility with the billions of lines of code already written in C and C++.
> Reason #2) Given the track record of the main author of being an ass to people who aren't willing to be marginalized
I was hesitant to even mention this, but not having to deal with demanding, danger-haired political agitators wielding their CoCs is enough of a reason for me to avoid Rust completely.
It feels like websites are not testing their sites on Firefox anymore.
Apple’s App Store Connect yesterday just won’t login anymore, tried Chrome and it works.
So many broken headers, weird fonts, overlapping elements, etc.
I wrote a extension for a janky old website I used frequently that is broken for Firefox.
It’s a simple js file, and I now have a couple dozen subscribers. A nice project.
When a site is broken, try using a separate profile to make sure that the problem isn't caused by any of your settings or extensions: https://support.mozilla.org/kb/profile-manager-create-remove...
If the problem persists, use this form to report it to Mozilla: https://webcompat.com/issues/new
The inability to fund Firefox development is completely baffling to me. The finances seem pretty obvious: Open up a fund for Firefox donations. Hire contractors under the non-profit to work on Firefox. When you have enough to pay a full time developer, hire one under the non-profit. Rinse and repeat.
If, as some claim, there isn't ever enough money to really fund development, fine, they've now proven that. But not even allowing it as a possibility is completely insane!
I'm left in a position where I'm assured repeatedly that the best way to fund Firefox development is to pay for a side project I have no use for like Pocket or their VPN and then hope that that payment doesn't get consumed paying for said side project or future side projects.
OP's thoughts were mine the day that the LBI was announced: finally there's a non-profit that is actually committed to maintaining browser diversity. It's just a pity that it's one that's starting from behind and not the existing non-profit whose browser at one point enjoyed a majority market share.
They may be starting from behind, but a clean slate might be to their advantage. It takes a distinguished dev to jump into an old, large scale project. Firefox and Chrome definitely meets both of those factors.
But how will the CEO get millions in compensation for running the browser into the ground while funding her side projects?
Oh sorry, she's chairwoman of the board now, completely different.
I can’t help but wonder where Firefox would be today if Brendan Eich had not been pushed out as CEO
Mozilla was in terminal decline in 2014 so pretty much in the same place as today. You'd have to go back to 2009.
Brendan Eich might not be the perfect CEO. But still I think he would have done better than Mitchell Baker did. He's interested in technology in a way in which she isn't.
Eich wasted effort on FirefoxOS because he doesn't understand business. Now he's a cryptogrifter.
FirefoxOS had potential to pick up the pieces from the outstanding WebOS. We could have seen continued funding for Servo as well.
The business model for FirefoxOS didn't make sense, just like the business model for WebOS didn't make sense. Android was cheaper than free to put on phones because Google was willing to share search revenue with carriers. They would not have done that on a FirefoxOS phone before it reached scale, nor would Microsoft, which was pushing its own phones.
Offering privacy first OS would make perfect sense.
I don't buy it. Apple owners pay premium prices for a perception of increased safety and convenience. I feel that way about what WebOS was. There is always market space available for a device people want.
You feel that way, and WebOS failed on phones.
HP played musical CEOs - 3 in less than a year - and one decided they shouldn't be in the phone or PC business. People loved the phones which were objectively years ahead of Android or iOS. It was not a product failure, but one of management.
People loved the phones, but they didn't buy them. The carriers didn't want to sell them because they don't get paid on the backend. As I said, the business model doesn't work.
The business model for webOS was the same as the one for iOS though. Make OS, put it on devices, sell devices. Sell apps.
FirefoxOS was simply dumped too early. You need TIME to advance in an established market and they simply didn't give it time. They wanted results within a year or two, but growth occurs organically in an occupied market.
In India, an entire telecommunications company was forced to use a fork - KaiOS for Reliance Jio phones because FirefoxOS was abandoned.
FirefoxOS was a terrific idea, but the baby needed time to grow up to teenage level, but was murdered soon after birth
A leader should unite an organisation. You can't lead an inclusive organisation and then cause divisiveness.
And don't forget, these things are not just cosmetic. Not being able to get married could lead to some serious consequences when having kids (e.g. a lesbian couple) and one partner dying.
Personally I would not have pushed to fire him, no, and I'm very pro-LGBTQ+. It was only a small donation compared to how much he makes and the legislation was easily defeated. But I don't work at Mozilla.
So how well did Mozilla do with an inclusive leader?
Well, not very well but it was clearly the wrong leader.
I'm not sure I'd call losing 95% of your market share well, but each to their own I suppose.
Mozilla has been doing terrible.
> And don't forget, these things are not just cosmetic. Not being able to get married could lead to some serious consequences when having kids (e.g. a lesbian couple) and one partner dying.
That is not true. California had domestic partnerships with identical rights and responsibilities as marriage starting in 1999. Eich opposed applying a term that, in his view, carried religious import. That's all.
is there any reason to think it wouldn’t look like Brave just with firefox instead of chromium?
Is there any reason that would be a problem? My main beef with Brave is that it's not really contributing to browser diversity.
Yes. Brave's crypto scam is a problem, and they've done some very controversial things in that regard. Like taking "money" on behalf of sites that didn't even participate.
I don't think the CEO matters. Their entire trajectory was probably fixed the instant Google decided to release a browser.
Yes. The purpose of Mozilla Org, from the perspective of the people paying for it (Google), was to kill Firefox. Mitchell Baker got rewarded because she did her job.
It's hard not to imagine Google giving a little wink as they hand over that check.
I don't think he would've done things differently really. He was also part of the same old guard and wasn't exactly aiming for some radical changes inside Mozilla. Imo one of the only things that could've made Firefox more relevant would've been to focus on an electron alternative, especially early on in 2013-14 as it would've been an entirely new "product segment", which could've made Firefox the standard engine for a lot of apps. But there's no indication that anyone high up at Firefox wanted to do something like that. It's a non-profit and non profits are rather conservative, for better or for worse.
You mean positron? https://github.com/mozilla/positron They did try to build that, and gave up.
They had XULRunner long before that, then of course they ditched it to pursue whatever crap they were pursuing that year.
What a great vision.
Yeah I heard about it, but I don't know why they gave up. There's a lot of stuff that could be done to improve on electron (especially back then), and Mozilla was in a nice position where they controlled their web engine (as opposed to electron), so they could've made a very solid product... anyways that's not happening now...
Edit: okay from what I understand in the blog, one of the reasons for abandoning it was that it was hard to keep up with the electron API changes and keep it compatible. That just goes to show that they were completely outplayed early on, otherwise they wouldn't have had to play catch up by merely being an electron shell around Spider monkey...
>But Tofino is dead (long live the Browser Futures Group!), and Electron compatibility isn’t essential for a viable Gecko runtime. It’s also hard, since Electron has a large API surface area, is a moving target, requires Node.js integration (itself a moving target), and is designed for Chromium’s process architecture, which is substantially different from Firefox’s.
He would have at least avoided getting distracted by every single liberal cause that popped up along the way and kept his focus on technology. You can complain about Brave's crypto stuff, but at least it was trying to solve a real problem with internet monetization instead of being whatever Colorways was.
Sure but that's just a symptom not a cause. Even without making Mozilla turn into a regular non profit that just happens to have a browser project (as opposed to a browser project non profit), the strategy they had just couldn't work.
Every monetization attempt failed (even with stuff centered around "privacy", a niche where Firefox is well known). I've seen numbers that indicated that the Mozilla foundation donations are almost equal to what they profit from their commercial products.
> Every monetization attempt failed (even with stuff centered around "privacy", a niche where Firefox is well known)
Again, though: they have yet to try the obvious, which is allowing people to donate to Firefox.
I have zero interest in supporting all the random distractions that Mozilla engages in, but if they gave me a donation box for Firefox specifically I'd set up a recurring payment today.
They can't in good faith claim to have tried every monetization method when they have never let users earmark funds for Firefox.
Money is not the Problem with firefox https://preview.redd.it/r9q69xop8n6d1.png?auto=webp&s=59a1d3...
This diagram should be zero-aligned at the very least.
This is misleading. Firefox does not have a CEO, Mozilla does. The Mozilla CEO/chairperson is responsible for many more projects than just increasing the market share of Firefox — whether nerds on Hacker News think that’s what Mozilla should be doing or not is another conversation.
Sure, but their main project still is Firefox, by far. That's the project that has the most impact too. How successful are they with their side projects, anyways?
> That's the project that has the most impact too.
How do you measure impact? If it's income created for Mozilla Corp then I agree it's impactful too, and the CEO's pay does seem justified.
> How successful are they with their side projects, anyways?
Honestly I don't know, I haven't looked at their latest annual report. I do pay for Mozilla VPN, although I'm not a Firefox user.
$75 million per year from subscriptions and ads, according to their latest report (2022 for some reason). Another commenter did some quick math to try to prove that donations were fruitless and found that Firefox could reasonably expect to replace that revenue with a donation box:
https://news.ycombinator.com/item?id=40901664
So in other words: the side projects aren't successful enough to justify not accepting donations.
I'm not opposed to a donation box at all, I'd donate myself even though I don't use Firefox.
So what else is it that she did do so amazingly well?
According to this comment† from the very same post on Reddit:
> [Mozilla] in 2018's cash flow was negative ~1 million dollars while in 2022 it actually profited ~167 million.
A reply to that comment‡ states the following:
> Also important is that if you look at their annual reports, while it's still the most significant revenue source, the percentage of revenue coming from search engine royalties (i.e. Google) has been steadily going downwards. Instead revenues from their other services (VPN, Pocket, etc) had been increasing steadily.
And indeed we can verify those numbers on Wikipediaᵃ, where we see "Revenue derived from Google" trending downward every year.
So it seems she's been A) successful with continuing the search engine deal with Google; and B) increasing revenue from their other services (VPN, Pocket, etc.) so that Google's contribution to the revenue pie chart slowly shrinks over time.
† https://www.reddit.com/r/dataisbeautiful/comments/1dg7ejv/co...
‡ https://www.reddit.com/r/dataisbeautiful/comments/1dg7ejv/co...
ᵃ https://en.wikipedia.org/wiki/Mozilla_Corporation#Finances
Donations are a way to buy influence. Just wait until they receive a generous donation from M. Soft.
And that situation would be worse than the current one, where 80% of their revenue comes from their only serious competitor?
Their primary “donation” is Google. They’re focused on virtue signaling values instead of real work.
It’s a fantasy land. I was there for awhile.
I would imagine that there is caution about becoming beholden to user donations to continue operations. Such a situation would give users a measure of effective voting power in the development of the browser.
If you were starting a project from scratch I could see that as a valid concern, but the current world is one where 80% of the funds to pay for Firefox comes from Google. No one can seriously argue that becoming beholden to your users is a worse situation than becoming beholden to your primary competitor.
>No one can seriously argue that becoming beholden to your users is a worse situation than becoming beholden to your primary competitor.
The C-level execs getting their salaries off that Google money can!
Hypothesis: They are paid (by Google) to keep Firefox unpopular.
I don't think so, but close. I think they're indirectly paid by Google to keep Firefox around as a token competitor for antitrust purposes. I'm sure that's what the "search deal" is really about. Because Google already owns the search market, they don't have to pay for it.
However with falling marketshare there comes a point that when that won't fool regulators anymore. And then there's no point for Google to keep paying.
I would present that situation as evidence that the "competition" isn't really a serious one. But perhaps I am ignorant.
It seems more likely to you that Google isn't serious about Chrome's dominance than that they're totally serious about it and are using Firefox as a guard against antitrust and using their funding of Firefox as leverage to get Mozilla to cave?
>Such a situation would give users a measure of effective voting power in the development of the browser.
Yes, better give it to Google and golden-parachuting C-level execs
That's the same situation basically any for-profit company with a paid product is in, is it not? If people don't like your product or don't see a future in it they will be less willing to pay for it (or donate for it). How is that bad?
That's the difference between profit and rent: the optionality of the product.
As opposed to being dependent on Google. Which is your main competitor. Galaxy brain move from the brain trust at Mozilla, sorry I mean Mozi//a.
Why that is unacceptable; so give it all to Google?
> The inability to fund Firefox development is completely baffling to me.
It's hard to imagine that it's for a reason other than "Google wants it that way".
You can fund Firefox by pooling money and pay a developer or a company like Igalia to implement a feature you want. It's not trivial, but given the number of people on HN that claim they would pitch in, someone should really try that.
Folks on HN are good to talk the talk but not really to walk the walk. Not only they could give to developers or company like Igalia but they could also get a Firefox Relay/VPN subscription. They don't even need to use it and their money is going to be 100% profit for MoCo. Also, if we are realistic, the total money in donation that Mozilla could get would probably represent a drop in the ocean compared to their annual budget and the amount of money you need to develop a (complete) browser. It's way more complicated than creating yet another chrome skin.
> their money is going to be 100% profit for MoCo
If you can provide a citation for this claim I'd get a subscription today. I don't pay for their side projects because I don't want them to take it as a signal of demand for VPNs, but if it's truly 100% profit I'd be willing to risk it.
> Also, if we are realistic, the total money in donation that Mozilla could get would probably represent a drop in the ocean compared to their annual budget and the amount of money you need to develop a (complete) browser.
People keep saying this, but given that it's never been tried you have no proof. And even if it were, what harm is there in opening up one more option for those of us who want to be really clear about what we're paying for?
> If you can provide a citation for this claim I'd get a subscription today. I don't pay for their side projects because I don't want them to take it as a signal of demand for VPNs, but if it's truly 100% profit I'd be willing to risk it.
Fair enough. They publish their annual financial report but it isn't splitted per project so it's hard to know for a fact with the public information we have access to. However, it isn't unreasonable to think that at the very least a percentage of the smaller products revenues are reinjected elsewhere in the organization (e.g Firefox) since the goal seems to be to diversify their income sources.
> People keep saying this, but given that it's never been tried you have no proof. And even if it were, what harm is there in opening up one more option for those of us who want to be really clear about what we're paying for?
It's been tried over and over in the FOSS community. Few projects are able to get decent money with donations (e.g. Thunderbird). However, it's nowhere near the complexity of a web browser.
For example, Thunderbird made almost $7M (USD) in 2023 for an average of $20 per donation which is 350k users out of 20M monthly active users [1]. Firefox has 10 times that number of users so we could estimate that they'd make $70M/year. That's far from $500M/year they're doing right now.
[1]: https://blog.thunderbird.net/2023/05/thunderbird-is-thriving...
$70m is just $5m shy of their entire "subscription and advertising revenue" line item, with none of the extra cost of getting that revenue. Your back-of-the-napkin math would suggest that donations could render all of Mozilla's for profit side projects unnecessary and allow them to focus that energy exclusively on the browser. What's not to love?
You're comparing the success case of donations against the failure case of profit side projects.
As I said above, if it's a failure, fine, at least they tried. Knowing that it's possible to replace the side projects with a better model why would they not at least try?
I don't want a single feature, I want a guarantee that Firefox will receive consistent maintenance over time and won't be influenced by Google's opinions about what the web should become. A small monthly donation helps with that in a way that feature sponsorship doesn't.
Why do you believe that a monthly donation will help against Google influence on the web more than dedicated feature work? That seems backward to me.
Yeah right, you're basically talking about a fork because nobody can force upstream to go along with your plan. There are already several forks of Firefox. We don't need more.
No I'm not talking about a fork. There are many things the team at Moco just has no time to work on and will happily welcome contributions.
I'm saying you can't independently fund whatever features you desire without a fork, because upstream is under zero obligation to accept your contribution. They may have a conflicting vision of where development needs to go, or simply be unwilling to assume the risk of taking your contribution.
Implementing a whole ass new W3 spec is not something for a single contractor working on donations to do. That's a recipe for never finishing.
Mozilla isn't incapable of funding Firefox. It's just that they get most of their funding from Google, and thus they will never be allowed to break free or dominate the browser market again. That is, unless Google gets out of the browser business, which will probably never happen.
There must be some sort of cultural virus attached to Firefox that it has to make money as a commercial entity. Firefox was born from Netscape, a for-profit closed-source project, and while they lost the closed-source aspect of it, the executive class at Mozilla don't want to give up the for-profit segment.
Yeah, only if the Mozilla foundation was run by the engineers
Why is Ladybird getting so much attention. Has anyone herd of servo? They're trying to offload css rendering to the gpu. That could be a big deal in the long run.
https://servo.org/
Because ladybird is a browser, servo is a component of a browser. It could well be that Ladybird ends up using servo as a component.
Although I am stocked about the new browser getting all the attention it deserves, isn't chromium still the most secure browser to use? How long will Ladybird take to be as secure as chromium?
You can run your browser in a VM if you're concerned about its security so much.
VM is not a solution to this. You can call it as a bandaid if you intend to use an insecure browser
Why do you say it's the most secure browser?
A bit funny, I donated and got redirected to https://ladybird.org/thanks.html which is a 404.
"Thanks but no thanks"
Here you go :)
https://github.com/LadybirdBrowser/ladybird.org/blob/336f892...
Feeling the same about emacs. Id like to donate to emacs, but the only option is to fund fsf instead. Last I checked.
Funding Servo is another good option: https://servo.org/sponsorship/
Isn’t servo Mozilla’s cancelled browser project? (Genuine question)
Yes. It now has a life of its own.
It moved to the Linux Foundation in 2020[0] and has been getting active development since about 2023[1].
I guess I should also add that it is just the rendering engine, not a full browser
[0] https://servo.org/blog/2020/11/17/servo-home/
[1] https://servo.org/blog/2023/01/16/servo-2023/
Second this. I'd much rather see more funding for a safer and secure browser than yet another browser that will have the same C and C++ memory corruption vulnerabilities again.
The FAQ at the bottom of https://ladybird.org/ has this easily-overlooked section:
> However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
So it looks like there's a plan to refactor away from C++ as it spreads its wings. I'm in favour of people funding any browser engine with a realistic shot at viability.
I think Ladybird and Servo are exceptionally interesting projects and am so happy they exist. Despite being my daily driver, Firefox has its problems, and they regrettably mostly stem from the Mozilla foundation. Supporting a future with an ecosystem of FOSS browsers that aren't owned by an advertising company is very exciting.
Not only that, but Servo is only receiving less 3000 USD/month in donation, less than their goal of 10k/month, and much less than what they deserve if consider Ladybird is receiving millions.
https://servo.org/blog/2024/06/28/input-text-emoji-devtools/
How did you figure Ladybird is receiving millions?
They likely meant just one million USD + other smaller donations.
https://news.ycombinator.com/item?id=40856791
would be neat if ladybird ended up depending on and helping fund servo. that would fit both projects' missions - servo could continue focusing on the rendering engine and ladybird could get to outsource effort on that part of the code.
I know they didn't do this on purpose and it was because it started as part of SerenityOS, but I'm unexcited by this project because it's written in C/C++.
Rust was literally invented to solve the security and concurrency issues inherent in using C/C++ for a browser engine. You could argue that's the one use-case where it is objectively the best language to use. It's so valuable for that purpose that every large company has rewritten at least some crucial components in Rust.
I also think Rust will be one of the only languages strict enough to enable the use of AI-generated code without compromising security. I certainly don't want AI-generated code for high-security applications, but there's nothing we can do to stop it at this point.
I believe the team has said they are currently evaluating different languages, though they have not divulged which ones. From the FAQ on the Ladybird website:
"We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages."
I assume it's either Rust or Jakt (the latter a language in development by the Ladybird lead dev), though I suppose Swift might be on the table.
Creating a new language is almost as insane as building a browser engine. I do not expect this to become a viable browser regardless, but I guarantee it'll fail if they use their own new language for it.
Rust is great in theory. But idioms are still being teased out and it hasn’t been used on anything with more code than servo afaik.
C/C++ is arguably the safer choice in terms of actually completing and maintaining a project of this magnitude.
> it hasn’t been used on anything with more code than servo afaik.
It very much has.
Name them, then.
I do like Rust, but I've only come across a few "higher profile ish" projects. None were really that important or useful that I actually bothered to remember them.
Companies like Amazon, Facebook, and Cloudflare have millions of lines of Rust code running in production.
Don't forget Microsoft.
Windows 11 kernel will soon be booting with Rust inside (https://news.ycombinator.com/item?id=35738829)
Microsoft seeks Rust developers to rewrite core C# code (https://news.ycombinator.com/item?id=39240205)
I only left them off because we’re talking about size here, and I don’t know how much code that actually is. I am a Windows user, so I’m quite excited to have Rust in my kernel! But as far as I know it’s just one small bit, with more to come!
You're replying to Steve Klabnik, co-author of the Rust book [0] and (previously) a core team member for years. If he says it's been used on big projects I'd be inclined to believe him.
Note that it's likely that some of the biggest applications aren't public and so even if identified you couldn't actually count the lines yourself.
[0] https://doc.rust-lang.org/stable/book/
What he said is true, AWS uses Rust heavily in some of AWS core systems https://aws.amazon.com/blogs/devops/why-aws-is-the-best-plac....
Some of the open source projects you can find are AWS Firecracker https://github.com/firecracker-microvm/firecracker and Cloudflare Pingora https://github.com/cloudflare/pingora
> I've only come across a few "higher profile ish" projects
Of course, your mind is biased towards things that have existed for years before Rust gained traction. Those codebases aren't necessarily going to be rewritten overnight (if at all) in Rust. Others have mentioned it, but tech companies are writing foundational software with Rust, check out Cloudflares repository list for example:
https://github.com/orgs/cloudflare/repositories?q=language%3...
C++ is an awesome language for this. Even Firefox isn't all Rust. Do you think it's wise to use tech controlled by your main competitor?
> Do you think it's wise to use tech controlled by your main competitor?
Mozilla doesn't control Rust, and why would it matter? What is your disaster scenario here? What would Mozilla do to sabotage Ladybird?
At this point, Ladybird has no competitors because it is not much more than a hobby project. It isn't usable yet.
Friends of Mozilla certainly control Rust, and it is not outside the realm of possibility for Rust to switch to an awful license. It may be a bit much to suppose that Rust devs would sabotage Ladybird but certainly there is a potential conflict of interest that should be looked at.
>At this point, Ladybird has no competitors because it is not much more than a hobby project. It isn't usable yet.
Whether or not it is usable is a temporary technical issue. It absolutely is a contender for mindshare. Lots of people want a browser that isn't controlled by a nefarious advertising megacorp, and Firefox is about the only game in town. That is hopefully going to change.
> Friends of Mozilla certainly control Rust
Like who?
Anyway, it would be a good thing anyway because "friends of Mozilla" are likely some of the most dedicated FOSS people working in software.
> it is not outside the realm of possibility for Rust to switch to an awful license
It is absolutely outside the realm of possibility. It is as impossible as Python or any other major language doing it. Millions of lines of Rust are in production at for-profit and non-profit orgs, as well as in FOSS projects.
Even if they did it, Rust would be immediately forked and continue as it was before under a different name.
> Whether or not it is usable is a temporary technical issue.
I disagree. It is a long-term technical issue, because every viable browser engine so far has had many millions of person-hours put into it. Ladybird isn't close and likely never will be.
> Rust was literally invented to solve the security and concurrency issues inherent in using C/C++ for a browser engine.
Are most browser vulnerabilities not still found in engines like V8? Rust can help with something like last year's buffer overflow in libwebp (although that's overkill when a project like https://github.com/google/wuffs exists), but I'm unclear on how it gets you a better JIT.
AIUI, Servo has been a failure because Rust is not very good at this problem domain. Browsers have to deal with circular references and this is easily handled in C++.
Hopefully someone who knows more will explain this better
Rust has memory-safe handling of circular references, but it can also be done with "unsafe" blocks.
It's (much) more involved than using C++, but that's a worthwhile tradeoff for something as important as a browser engine.
More info: https://eli.thegreenplace.net/2021/rust-data-structures-with...
if you ever write the words "unsafe" in a rust codebase, and you are not directly needing to poke bits on some hardware, you are doing it very, very wrong.
good link you shared. i personally always went with option 2 he presents.
This kind of dogmatism is why people think Rust will be impossible to adopt. All `unsafe` means is that the code inside the block doesn't have Rust's guarantees and should be inspected extra carefully by hand, much the same as you'd ideally inspect every single line of C. If sprinkling `unsafe` everywhere allows an organization to quickly adopt Rust's guarantees elsewhere and they're aware of that caveat (hard not to be given the naming) that can only be a net improvement over doing the entire thing in C.
You can always go through and systematically remove unnecessary `unsafe` later if needed, but there's no need to do so upfront if that would prevent adoption.
there's literary two other patterns on the one example in this thread...
refactoring those unsafe will never happen in the kind of place that put them in place to begin with.
My concern with Ladybird is the long timeline to deliver the alpha version. I think the development strategy should be discussed in the community because there could be good ideas to speed up the process.
If you subscribe to Firefox services isn't that also funding Firefox?
Hopefully, but you can only hope. My fear is that when people are crunching the numbers at Mozilla they'll see that Pocket (or whatever) is doing well and funnel resources to that, unable to distinguish between people who like Pocket and people who just want to help Firefox out.
Giving me a donation box to pay for Firefox means that I can be very confident that they are getting the right message from my dollars. But for some reason they are very reluctant to do that.
Glad to see this challenge to the powers that be and the status quo.
chromium is open source - have chromium standards set by a foundation instead of google. then funded by grants / taxes. etc
and let the market work.
browsers are a common utility, like water, internet etc - n should be treated the same.
>let the market work.
Chrome is a punch in the face by the invisible fist of the market.
I think you want:
https://github.com/ungoogled-software/ungoogled-chromium
Without signing in to a Google Account, Chromium does pretty well in terms of security and privacy. However, Chromium still has some dependency on Google web services and binaries. In addition, Google designed Chromium to be easy and intuitive for users, which means they compromise on transparency and control of internal operations.
ungoogled-chromium addresses these issues in the following ways:
- Remove all remaining background requests to any web services while building and running the browser
- Remove all code specific to Google web services
- Remove all uses of pre-made binaries from the source code, and replace them with user-provided alternatives when possible.
- Disable features that inhibit control and transparency, and add or modify features that promote them (these changes will almost always require manual activation or enabling).</i>
This relies on both googles funding of chromium and the free work of people contributing to this repo.
The parent comment (and this whole post) is mostly about the funding of browsers.
fund the right browser/codebase.
If you were to fund, say chrome, you might waste your money.
Might be similar to funding firefox, which has lots of telemetry baked in. Unless you could fund a "no-telemetry firefox", or a version of firefox with easy to implement self-hosted firefox sync and auth.
Do you not read the articles or the title or the comments before replying?
Another comment brough up memory safety. I'm surprised myself that the project is moving forward without using a memory safe language at its core. A browser is a huge attack surface and all the example I know point to a necessarily enormous code base.
I understand the project started as a hobby, and anyone who wishes to be involved has their own prerogative, but I'd have a hard time getting behind it myself.
All the major operating systems these browsers are running on, are written in c and c++.
How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language?
> How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language?
It turns out actually pretty effectively? There are going to be more bugs and boundary issues of the OS, but memory unsafety isn't some goop that oozes into your runtime.
Yeah just a hyperbole.
My point is, people act like anything built with non memory safe languages is shit ever since Rust became the Jesus. We have the actual operating systems written in C, working ok. It is fine.
Yeah maybe Rust would be better but it is not a magic bullet and memory safety comes with many caveats in design of the code and possible performance issues when you are building something low level like a browser.
Right, or equivalently, you can rely on the million eyeballs and the million developer-years poured into those OSes, while developing your project with a much smaller team.
In many cases, you'd need to escape the browser before exploiting the OS itself. Security is not an all or nothing, layers and layers are effective at mitigating or increasing the time it takes for exploit to work. For instance ASLR is absolutely not a bulletproof solution, but many exploits are order of magnitude more complex to execute when enabled.
In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
My remark was a little more abstract and frankly, absurd though.
I mean, the most memory safe language will invoke syscalls. It will ask for memory pages and stuff. If we assume the app is running on a pile of shit because the OS is written in C, how can we be sure that the language is memory safe?
I understand the value of memory safe languages but people bashing on C/C++ code does not make sense to me when everything is essentially running on C. That’s all.
> In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
This made me curious about something. Has there been many exploits stemming from JavaScript engines? I honestly do not know but as far as I can tell, most of the issues originate from faulty image decoders screwing up memory and tls implementations etc.
AFAIK most of modern web browser vulnerabilities come from JavaScript engines.
A memory safe language may force you to think about memory safety, but it can also work as a straightjacket that makes it more difficult to think about other security issues.
Seems other way around. Since you can focus more on other security issues instead of memory safety and other security.
No, because the memory safety part comes at a cognitive cost.
You may be right if you're talking about a GC'ed language, which gives memory safety and at the same time frees up the developer's mind. But if you're talking about constructs like borrow checkers then they do add cognitive load that is perhaps better spent elsewhere.
I've not found this to be my experience; if anything, working in Rust has freed me to think about other aspects of security in my project since I don't need to spend all my effort applying extra tools to find segfaults. Do you have an example?
Do you know that memory safety is relevant for security, compared to other causes of exploits? Or are you just guessing?
The developer of curl has done an analysis of what percent of his CVEs would have been avoided in a memory safe language. I think the answer was a bare majority.
As a very relevant example, Chrome found that 70% of their serious security bugs were memory safety bugs. 36% of them were use-after-free.
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
It's been discussed at length multiple times. This should be enough to get you started on further research:
https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...
> ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues
From https://ladybird.org (not some subpage, but literally on the main page):
Why build a new browser in C++ when safer and more modern languages are available?
Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.
However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
It’s not as simple as “just” using a memory safe language.
The languages that are memory safe either impose too much of a straightjacket to be productive (Rust), don’t give you a GC or a memory safe way of writing one (Swift, Rust), or give you a GC with the wrong semantics (Java, Go, etc). Yes, the browser needs to have a GC. No, there’s no way around that.
I’m not saying it can’t be done - but there are good reasons to stick with C++ to get this job done. Not an ideal situation but it’s where the world is at.
Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.
GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.
It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
That's not what happens in the browser at all.
The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references).
The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics.
So, maybe there is code out there where the GC can be an island. The browser is not that.
Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API.
And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
Doesn't Rc already demonstrate that kind of accounting?
You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.
It’s possible with RC but not GC.
GC != RC.
A type system can let you say things like “make sure someone finds out when I assign this pointer”. But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes). GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).
> GC != RC.
I am aware.
> But that’s not what GC wants, unless (as I said before) you’re happy with your non-GC heap pinning objects (the browser isn’t, but some GC clients are, sometimes).
I can't figure out exactly what you mean here. Temporary pins on the stack should be fine, and I don't see why anything else would be necessary.
> GC wants a guarantee like: you cannot have a pointer in any data structure unless that data structure can be found by GC, and when it is found, make sure to respond to the GC’s request to scan it. That ends up being hard to do with any type system, unless that type system only allows objects to be allocated by that GC and the abstraction sits in the compiler/runtime below the type system (like in Java, Go, and Fil-C).
Doing heap allocations through the GC doesn't sound very hard. And why does it need to be below the type system?
Maybe instead I should ask you what the already existing GC libraries for Rust get wrong? Do they require users to be unsafe or do something to break safety? Are they unusable to implement javascript?
> I can't figure out exactly what you mean here. Temporary pins on the stack should be fine, and I don't see why anything else would be necessary.
The browser has a whole native heap (i.e. C++ objects, in current impls) that participates in the JS GC heap as follows:
- If the C++ object is referenced from C++ or from JS, it must be kept alive.
- If the C++ object references a JS object, then the JS object must be kept alive, so long as the C++ object would have been alive per the previous rule.
- It's possible for an object reference chain like JSobject->C++object->C++object->JSobject, and let's assume there are no other pointers to the C++ objects, in which case the last JS object should kept alive by GC only if the first JS object is alive.
- It's possible for dead reference cycles to exist like JSobject<->C++object, in which case both should die.
This requires that C++ has the ability to place references to JS objects in C++ fields.
This is where pinning comes in. It would be quite simple (and memory safe) but also totally incorrect (i.e. massive memory leak) to say that if a C++ field points to a JS object, then the GC just sees that field as a root. This is what I mean by pinning. (Note that "pinning" has many meanings in GC jargon; I'm using the Hermes version of the jargon. I guess I could have said "strong root" or something, but that's weirder to say.) This would be wrong, since it would not allow us to collect the dead cycle at all. Dead cycles are a common case in the browser. It would also cause other subtle breakage.
So, what the browser does instead is to have the C++ heap participate in GC: every C++ object that could possibly store a reference to JS objects anywhere can respond to GC callbacks asking it to account for all of those references. And, every C++ object needs to have a story for being referenced exclusively from JS, exclusively from C++, or a combo of the two. And the C++ code needs to be able to participate in whatever barrier discipline is necessary to get generations or incrementality or concurrency that the JS heap wants.
There are different ways to do this. Blink's Oilpan is probably the most principled, and that's basically a whole GC-for-C++ framework - very complex stuff. So, tons of inherently not-memory-safe code on the browser side just so it can do business with the JS heap.
I'm trying to figure out where our understandings differ, since that generally sounds familiar and reasonable to me. I guess you're assuming the callback/accounting code needs to be unsafe or able to violate the GC's preconditions? But I don't see why you assume that. As part of the GC, build some data structures that can handle that accounting and present a safe API, then use those data structures anywhere you don't want to create a root. When the browser code accesses the contents, barriers can be applied automatically.
The hard part of using a data structure like that is giving it ownership of the data and control over destroying it, but Rc does that too, doesn't it? That kind of thing is why I mentioned Rc. The difference between Rc and GC is much more in the behind-the-scenes tracking than in the API it gives.
> I'm trying to figure out where our understandings differ, since that generally sounds familiar and reasonable to me. I guess you're assuming the callback/accounting code needs to be unsafe or able to violate the GC's preconditions? But I don't see why you assume that. As part of the GC, build some data structures that can handle that accounting and present a safe API, then use those data structures anywhere you don't want to create a root. When the browser code accesses the contents, barriers can be applied automatically.
If this code was all written in Rust, I could imagine there being almost no uses of `unsafe`, except for one: the thing where the GC decides to delete an object.
But this means that all of that code that isn't marked `unsafe`, but instructs the GC about what objects to mark or not, is really super unsafe because if it makes a logic error in telling the GC what to mark then the GC will delete an object that it should not have deleted.
So, the problem here isn't that you can't wrap the unsafe stuff in a safe API. The problem is that even if you do that, all of your seemingly-safe code is really super unsafe.
> The hard part of using a data structure like that is giving it ownership of the data and control over destroying it, but Rc does that too, doesn't it? That kind of thing is why I mentioned Rc. The difference between Rc and GC is much more in the behind-the-scenes tracking than in the API it gives.
The difference between RC and GC is exactly in the fact that the API they give is radically different. And that the behind-the-scenes tracking is different, too.
It's totally valid to tell RC "I want to point at this object so keep it alive".
But that's not the API that the GC will give you, unless it's a pinning API. The API where you tell the GC "keep this alive" will prevent the deletion of the garbage cycles I mentioned earlier.
So, the GC (in the case of something like a browser) gives a different API: one where user code either marks something, or not, at its discretion. There's no easy way to make that safe.
> But this means that all of that code that isn't marked `unsafe`, but instructs the GC about what objects to mark or not, is really super unsafe because if it makes a logic error in telling the GC what to mark then the GC will delete an object that it should not have deleted.
By putting it in a GC structure, it would be giving ownership to the GC, and would borrow it back to use. So whenever it's not borrowed, it's safe for the GC to delete it. And the GC won't delete anything outside of its control.
If you have a logic error and prematurely delete, then attempting to borrow the object will return None, which is still safe.
> It's totally valid to tell RC "I want to point at this object so keep it alive".
> But that's not the API that the GC will give you, unless it's a pinning API. The API where you tell the GC "keep this alive" will prevent the deletion of the garbage cycles I mentioned earlier.
The idea is that any pointing/pinning you do while manipulating an object would be a borrow on the stack. As soon as the function returns, there's no pinning.
So there's a few things that exist in this system:
* A GC-object references another GC-object, keeping the target alive while it is alive. A GC-object can be created by either Rust or JS. The loop you describe would be made up of GC-objects, so it would be straightforward to collect.
* A non-GC object has a permanent pinning reference to a GC-object. These are rare and purposeful.
* (Optional) A non-GC object has a weak reference to a GC-object, which can be collected at any time.
* Rust code has a temporary pinning reference to a GC-object on the stack, while traversing/manipulating it, and it goes away as soon as the function exits. It won't pin too long because the release is automatic. It won't free prematurely because the GC code knows the borrow is happening.
https://foundation.mozilla.org/en/donate/ ???
Yes you can donate to Mozilla Foundation. But no guarantee any such donation will actually fund Firefox development, as opposed to some completely unrelated non-technical project of theirs.
And in fact their FAQ for donations doesn't even mention Firefox under their "How will my donation be used?" section:
At Mozilla, our mission is to keep the Internet healthy, open, and accessible for all. The Mozilla Foundation programs are supported by grassroots donations and grants. Our grassroots donations, from supporters like you, are our most flexible source of funding. These funds directly support advocacy campaigns (i.e. asking big tech companies to protect your privacy), research and publications like the *Privacy Not Included buyer's guide and Internet Health Report, and covers a portion of our annual MozFest gathering.
Mozilla Foundation != Mozilla Corporation, so donations go where the Foundation wishes, not to Firefox development.
This is clearly explained in the article. The Foundation doesn't develop Firefox and can't transfer donations to the Corporation, which does.
The "What we do" page doesn't even mention Firefox...
https://foundation.mozilla.org/en/what-we-do/
All hackers should understand this and use at least Firefox. Otherwise you are failing your duty of keeping hacking alive.
I doubt this will work. Web browsers have an insanely large scope. Building a general purpose competitive web browser takes hundreds of full time engineers. I can't imagine you can fund such a thing with donations.
If you actually go give it a try, it's working fine. Not sure what all the hate is about.
You can tell they are a fly by night meme enterprise for not starting from a Mozilla fork.
Be realistic. For all bad mozilla foundation/corporation/toppahs did, the code is still open source and relatively free. If even something called IceWeasel almost had a shot at forking, the bar is pretty low.
Andreas has been doing this for a long time. The difference is that now he is openly shifting focus from the OS to the browser.
Having a fully new codebase implementing the web is a great thing.
IceWeasel was a completely different thing mainly based around mozilla trademarks for logos/names that clashed with the FOSS policies of linux distros when shipping non-upstream binaries.
He is great and the project is awesome. But please, do tell me the goal of serenityOS?
I think it was meant to be a recovery project first, hobby second, community third. Then ladybird started showing more potential so his focus shifted there.
Sorry if I don't understand what you meant to ask.
A unix like os with user interface from the windows 2000 era that he could use as his daily driver at some point (instead of Linux). He said as much in some podcast I can't remember (probably cppcast).
No. He said it was occupational therapy. The goal was relaxed coding, not achieving anything at all.
That's what I don't quite get. I'm really wary of a "from scratch" web browser at this point. I looked at their project and their main selling point is that they're building both the rendering engine and the JS runtime from scratch "Driven by a web standards first approach" - what exactly does that mean? Firefox has always had that approach and web standards are more complex than they've ever been. I don't understand why not using code from other browsers is supposed to be a selling point when all the major browsers have open source rendering engines and runtimes and there's independent runtimes being built like Bun that they could use.
We're talking decades of features they have to support - unless they're planning on strategically dropping support for older unused/deprecated parts of the standard? Even in 2008 Google made the decision to use Webkit for their browser because they understood what an enormous undertaking it would be to write their own rendering engine. That was 16 years ago.
> I don't understand why not using code from other browsers is supposed to be a selling point when all the major browsers have open source rendering engines and runtimes and there's independent runtimes being built like Bun that they could use.
Th selling point is to have multiple implementations of browser engines. Currently we have three (gecko, webkit and blink, where blink is based on webkit and webkit is based on khtml). If you consider how much of the modern world is based on browsing standards it seems pretty self-evident to not have it depend on a few corporations.
Bun is a wrapper around JavaScriptCore (the JS engine used for webkit just like v8 is used for blink or node), so not at all an independent JS runtime and is not at all a browser.
> We're talking decades of features they have to support
If this is proven not to work because the standard has grow too big as you imply then we should absolutely look into either dropping old standards or slowing the pace we introduce new standards. This project is a litmus test for the web.
Seriously, why isn't there a legitimate Mozilla fork we can fund instead? There are a lot of addons that will take decades to emulate, like Sidebery, the main reason I switched to Firefox and am staying on cool until a good fundable Firefox fork (like Vivaldi for Chromium).