hi WolfShade, in this case you should use firefox developer edition, which is available from https://www.mozilla.org/firefox/developer/ where it will be possible to disable the addon signing requirements now and in feature releases as well. in firefox dev edition enter about:config into the firefox address bar (confirm the info message in case it shows up) & search for the preference named xpinstall.signatures.required. double-click it and change its value to false.

Hi, @philipp, thanks for your reply.

I tried the xpinstall.signatures.required trick on 42; FireBug still works, but the plugin is still listed as disabled. It's my understanding that the trick is no longer working as of FF44.

Thanks for letting me know about the devloper version. I'll give that a shot. But it still makes absolutely no sense for Mozilla to do this. At least give users the OPTION of enforcing signatures for plugins; defaulted to ON, of course.

V/r,

WolfShade

BTW.. do you know where I can get an offline installer for the developer FF? The link you provided is the one that downloads FF, which I can't use on my internet-isolated dev system.

V/r,

WolfShade

I found your other post which gave a URL (HERE ) for the offline installer for the developer FF. The 64-bit is correct; but the 32-bit link still gets you the stub. Just thought you should know.

V/r,

WolfShade

UPDATE: For the developer edition of FireFox, if you want to use FireBug (which was the primary reason for me downloading it), you must remember to disable e10s. If you do not, then FireBug will not work, at all.

• http://download.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora/
• http://download.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-aurora/firefox-46.0a2.en-US.win32.installer.exe

WolfShade_ said

... At least give users the OPTION of enforcing signatures for plugins; defaulted to ON, of course. V/r, WolfShade

That is discussed in https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/

... Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and plausibly claim they were acting on behalf of the user’s “choice” not to opt-out of the light grey checkbox on page 43 of their EULA. This is not a concern about hypotheticals, we have many documented cases of add-ons disabling the mechanisms through which we inform users and give them control over their add-ons. 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. ....

WolfShade_ said

Hi, @philipp, thanks for your reply. I tried the xpinstall.signatures.required trick on 42; FireBug still works, but the plugin is still listed as disabled. It's my understanding that the trick is no longer working as of FF44. Thanks for letting me know about the developer version. I'll give that a shot. But it still makes absolutely no sense for Mozilla to do this. At least give users the OPTION of enforcing signatures for plugins; defaulted to ON, of course. V/r, WolfShade

Plugins like Flash, Java, Silverlight etc does not need to be signed, it is Extensions that do which is what Firebug is.

... Many developers have asked why we can’t make this a runtime option or preference. There is nowhere we could store that choice on the user’s machine that these greyware apps couldn’t change and plausibly claim they were acting on behalf of the user’s “choice” not to opt-out of the light grey checkbox on page 43 of their EULA. This is not a concern about hypotheticals, we have many documented cases of add-ons disabling the mechanisms through which we inform users and give them control over their add-ons. 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. ....

While true, there is not anything preventing developers from triggering a dialogue asking the user to confirm the change (on certain options, not all of them.) This would, effectively, prevent malicious changes from happening, while allowing the user more options.

I would also think (I'm not a developer of EXTENSIONS, so can't say for sure) that a developer could detect if a change was triggered by a user click or a programmatic click. (shrug)

Just my $0.03915 (after inflation.)

WolfShade