Easy: There's a difference between static, shipped code and a capability to modify software at a distance (which could even by hijacked by an attacker who infiltrates Mozilla's infrastructure.)

If your threat model includes the hijacking of Mozilla's infrastructure, I assume you read and verify the entirety of the Firefox source with every new version before using it, right?

Obviously not?

But there are trustworthy people working with and integrating that code, there's a good chance they'll notice a hinky commit, and they're very close to having completely reproducible builds—which means that there can be verification that the shipped binary matches the inspected source.

https://gregoryszorc.com/blog/2018/06/20/deterministic-firef...

Because Mozilla is easier to lock down than Chrome.

I guess "easier" isn't the word really, because Chrome can't really ever be locked down. It's pretty much always, effectively, an open book to Google.

You can lock down everything in Firefox. The drawback being, of course, times like this, when you can't get the fix unless you leave Normandy enabled. (Which I didn't.)

>:-(

Grrrr.

Setting preferences really should not be shocking, given that they have the capacity to run automatic updates. I'm more surprised that they can push code without certificates.

The expires certificate seems to be in a chain concerning extensions. Not necessarily the same chain concerning core browser updates...

> I'm more surprised that they can push code without certificates.

Where are you getting this from? AFAIK all Mozilla code / prefs they can push should be signed -- this very issue seems to stem from the cert used to sign AMO extensions expired.