[cyphar]

Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution.

And even the "download .exes from the internet" usecase is precisely as secure as downloading JS from the internet that is verified once per install. To attack someone who has an auto-updating Firefox and downloaded it from the internet, you need to intercept and attack TLS -- but only when the upgrade happens which is a fairly limited opportunity. The JS attack has the exact same properties if the above comment (that it only gets downloaded once per install) is true.

So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument (the real argument is that it allows for more "agile development" -- which is an understandable argument if you cop to that being the only reason for such a design).

[vbezhenar]

If you can attack TLS, game is over, you can't trust anything. A huge majority of Firefox users use built-in update mechanisms. Making life harder for majority of users to improve security of the selected few is a questionable decision. And if you're really insisting, you can always install some addon which will calculate hashsum of JavaScript resources.

[cyphar]

> Making life harder for majority of users to improve security of the selected few is a questionable decision

I agree in theory, though as an aside this isn't true for distribution packages because usually they are GPG signed with keys that are in TPMs on the release machines. Of course any other internet communication relies on TLS not being broken.

But another attack would be modifying one of Firefox's mirrors to host malicious Firefox (not a TLS attack but an attack of a specific mirror). GPG detached signatures for distribution packages protect against this and many other such problems (obviously some attacks against the build servers of a distribution would be problematic, but the same applies for any software project).

Though to be fair, I don't know if Firefox's auto-updater uses an update system like TUF or a distribution-style update system (which is mostly equivalent in terms of security) which would protect against these sorts of problems.

> Making life harder for majority of users to improve security of the selected few is a questionable decision.

I don't understand how logins being built-in to the browser is making life harder for the majority of users. It wouldn't make a difference to them. It would make a difference to the development team, but one could easily argue that the development team should be willing to make life slightly harder for themselves in order to make Firefox users more secure.

[rocqua]

> So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument

I agree. I was arguing for having some form of e2e encryption (like Firefox currently has) as opposed to not having e2e encryption. I wanted to argue against the idea that, because the e2e was implemented in JS, one might as well not have it.

Then, regarding the gap between e2e in JS vs e2e in binary, my point was that JS is just as good in most cases.

> Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution.

Does that mean that the code is only signed by the package distributor, and not mozzilla? Because in that case, the package manager becomes a single point of failure. Then again, I guess that is always the case. Still, it would be weird that, as far as mozzilla trust goes, a signed exe from internet is better than a signed package from your preferred package manager.

[cyphar]

In openSUSE our build system can be configured to auto-check the signatures of the source archives used for building, so you can check the builds to make sure that we are building from an official source releases (assuming the GPG detach-sign their source tarballs -- something I recommend any software release manager do).

But most distributions do their own builds, and without reproducible builds being universally available -- not to mention that distributions usually have minimal compiler hardening flag requirements as well as patches in some cases -- you couldn't reuse signatures for the final binary. Also the entire package is getting signed, so the binary's signature wouldn't be sufficient (and checking it on-install would be quite complicated as well).

> Still, it would be weird that, as far as Mozilla trust goes, a signed exe from internet is better than a signed package from your preferred package manager.

I think that has always been the general case, since distributions are an additional layer of people maintaining a downstream copy of a project. But don't get me wrong, most distributions have processes that allow you to verify that the source used for builds of large projects like Firefox are built using the real sources.

There's also usually several layers of human and automated review before a package upgrade can actually land in a distribution.