Hacker News Reader

Comment by ulrikrasmussen | Hacker News Reader

Can someone explain to me why most browser forks are based on Chromium? If the goal is to make a privacy focused browser which is independent of Google, isn't it then a bit counterproductive to put all your eggs in a basket which only exists due to the goodwill of your main competitor? Why not webkit or Gecko? There might be a good argument for it, but as a person concerned with privacy and the future freedom of the internet, who is supposedly the target user for a browser like this, I would expect the justification to depend on Google code to be front and center on the page.

View on HN

WebKit is easy but has terrible compatibility because the fruit company makes money from native apps. They do the bare minimum to keep Safari functional so that people keep buying iPhones.

Gecko has an uncertain future and is perpetually at risk of dying.

It's at least possible to switch from Chromium to WebKit if necessary so the risks of building off of Chromium are not that big.

Gecko is too big to die. Even with Firefox’s market share being a shadow of its former self, it’s still used by millions.

The real problems with Gecko is just that it’s harder to fork and has less compatibility with the web (that last part is largely just due to Chromium being the de facto standard so fewer people test their sites against Firefox).

> The real problems with Gecko is just that it’s harder to fork

That goes contrary to my experience. I'm a maintainer of a Firefox fork (with rather extensive changes to a lot of the internals), and it is pretty manageable to maintain. We manage to keep it roughly up to date and add new features without financial backing or folks working full-time on it.

If all you do is change the branding and apply some superficial stuff, Chromium might be doable, but that is hardly a new browser. Everybody who forked Chromium from the folks I know (mostly research/security testing people) gave up due to the constant churn.

For this reason, from my experience, Firefox forks are much easier to maintain once you start applying changes to internal things. Firefox is changing at a slower pace, making keeping up to date much more manageable, but that also has its drawbacks, as it does not support every crazy feature Google pushes out, e.g., WebUSB. But, for example, folks I know maintained a v8 fork that was shelved as the introduction of Torque (which has spotty public documentation, to be very kind) means it is a complete rewrite.

Thats interesting. Thanks for sharing.

Why do you think that very few projects adopt Gecko then?

I'm somewhat uncertain personally about the future of Mozilla myself, as well as compatibility issues and a lack of mindshare.

Also, I feel working with the Chromium codebase is easier if you only apply superficial changes, e.g., the linked browser. The patch files are all very simple, so the fact that Chrome is generally less crufty (Mozilla is working on cleaning up a lot of ancient stuff, which causes us a lot of pain but is probably great in the long term), simply due to being newer, might make it easier to get started. Although I always felt the most significant hurdle (if you know C++ and JavaScript sufficiently well to patch a Browser) is getting the stuff to build, Mozilla is doing reasonably well on that front. Building Firefox always felt less annoying than building Chromium.

How those patch files work? I was trying to read the Helium codebase but is only full of .patch files.

I think you're conflating the Engine, Gecko, with the browser, Firefox. The Browser, Firefox, is easy to fork, judging by the multitudes of soft forks a la Libre Wolf, Zen, etc...

The Engine, Gecko, however, is hard to fork since it's tightly coupled to the browser itself.

I also think that when the parent mentioned "forking Gecko", it might be in the sense of extracting the engine and putting a new browser on top of it, just like other Webkit based browsers e.g. Orion and Gnome Web.

That's fair but most of these browsers simply fork chromium and make their changes there instead of genuinely building something new off of blink.

Rather the fruit company doesn't want to implement ChromeOS Platform APIs that never made it into Web standards.

Couple main reasons: 1) BSD license vs a CopyLeft license. Edge, Opera etc don't want to push their changes back up. 2) Compatibility and performance is why Brave switched from Gecko to Chromium. 75% of the marketshare is chromium based browsers so sites will more than likely work with chromium browsers.

I don't why webkit is more popular. Maybe because it(Apple) is slow to adopt standards.

> Maybe because it(Apple) is slow to adopt standards

I think this is an interesting bit of propaganda - they are historically not all that slow to adopt actual standards.

What they often are is unwilling to adopt Google's pre-standardisation extensions (things like WebUSB, which have never been adopted as standards).

WebGPL, WebRTC, Gamepad API, WebASM etc Years behind Gecko and Chromium. Don't get me started on codec support with Safari. Webkit is the new IE.

