One huge advantage the Chromium has over Gecko is Google's Security Team (ie Project Zero).

For most users, the web browser is one of the biggest attack surfaces and having arguably the best security team behind the browser engine is a good thing.

Google have certainly done a great job of maximizing the PR benefit from their security researchers. And it’s a great thing they’re doing. But regardless of how well individual companies market their respective security teams, Firefox has a comparable reputation for their browser engine.

Yes some of that might be thanks to PZ, but that’s beside the point, isn’t it?

Choosing Mozilla’s platform would have been better for code diversity, which has its own distinct security benefits.

I can understand value in multiple browsers for experimenting with new things (see Rust integration into Mozilla's engine), but what are the security benefits?

Like if you have 3 different crypto imlpementations, you have times more teams that have to get a thing right. It seems way easier to try and get it right just once.

Perhaps there's a holistic idea of "if one browser has an issue, at least it doesn't affect 100% of them" but given what CVEs look like in reality (often variations of the same attack across multiple programs) it seems like the cost/benefit would not be in our favor

Multiple implementations is a great way to highlight issues in the spec vs reality (assumptions, unspecified behavior, etc). If you only have one implementation, the implementation becomes the spec and you end up with people targeting compatibility for that rather than a specification.

This happened with Cisco routers back in the day, Juniper had to add a flag to make a routing protocol compatible with Cisco because Cisco implemented it wrong but had so much dominance that Juniper had no choice if they wanted to get in the game.

> what are the security benefits?

Not everyone gets hit with every attack. Biological systems work this way too.

The biggest security benefit is that competition motivates everyone to work harder, to explore alternative solutions, to raise expectations. Competition means investing in ideas like Rust and Servo.

Without serious competition you eventually get IE6.

This is flatly not true. Just dig through the CVEs and you'll see while they have a similar number of bugs Chrome's are mostly in the harmless category (browser got DOSed) where as Firefox's has had like 10x the bad category (code got executed outside the sandbox).

* Firefox has a comparable reputation for their browser engine.*

Is this really true? someone posted somewhere(can't find it) where it shows Firefox has a worst security record compared to Chrome.

Also, in the past, Firefox was left out from hacking browser competitions because it was to easy to hack.

It's not actually clear that they prioritize their own products all that much. Certainly in regards to Project Zero, it seems the point is that they are detached from the rest of the product teams. (Correct me if I'm wrong)

Outside of the security teams, I think it's actually that Chromium is much better fuzzed and scrutinized. They just have so many more resources, including those for security.

>It's not actually clear that they prioritize their own products all that much. Certainly in regards to Project Zero, it seems the point is that they are detached from the rest of the product teams. (Correct me if I'm wrong)

Most of what I've read relates to Microsoft products - and I'm not saying that Microsoft is better/worse than the rest when it comes to security.

Google is here to protect you from the lovely document reader that they forcibly mutated into a toxic app platform.

So you’d rather live in a world where all the web apps you use every day need to be installed and run with full user permissions?

The web is the safest, most battle-tested sandbox environment to run apps in. It’s so safe that you click random links all day long, running 1000s of apps and never have to worry.

I’ll take web apps over native apps from a security perspective, thank you.

I don't really think this is a problem anymore. It's more that no desktop OS provides secure native execution facilities a la iOS. The web browser was the best solution for sandboxing web applications in 1995-200x, but now CPUs have multiple cores, virtualization extensions, systems with multiple gigabytes of ram, etc.

There are better ways to sandbox applications in 2020.

As an interesting counterpoint, since iOS sideloading became semi-possible around 2014, there have been many more app-based Jailbreaks than Safari-based Jailbreaks.

This is true despite the fact that on iOS, sideloading custom apps without a developer account is extraordinarily inconvenient.

I'm so sorry to respond so late; I would just like to point out "the cloud," and the fact that there have been very few hypervisor escapes. Just because there are more app-based Jailbreaks on iOS has little to do with what is technically possible given the hardware (recent Intel missteps notwithstanding).

Personally, I'd rather live in a world where you could tell a web app from a document before you opened it. No need for apps to be native, but on a different protocol.

Totally. The hell of security issues is what makes IE a terrible product.

I think the biggest reason they went with Chromium/Blink is simply because of market share... most users at this point are using Chrome for better or worse, and MS is going with the safest bet in terms of user compatibility for today's web.

I believe the reason was NodeJS and Electron, wasn’t it? Basically, MS expects NodeJS and especially Electron to become fairly important going forward (MS’s 2 newest and highly successful apps are both Electron based...VS Code and Teams). There is no indication that either of those are moving away from Chromium anytime soon.

