I think everyone who has followed the industry for long enough knows that if Chromium is the only option then Google will abuse it some way or another.
For now at least there exist two other teams outside of Google that knows how to create browsers and two working codebases so one doesn't have to start from scratch.
It doesn't even need to be the only option; Manifest V3 (making adblockers impossible) already exists.
I think it's very clear that adblockers are still possible in MV3, despite concerns.
https://chrome.google.com/webstore/detail/adguard-adblocker-...
https://chrome.google.com/webstore/detail/ublock-origin-lite...
Regardless, the point about a Google-only web resulting in restrictions stands even without that: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
The Browser Launch feature says that Firefox always waits for extensions to load network requests whereas Chrome gives an option to wait via a setting. So in this case, you're trading performance (parallelizing the work) for privacy (may not catch a tracking request). It's a tradeoff I'm sure many are willing to make, but I like that Chrome offers the setting. I tend to err towards performance, myself.
WebAssembly says it isn't used - not because it isn't available - but because it would add an extra permission to the manifest. That is to say, Chrome informs you of this when installing extensions and Firefox doesn't. That's a minor implementation detail at best, and I think a case can be made that providing more granular scopes is a positive thing.
Then pre-fetching. Are they really disabling a major performance feature by default? I've used pre-fetching to good effect when the browser's resource scanner ran at the wrong times. The option should exist but this is a terrible default.
The other features are more reasonable. HTML filtering could be useful for adversarial sites like Twitch.tv that actively fight adblockers. Storage Compression seems like a useful optimization if you have a lot of extensions installed that populate IndexedDB. I'm assuming it's caching those values rather than doing a "first time setup" every time a new private window is launched.
I'll readily admit there may be more intent behind these features than is expressed in these blurbs, but on initial glance I wouldn't say anything here is critical. The pre-fetching one in particular seems like a negative.
And where will Mozilla get the funds to pay for this project. From "tech" company (Google) ad services revenue of course.
Mozilla will feed its users' web searches to Google, take millions of dollars in return, and then use it to free us from "tech" company tyranny.
Hold on. What.
Under the current arrangement, Mozilla cannot survive without "tech" companies. They have no other viable source of funding. Before Google, it was Yahoo.
This headline sounds like it came from The Onion. Something like "Phillip Morris to explore healthy tobacco alternative".
Mozilla announcements seem to presume that their audience are complete morons who will believe anything.
function Accept_Designated_Firefox_Donation( $Amount ) {
$Firefox_Designated_Budget_Allocation += $Amount;
$Firefox_General_Budget_Allocation -= $Amount;
$Crap_You_Hate_General_Budget_Allocation += $Amount;
}Embedding Firefox doesn't increase marketshare and protects more people from tracking. Nobody gives a shit that your Electron app runs with Firefox and not Chromium.
Now, I do agree that the Mozilla CEO pay is way too high, but holy fuck find something new and useful to complain about.
It also wasn't equivalent to Electron for a bunch of big architectural reasons related to required changes to Gecko that the team never prioritises because Proton wasn't a priority project.
> was solely bleeding money
Yes. Because unreleased in-progress projects should be profitable before they're released in order to be viable. How much money was it bleeding? Do you have eyes on these accounts?
Wasn't it supposed to be a full on replacement? I get that they were still a long way off but it seemed like they got really far and what was there was super promising.
Servo gave the following to Firefox:
* Proof that Rust can both be used to make browser engine components and easily integrate, with really good performance. Servo served as a way also to test out Rust changes and pain points that needed to be addressed.
* Stylo, a CSS rules engine.
* Neqo, an HTTP/3 library
* WebRender, the multithreaded rendering architecture that everyone was really thinking of when mentioning Servo
Which is really pretty much all of Servo. Html5ever is fun but unneeded.
I suppose you're probably right but then why do they say "Servo’s mission is to provide an independent, modular, embeddable web engine"
>Making a new browser engine from scratch is a stupidly long undertaking
I remember running their testing snapshot thing a long time ago. It seemed like they managed?