WebGPU not yet a W3C standard (it's at the previous step, as a "candidate recommendation"). Apple's WebGPU implementation went live before Firefox's implementation.

WebRTC went live in Safari the same year that the non-draft version went live in Chrome (Chrome supported the pre-standard webkit-prefixed version for some years before).

Similarly, Safari added support for WASM the same year that WASM was standardised (once again, Chrome supported a pre-standard version ahead of standardisation).

Yea the funny thing is that the real lie is that Safari is behind, that hasn’t been true for many years now.

The further irony is calling it the “new IE” when in fact it’s Chrome that is far more similar to the IE of old, at least in terms of the dirty tricks - dominant market share, uses it to push non-standards, stuffs in user hostile features to the brim, and spies on you incessantly. The only difference is it’s not terrible at performance.

> I don't why webkit is more popular.

Because Safari comes pre-installed on billions of devices?

My guess is just that a lot of people really like Chrome and wish they could have that without the privacy concerns. I mean honestly I'm the same, I'm just seemingly more cynical as to whether that's possible.

That plus the fact that using a chrome based browser effectively hands over a bit more control of the web to chrome. If I don't like the privacy issues with chrome, it seems like a bad idea to hand (more) control of web standards over to the company that makes it, directly or indirectly.

Everyone mentions compatibility and performance as the main reasons, but this still doesn't make any sense to me. If I switch to a browser which has a stated goal of protecting my privacy and protecting the freedom of the web, then performance and web site compatibility is much further down my list of priorities.

I'd agree but performance and compatibility bubbles up to top concern pretty quickly when you use something nearly constantly (which I'd say is applicable for a browser).

Even if you have personal priorities for privacy, surely you can understand that many user's first expectation for a web browser is for websites to work correctly.

We've kind of lost the plot if we get too far away from the core notion that a web browser is for correctly and completely rendering websites. The user population don't use web browsers to hide, they use it to look at the internet and do internet work. If a browser has any problems doing this, it not going to be relevant.

I believe that Gecko is notoriously hard to maintain and integrate into other software. It's not something I've attempted myself so take it for what it is. It was one of the issues Servo was suppose to address.

There is a few browsers based on WebKit, so that seems doable.

Even in 2025 you still get the most compatibility with [insert-website-here] with Chromium

Sure but I only use Firefox (no other browser installed (except Edge on Windows)) and I don’t have any issues; so some none-trivial portion of the web doesn’t require Chrom(ium) specific behaviour.

Google websites intentionally degrade performance if you browse from Firefox. Facebook Messenger's E2E only works on chromium browsers. There are many websites that show popups to use chromium for the best experience. I do get it, these aren't privacy-friendly websites, but for professional purposes, lot of people are forced to use chromium browsers or user-agent strings.

> Google websites intentionally degrade performance if you browse from Firefox.

If this is true they should be in court for these anti-competitive practices.

Messenger's E2E is working fine for me?

The only websites I seem to have issues with are usually trash sites anyway. All my regular sites like banking, Google Docs, Office 365, finance, etc. work just fine in Firefox. I do find its performance not up to par with most sites that might have a very JavaScript heavy app for gaming and such.

I don't know the internal details of the architecture, but on Windows, it's very trivial to be "Chromium". The newest web browser component has been based on Chromium for a few years.

>Can someone explain to me why most browser forks are based on Chromium?

Because it's very very very good. Google poored billions into it and it shows.

Its probably the easiest to build off of.

The thing is, Gecko is really insecure when compared to Chromium. Its sandboxing is asinine. Additionally, due to lack of WebView implementation, on mobile you have to use Chromium either way, leaving you with two completely separate attack surfaces.

Quoting GrapheneOS developers[1]:

> Avoid Gecko-based browsers like Firefox as they're currently much more vulnerable to exploitation and inherently add a huge amount of attack surface. Gecko doesn't have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox / Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android. This is despite the fact that Chromium semantic sandbox layer on Android is implemented via the OS isolatedProcess feature, which is a very easy to use boolean property for app service processes to provide strong isolation with only the ability to communicate with the app running them via the standard service API. Even in the desktop version, Firefox's sandbox is still substantially weaker (especially on Linux) and lacks full support for isolating sites from each other rather than only containing content as a whole. The sandbox has been gradually improving on the desktop but it isn't happening for their Android browser yet.

IronFox (an FF fork) developers[2]:

> While we do as much as possible to improve the situation, it should be noted that Firefox-based web browsers, including IronFox, have security deficiencies when compared to Chromium. This is especially notable on Android.

[1] https://grapheneos.org/usage#web-browsing

[2] https://gitlab.com/ironfox-oss/IronFox/-/blob/dev/docs/Limit...

An in-depth examination of this topic and a plethora of other sources can also be found here: https://madaidans-insecurities.github.io/firefox-chromium.ht...

Reply on news.ycombinator.com