The sad thing is that those apps' HTML and JS probably are standards-compliant, so supporting Slack, Teams, VSCode, (Electron) Skype, etc in a Firefox-based version of Electron should be possible and very straightforward - yet it probably won't happen.

What's sad is that Windows 98 fully supported desktop-based HTML+JS apps ("HTA Applications"), with access to native resources (using COM via `new ActiveXObject`) and it works with IE11 still - Microsoft just never pitched it as a serious development platform for some reason. Just imagine what today's world would be like if Microsoft did pitch HTA as a successor to VB6 (instead of the quickly-abandoned WinForms platform, now barely on life-support) (I'm mostly thinking we wouldn't be stuck with excessive memory consumption in Slack, and these apps would be able to use things like native context-menus and accessibility features)

> Just imagine what today's world would be like if Microsoft did pitch HTA

That would have been a security nightmare.

Electron is pretty much the same nightmare anyway. Just because it runs in chromium doesn't mean it preserves the sandbox. All electron apps have full access to your filesystem and os, even from their chromium window context.

Microsoft rightfully decided not to push a garbage app platform. It couldn't know someone else would do so later.

WinForms was never "quickly abandoned" ... MFC has been the defacto standard for Windows UI since Win 3.1

WinForms did not receive any significant updates after .NET Framework 2.0 and Visual Studio 2005 - integration with the new User32 controls added in Windows 7 was only through downloaded optional redistributable DLLs. Ever since the .NET Framework 3.0 (and until UWP) Microsoft was selling WPF as the way to build Windows desktop applications without C/C++.

It's a big reason, for sure. To be able to instantly sync everything over, will mean there will be many, many people switching. It's tied to Edge is built in to Windows. Having Chrome installed will be redundant.

This is exactly the kind of thinking that perpetuates monocultures once they start.

Sadly, that doesn't make it wrong per se, just deeply discouraging. It makes me think we're past the point of no return.

Responding to a reply that was deleted while I was in the process of writing my response:

---

> I don't see why it's Microsofts responsibility to do whats worse for their products, users and business just to bring some sort of benefit to Mozilla which has awfully mismanaged over the past 10 years or so. The browser monoculture didn't happen over night it happened thanks to years of neglect from the other browser engines. I don't like this situation and don't even use Chrome myself but this is the reality of the web today.

I would wholeheartedly agree with you if Firefox Quantum wasn't so damn good.

I didn't use Firefox for years except for occasionally testing sites. Quantum blew me away in terms of rendering speed; it reminded me of Chrome in the very early days. I know that benchmarks say Chrome is still ever-so-slightly faster, and I can't explain that, but Quantum legitimately feels quicker when I use it. At worst, it's certainly not a downgrade from Chrome.

I do wish Firefox's interface was cleaner—the pocket integration and similar stuff just feels like icky clutter to me—but I've been able to mostly clean it up via about:config tweaks, and none of that's relevant to the rendering engine.

That Firefox managed to do all of this with much more limited resources than Chrome, and despite how many sites nowadays are built to target Chrome specifically... it's seriously impressive. I'd love to see what the engine could do with Microsoft's additional resources behind it.

I think Quantum is smarter about what it prioritizes rendering. Time to complete page load may be slower in Quantum, but Quantum makes sure to display key parts of the page so that it appears to load faster.

Even the guy who literally birthed Firefox (Brendan Eich) picked Chromium for Brave, his new browser.

We started with Gecko in 2015, but it lost on many dimensions in a head to head comparison enumerating gaps vs. Chrome. DRM is just one example. We don't like DRM, but users want Netflix to work, and Google makes WideVine free-as-in-beer; whereas at the time, Mozilla had an Adobe deal that did not extend to non-Firefox Gecko embeddings.

So we switched to chromium/Blink in late 2015. Much later, when I visited Apple in early 2017, a devrel friend asked why we couldn't use WebKit. A WebKit founder in the meeting agreed with me that there was no way for Brave to do so on Windows w/o running out of capital. DRM again was an issue too, without WideVine. Don’t blame startup for not carrying a full engine — that needs deep pockets. While MS does have deep enough pockets, it is starting by using chromium/Blink and slow-forking.

Waterfox (a rebuild) and Basilisk (a hard fork) are based on Firefox, but they have Widevine.

Hey, thanks for everything you've done for open source and open platforms.

The reason you gave here for Brave not choosing Gecko (or WebKit) is interesting – but given Microsoft's deep pockets and tech know-how those reasons don't apply to them.

I think this is a strategic blunder on Microsoft's part and I say this as a Linux user. :)

