If Mozilla hadn't locked down Firefox so much, the fix could have been as simple as going into about:config and flipping a switch to allow unsigned plugins.
TBH it’s not hard for me to think of ways Mozilla could have preserved user control even in the face of these constraints though. For instance, I already use a master password to encrypt/decrypt the password database in Firefox. Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them?
If the crapware uninstall Firefox, install Firefox Dev Edition, and installs the unsigned plugin, there's not much of a "gray" defence there.
People, including myself, were argueing against putting mozilla in a position where they are a single point of failure. That critique was countered with the specific argument that giving users an override is not acceptable because any override could also be used by adware and thus mozilla must be the sole arbiter of what addons can be installed.
Under the Unix security model, for example, that would be pretty likely: your profile's owned by your account, the executable & its containing folder are owned by root & go-w, so code running as you can tamper with the former but not the latter.
Regardless, as I said in my comment, I only mentioned the Unix model "for example" - not to "shift the goalposts", just because I'm more familiar with it than with whatever anti-binary-tampering measures Windows may have.
> By baking the signing requirement into the executable these programs will either have to submit to our review process or take the blatant malware step of replacing or altering Firefox. We are sure some will take that step, but it won’t be an attractive option for a Fortune 500 plugin vendor, popular download sites, or the laptop vendor involved in distributing Superfish. For the ones who do, we hope that modifying another program’s executable code is blatant enough that security software vendors will take action and stop letting these programs hide behind terms buried in their user-hostile EULAs.
(emphasis mine)
I haven’t heard of this actually happening.
In other words, it’s not a purely technical solution, it’s a political solution, and the success or failure of such a political solution can only be judged by real world results rather than technical possibility.
Or just inject code the browser at runtime.
Under the Unix security model, the UID is the permission boundary. Even if the binary is owned by root, it inherits the user's UID when they run it.
This feature uses SHA-1. [1]
> Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them?
It cannot protect against such. It can protect against a household adversary such as a 4 year old, and that's about it.
[1] https://palant.de/2018/03/10/master-password-in-firefox-or-t...
Of course if Mozilla had wanted to secure the config settings they could just fix the master password hashing functionality at the same time.
Ordinary users would have 5 levels of toolbars!!! Installed by anti-virus apps, etc.
Locking down can back fire, but think not that this wasn't done in the interest of most users.
1. Type about:config in URL bar
2. Change xpinstall.signatures.required from true to false
3. Restart Firefox
...which is to say, it's a trade-off, and though you can disagree with the weight Mozilla assigned to the pros and cons, their reasoning was valid.