The following rant is purely based on experience and speculation, and not based on a code review or peppered with other insights like design papers.
A few days ago I, like many other users of Firefox, noticed, that all the addons were disabled. A temporary workaround was already available on the Internet, but the whole episode made me think why Mozilla keeps periodically checking the signature of already installed software.
From my point of view, there is some merit to the idea that the software that a user is installing, has traceable origin. This is customarily achieved by code signing. The Debian project does this, and, I think, CentOS etc. are doing this as well by now. In the case of Debian, you download a keyring with "known-good" GPG keys, and the packages are signed with a key out of this set keys contained in the keyring. Third party vendors like eg. Google, Docker or Jenkins are using their own keys, of course. But once you have installed the software, no signature or key gets ever checked again, and the software continues to run indefinitely, as far as code signatures etc. are concerned. No potential for breakage due to operational conditions here.
This approach has the nice properties that it works offline - the basic set of keys is part of the installation media, that you can verify the keys at anytime when you want to install or re-install a package, and there is no data leakage to the outside world, since all operations work only locally.
Now look at Firefox:
It's not quite clear to me when exactly the signature checking occurs, but let's explore a these plausible cases:
- signature checking at install time
- periodic signature checking
Signature Checking at Install Time
If the signature of an add-on is only being checked at install time, then the only possibility that I can see why the add-ons are now all disabled, is that someone put out new versions of all add-ons I have installed, at the same time. And the same for every other user on the Internet. This is extremely unlikely. It's much more likely, that they are checking the signatures of all installed add-ons once they are trying to install a new (version of an) add-on. Since Firefox comes with auto-updates turned on for all add-ons, this would then occur at the earliest occasion when an update would be due to be installed.
But the proper handling of the problem is not to disable all add-ons where they can't check the signature - at least, there should be an easily accessible option to re-enable an add-on if they had disabled it. Unfortunately, by default, Firefox is quite terse in this area. A much more sane handling of the situation would be to not install the new add-on, but keep the old version running, unless overridden by the user.
Periodic Signature Checking
Another possibility is that Firefox would periodically check the signatures of all installed add-ons. That would be a privacy invasion, as it would leak usage data to Mozilla, which I'm not confident that all Firefox users would have consented to, if they would have been asked.
But reading the Mozilla.org website and their Twitter, where they said they would be posting updates, suggests that this kind of "nanny-state" behaviour would be perfectly in line with their general conduct, which appears to be more and more to replace proper software engineering with propaganda and coercion, frequently about things which are unrelated to, or contribute little, to the practical freedom, security and privacy of the actual users of their software. I also don't really understand how much of a problem that would be to issue a new certificate and have the better handful of add-ons which are available for the new version(s) of Firefox, automatically signed and upgraded as well. Instead, they are trying to cram their "studies" down the throat of Firefox users, which would basically surrender my browser to them for total remote control. This isn't going to fly with me, and I think I'm not alone in this regard. So, we are in day two/three after this event.
Summary and Recommendations
I don't know what they are really doing here, regarding the signature checking, but disabling them after they have been initially vetted, does raise a number of serious issues. As outlined above, there's the operational issue for the users. Then, there's the potential breach in privacy, depending on how exactly they do their signature checking.
I sincerely hope that they don't have only one certificate chain to sign the add-ons and the browser, but one obvious solution would be to bake a new certificate chain into the browser, sign all the add-ons with it, and then push the update out, so users could install the new certificate chain in a secure manner.
If the concern is that Firefox as a whole is too insecure to trust the add-ons to remain unchanged in the profile, once installed, then maybe one could think that having operating system packages for these add-ons to install them in the read-only area of the computer as an administrative user, eg. somewhere under /usr, and Firefox being unable to modify them itself, not such a bad idea after all. Also, there should be a way for the user to install third-party add-ons without the interference of Mozilla, without disabling the signature checking altogether. One way to do that would be to have additional search paths for third-party or user created add-ons, which could also be quite nicely outside of the reach of Firefox itsel, eg. somewhere under /usr/local. Although these examples are for Linux or Unix, I am confident that recent versions of Windows also have some ways to make it difficult for normal users to overwrite parts of the operating system.
And then there is also the general challenge of keeping the signing infrastructure and the process itself secure, as illustrated by this essay at SANS.
Generally, I think that Mozilla should not try to become first and foremost a pressure group with some software trailing behind, although I do agree with some of the purported ideas, but instead should focus on actually creating a usable browser which actually delivers on all the proclaimed privacy, secutity and other usability claims that they make.