Microsoft has now warmly embraced Linux – and I think they could have chosen this time to warmly embrace Mozilla. Oh well.

Microsoft was slowly losing browser share with their own engine, felt they needed more web compatibility (including de facto via the WebKit lineage) and extensions sooner. They were not going to play a long game, even if they could afford it. Mozilla may have looked wobbly to them, too.

Didn't see your reply before this, sorry.

I hear what you're saying – but! – a tech giant has to play the long game. The Web is an open (for now) platform and Microsoft, like Apple, like Google, need to have their own web client/server implementation. Makes no sense to be beholden to Google imho.

I'm stunned at how little desktop browser share Edge has (4.6%): https://gs.statcounter.com/browser-market-share/desktop/worl... – however, changing browser engine is not going to change that, is it? I suppose, if Google and Microsoft end up equally and democratically sharing Chromium development then all's well.

Given the recent layoffs at Mozilla it's a pity (in hindsight – for the benefit of the open web) Microsoft didn't back them :(

Anyhow, thanks for the response.

Surely Microsoft has done their homework: researched everything and weigh the pros & cons. This is a big thing and the next step in their browser strategy. We can only guess their reasons, but clearly in their eyes, Chromium codebase is the better choice.

True, but big companies can sometimes make big mistakes, no?

Yeah, but he also designed JavaScript, so...

Considering he designed it in about 10 days, it could have been much worse… and now it’s one of the most popular and important programming languages in the world; go figure: https://spectrum.ieee.org/computing/software/the-top-program...

In 2001, Apple could have picked Gecko but forked KHTML instead to create WebKit/Safari because it was smaller and seemed easier to work with.

It doesn’t change the fact that back in the day, high profile companies picked WebKit—Google, Blackberry, Nokia—for their browsers.

In 2013, Google forked WebKit to make Blink and nowadays, Microsoft, Opera, Brave and others have picked Blink/Chromium for their new browsers.

Even as Mozilla is making great strides with updating its engine (was Gecko; now Quantum), nobody else is going on that trip with them.

KHTML was always designed and positioned as an embeddable browser engine. Mozilla deprecated the embedding of Gecko, so you have to fork and change the whole browser instead of just lifting the engine...

I like JavaScript... it’s very flexible and incredibly expressive. Using c# lately, I just feel shackled

Moving for any modern language you know well to any other modern language will feel like that. You need to spend time learning. It has nothing to do with the what the language is capable of.

"I can code in X so I should be able to jump in to any other language and get to speed instantly." is obviously wrong.

I'm the exact opposite. Having a compiler help you avoid an entire class of bugs is superb.

What can you express in JavaScript which you cant express in C#?

Serialization for one thing. You can work with JSON extremely freely without creating weird serializable classes for every combination of data you might need to work with - eg, no class named "DoodadList" for when you want to de-serialize a JSON list (maybe that's a Unity3D thing?).

You can nest functions nicely and work with closures when it makes sense, if you like that sort of thing.

The async programming model is also really nice to work with.

You also don't need to create classes for every noun, verb, and adjective in your system either - when all you need is a function, you just write a function, not some weird object to hold it.

You also don't have to write a f after all of your decimal values to tell the silly compiler that you mean for 0.25 to be a float. (this one truly does not matter, but there are a lot of little things like this that add up)

I know you can do a lot of that in C#, but its just so effortless in javascript. You just need to be more disciplined about how you code it

You are right about having to create a class to hold a function, that is annoying. But C# do support nested functions and closures. I don't really understand your other points. A literal 0.25 in C# will be parsed as a double precision. If you want it to be a float (less precision) you use the F postfix. But JavaScript doesn't even have the float/double distinction.

What can you express in C# which you cant express in Assembler?

Expressions and functions for example. Assembler is really low level, it doesn't even have control structures. But C# seem to have everything JavaScript has and much more, so I just wondered why the parent post found JavaScript more expressive.

Looping over properties of an object is painful in C#.

Under a 2 week deadline. I challenge you to do better.

Most likely he had been thinking about the project for some time. But the 10-days-execution story sounds much nicer

I joined Netscape on April 3, 1995 but in the server team, due to a temporary requisition shortage. I worked on what would eventually become HTTP 1.1, which we wanted to be more like SPDY or HTTP 2. Therefore I had only spare time to think about what became JS, and I used it to study HyperTalk, Logo, and other languages, not just Scheme or Self.

I finally got transferred to the client team one whole month later, in early May. Then I had ten days to demo-day.

Why do you feel compelled to make up a story? Because it sounds nicer to you to denigrate my work, it seems.

> Why do you feel compelled to make up a story? Because it sounds nicer to you to denigrate my work, it seems.

Because randos on the internet (especially business types) love to make stuff up in the name of puffery and deifying. Legends are rarely true.

Thank you for clarifying.

You are a business type?

Yes, sadly. I'm well aware of our capacity for bullshit and cargo-culting

Not that you need it or anything, but I'd like to thank you for your work on Javascript - without it I might never have gotten started with programming.

So, thank you very much for laying down the foundation for a whole generation of new programmers!

He was... kind of. My understanding is Eich had been thinking for a while about the idea of bringing a version of Scheme into the browser. He was lured to work for Netscape by the promise that yes, he could do this. Unfortunately the business decision came down that the language's syntax had to approximate Java. So the semantics of the language had probably been settled in his mind for quite some time, but the syntax change still makes the 10 days an impressive feat. (And also explains a lot of the weirdness in JavaScript -- you're writing code and expecting it to behave like a C-like, but you're actually kind of writing quasi-Scheme and you don't know it.)

I've spoken and written about the early days, e.g., here:

https://www.youtube.com/watch?v=aX3ZABCdC38

Friends from SGI recruited me (second attempt) in March 1995, I joined in early April but in the server group. I thought a lot -- but worked too little due to server commitments -- during the month of April, about "the scripting language" which was suggested to be Scheme when I was being recruited, but which by the time I joined could not be Scheme, due to the impending Java deal between Netscape and Sun.

Java meant either no scripting language, or a kid-brother language, which meant C-like syntax, primitive vs. object types as in Java, and other unfortunate consequences.

When I transferred to the client group in early May, I had to produce a demo very quickly. I chose first class functions and (barefly there at first) prototypes as the building blocks. The rest is history.

So it sounds roughly one month of thinking and researching, then 10 days of coding?

That's what I wrote, yeah. With constraints going from "Come do Scheme!" to "make it look like Java" and even "feel like Java" because interop, via what we hoped would come, and did in Netscape 3, as a JS/Java bridge called LiveConnect.

The Belgium Post built a whole web app+service architecture on LiveConnect.

Think of LiveConnect as "Active Scripting" on MS's platform, which enabled Java components to be developed and glued together by JS.

Thanks!

Or they could have open sourced EdgeHTML. It's not like it was worse, than Gecko.

It was worse than Gecko. Gecko is excellent.

Edge still has (had?) so many rendering issues on sites we make. One thing I find really impressive about Firefox, despite the completely different engine I _very_ rarely find FF-specific bugs.

(Perhaps I should have specified "Quantum" rather than "Gecko"? I meant the engine that new Firefox uses, I thought it was still called Gecko but sounds like I might be wrong?)

www.just-eat.no

Many (all?) Oslo postcodes start with 0, and their site truncates the 0 when you try to enter your postcode. Their stated solution was to use Chrome, so they don't get any of my business.

From your description, it sounds like they decided to use a "number" typed field for the post codes. This is of course incorrect, post codes are really just strings. While the bug manifests itself on firefox, it is hard to blame it for implementing the field according to spec [1]. Chrome decided to ignore the spec and leave the field more free-form, which in turn enables developers to use it incorrectly without detecting the compatibility bug.

[1]: https://www.w3.org/TR/html52/sec-forms.html#number-state-typ...

> User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user’s selection as a floating-point number.

Notably, this type of issue is exactly why it's important to have more than one implementation of web standards!

If Chrome is your only target, the standard ceases to mean anything. The real standard is just whatever Chrome does.

Open-source IE would be even more interesting to see, mostly because the early versions ran well even on systems with two orders of magnitude less RAM and CPU power than ones today; especially when displaying static pages and not JS-heavy apps. I remember the Firefox of the time was noticeably more sluggish than IE6 and used more RAM, and know quite a few people who tried FF and went back to IE for that reason.

I could just imagine them looking at the (security) horrors of the IE source code, and with a cold sweat, sticking it in the drawer.

> I just wish they'd moved to Gecko instead of Chromium.

The usual answer to that complaint is that Gecko is harder to embed. MDN pages on the subject even mention it’s deprecated and that the documentation is obsolete.

Is this something Mozilla could feasibly improve?

It might not be worth the effort, and instead concentrate on Servo[1].

[1]: https://servo.org/

If you look at long term investments are you confident Gecko will still be around in 10 years? Chromium is the only safe choice they had.

If Microsoft had also gone with Gecko? Yeah, I'm quite confident Gecko would still be around (and maintained by many people other than Microsoft) in a decade.

I think it will be around anyway btw, although I'm perhaps less sure.