A script to allow installing unsigned extensions on Firefox(gist.github.com)
gist.github.com
A script to allow installing unsigned extensions on Firefox
https://gist.github.com/TheBrokenRail/c43bf0f07f4860adac2631a1bd9e4136
29 comments
Iceraven on Android makes an attempt to allow additional Firefox add-ons: https://github.com/fork-maintainers/iceraven-browser
The privacy-oriented Mull fork works with those instructions:
https://f-droid.org/en/packages/us.spotco.fennec_dos/
But Nightly also works with add-on collections for me. Which step are you stuck on?
https://f-droid.org/en/packages/us.spotco.fennec_dos/
But Nightly also works with add-on collections for me. Which step are you stuck on?
For some reason I had to try it twice before it worked for me. I started from a brand new collection the second time and followed Mozilla docs to the letter.
I used the same blog post a year ago and it's working with Firefox Nightly from FFUpdater (Fdroid).
Here is mine : https://addons.mozilla.org/fr/firefox/collections/17173754/t...
Here is mine : https://addons.mozilla.org/fr/firefox/collections/17173754/t...
Because Android is more locked down than desktop Linux, there unfortunately isn't an easy way to modify Firefox in-place.
If it helps, the biggest issue I had with setting up custom extensions on Firefox Nightly Android using spaces in the collection name.
If it helps, the biggest issue I had with setting up custom extensions on Firefox Nightly Android using spaces in the collection name.
xposed (lsposed, edxposed, tai chi) lets you hook into apps at runtime if someone was interested in making a mod.
Fennec from f-droid is a clone of Firefox Android with some enhancements, including removal of the whitelist.
Tangent: I just discovered that the Wayback Machine browser extension actually has had an official release, most recenly five months ago, and no longer has to be installed in this way. (There was a rather large gap between Apr 18, 2018 and Feb 18, 2022 when the only way to have a working Wayback Machine browser extension was to install it directly from the source code.)
On separate note, I recently started avoiding Firefox packaged from distro (just extract official download in ~/bin or sth ).I think everyone should do it, my rational goes like this
- distro are usually slow to ship new updates
- when u update running Firefox under its feet using distro package manager, it won't like ... everything crashes.
- not distro ff applies update patch when it starts or shows yellow notification on right side to say update is ready ... much better UX.
- most distro do not ship with LTO/PGO optimizations (I think have not checked)
- snap packages have uses, but I do not like sth Firefox as snap, unnecessary bloat.
- distro are usually slow to ship new updates
- when u update running Firefox under its feet using distro package manager, it won't like ... everything crashes.
- not distro ff applies update patch when it starts or shows yellow notification on right side to say update is ready ... much better UX.
- most distro do not ship with LTO/PGO optimizations (I think have not checked)
- snap packages have uses, but I do not like sth Firefox as snap, unnecessary bloat.
> - distro are usually slow to ship new updates
Depends on the distro. Some focus on stability (like debian), so that's intentional. Others focus on quick updates (like Arch) and they usually succeed. Either way, if there's a serious security issue, the packagers will be definitely be notified and ready to ship the update immediately after upstream, hopefully along with a push notification to their users to update ASAP.
> - when u update running Firefox under its feet using distro package manager, it won't like ... everything crashes.
I haven't had that happen in over a year - Firefox just says "please restart to keep using Firefox" on new tabs. And you're the one triggering the update, so it's the same as a manual install.
> - not distro ff applies update patch when it starts or shows yellow notification on right side to say update is ready ... much better UX.
Updating on startup is horrible UX - what if I'm on really slow wifi or have a weak computer? Now I have to wait multiple minutes for my browser to start. As for update notifications, most distros that provide GUIs for their package manager also provide update notifications that you can enable.
> - snap packages have uses, but I do not like sth Firefox as snap, unnecessary bloat.
So...don't use snap? Every distro I know packages Firefox using the native format, snap is just another option that you're free to ignore.
Depends on the distro. Some focus on stability (like debian), so that's intentional. Others focus on quick updates (like Arch) and they usually succeed. Either way, if there's a serious security issue, the packagers will be definitely be notified and ready to ship the update immediately after upstream, hopefully along with a push notification to their users to update ASAP.
> - when u update running Firefox under its feet using distro package manager, it won't like ... everything crashes.
I haven't had that happen in over a year - Firefox just says "please restart to keep using Firefox" on new tabs. And you're the one triggering the update, so it's the same as a manual install.
> - not distro ff applies update patch when it starts or shows yellow notification on right side to say update is ready ... much better UX.
Updating on startup is horrible UX - what if I'm on really slow wifi or have a weak computer? Now I have to wait multiple minutes for my browser to start. As for update notifications, most distros that provide GUIs for their package manager also provide update notifications that you can enable.
> - snap packages have uses, but I do not like sth Firefox as snap, unnecessary bloat.
So...don't use snap? Every distro I know packages Firefox using the native format, snap is just another option that you're free to ignore.
Thank you. The nonsense dance Mozilla requires for this is one of the many reasons they've lost all of my sympathy.
Can you say more about why this is "nonsense"? Do you understand why it exists and disagree with the reasoning? If so, can you elaborate?
Not OP, but my reasoning goes like this: mandatory signing means that Mozilla can singlehandedly decide what extension I can and can't install. I might disagree with their decision sometimes, so I want to be able to install those extensions regardless of what they think. Maybe I'm perfectly fine with a specific extension that does something against the AMO rules and want to install it from the creator's website. Maybe I want to try a beta version or downgrade to an older one because something is wrong with the latest one - all of this is possible by just downloading a release from GitHub and clicking the file, but it isn't allowed.
It also means that is AMO goes down or I can't use it for whatever reason, I can't use any extensions. This has happened in the past!
It also means that is AMO goes down or I can't use it for whatever reason, I can't use any extensions. This has happened in the past!
Is "I'm perfectly fine with a specific extension that does something against the AMO rules and want to install it" a thing that happens in practice? (this is an honest question, I haven't come across extensions that I was interested in but that have been explicitly banned)
My original comment was reacting to the description of signing as "nonsense" but there doesn't seem to be understanding of why it exists. In brief: Mozilla can (and does) block specific extensions when they are found to be doing something malicious. From what I have seen the bar for this is very high, this applies not just to extensions that do things like extract user data, but to those that do it in a deceptive way without disclosing to users what the extension does. Anyway, this blocking works based on a unique ID embedded in every extension. But if extensions were not signed, a bad extension could just claim to be "[email protected]" or something, trivially evading blocking. Signing isn't about somebody passing judgement on individual extensions, it is about ensuring that addon IDs are unique and not spoofable. You might reasonably say that there should be a user option to disable the signing requirement, but how would this work exactly? You wouldn't want the user to have to affirm that they want this setting every time they start the browser, which means it has to be stored somewhere on disk with other user settings. But this is, again, trivially forgeable by any software that has write access to the part of the system where user preferences are stored. I don't believe that anybody at Mozilla wants to put arbitrary limits on how people can use Firefox, but they do have a strong interest in protecting users who don't have the technical savvy to evaluate the implementation of extensions they install (which I would hope anybody who is installing unsigned extensions does!) The system described above was built up (over the years!) in response to actual abuse of extensions by bad actors. The choice between having reasonable protections for the overwhelming majority of users versus offering flexibility in this case is a crummy one to have to make, but the compromise Mozilla settled on is allowing for unsigned extensions in developer edition, Nightly builds, or custom-made builds. You may personally prefer a different outcome for this decision but calling it "nonsense" or ascribing other motives to Mozilla sounds to me either uninformed or disingenuous (or maybe just unable to consider the reality of weighing the needs of different groups of users when making a decision like this).
My original comment was reacting to the description of signing as "nonsense" but there doesn't seem to be understanding of why it exists. In brief: Mozilla can (and does) block specific extensions when they are found to be doing something malicious. From what I have seen the bar for this is very high, this applies not just to extensions that do things like extract user data, but to those that do it in a deceptive way without disclosing to users what the extension does. Anyway, this blocking works based on a unique ID embedded in every extension. But if extensions were not signed, a bad extension could just claim to be "[email protected]" or something, trivially evading blocking. Signing isn't about somebody passing judgement on individual extensions, it is about ensuring that addon IDs are unique and not spoofable. You might reasonably say that there should be a user option to disable the signing requirement, but how would this work exactly? You wouldn't want the user to have to affirm that they want this setting every time they start the browser, which means it has to be stored somewhere on disk with other user settings. But this is, again, trivially forgeable by any software that has write access to the part of the system where user preferences are stored. I don't believe that anybody at Mozilla wants to put arbitrary limits on how people can use Firefox, but they do have a strong interest in protecting users who don't have the technical savvy to evaluate the implementation of extensions they install (which I would hope anybody who is installing unsigned extensions does!) The system described above was built up (over the years!) in response to actual abuse of extensions by bad actors. The choice between having reasonable protections for the overwhelming majority of users versus offering flexibility in this case is a crummy one to have to make, but the compromise Mozilla settled on is allowing for unsigned extensions in developer edition, Nightly builds, or custom-made builds. You may personally prefer a different outcome for this decision but calling it "nonsense" or ascribing other motives to Mozilla sounds to me either uninformed or disingenuous (or maybe just unable to consider the reality of weighing the needs of different groups of users when making a decision like this).
This is great. If FF updates and removes the tweak will it uninstall the extensions or otherwise mess them up?
Two notes on updates:
1) It will break partial updates, which means the first update attempt will fail, and then Firefox will fall back to a full update (larger, slower).
2) After the update is applied, yes - it will remove the tweak (because the enterity of omni.ja will have been replaced).
1) It will break partial updates, which means the first update attempt will fail, and then Firefox will fall back to a full update (larger, slower).
2) After the update is applied, yes - it will remove the tweak (because the enterity of omni.ja will have been replaced).
The extensions will just be disabled until the script is rerun.
* Firefox on linux (ubuntu to be specific)
It should work on any Linux as long as omni.ja is located at /usr/lib/firefox.
Is there a repository of these Firefox unsigned extensions?
Most extensions that exist are on Mozilla's Addons site. And unsigned extensions aren't commonly distributed because you just can't install them on normal Firefox, only Nightly or Developer Edition builds.
The main use-case of this is so that Mozilla doesn't have total control over what extensions are allowed to be installed.
It can also be used so you can install extensions you built-from-source.
The main use-case of this is so that Mozilla doesn't have total control over what extensions are allowed to be installed.
It can also be used so you can install extensions you built-from-source.
Personally I've found https://github.com/xiaoxiaoflood/firefox-scripts/tree/master... very nice and almost indispensable – working versions of DownThemAll [1] and Norwell History Tools hacked to continue running on modern Firefox.
[1] Yes, by now there's an official Webextension version of DownThemAll around again, too, but that's too much hobbled by the limitations of the Webextension API, i.e. can't download to outside of the official Downloads directory, can't intelligently/properly handle file name conflicts with already existing files [2], etc.
[2] Most importantly, the Webextension API doesn't seem to have a "skip the download if the file already exists" option – it's only overwrite, rename the new download, or prompt, and Firefox doesn't even support the "prompt" option.
[1] Yes, by now there's an official Webextension version of DownThemAll around again, too, but that's too much hobbled by the limitations of the Webextension API, i.e. can't download to outside of the official Downloads directory, can't intelligently/properly handle file name conflicts with already existing files [2], etc.
[2] Most importantly, the Webextension API doesn't seem to have a "skip the download if the file already exists" option – it's only overwrite, rename the new download, or prompt, and Firefox doesn't even support the "prompt" option.
Any possibility of getting this for windows?
Seems you should be able to read through the script and adjust accordingly pretty easily: https://gist.githubusercontent.com/TheBrokenRail/c43bf0f07f4...
Seems `firefox/omni.ja` is the relevant file to patch. If you run a bash terminal, you might be able to run the script by just changing the paths.
Seems `firefox/omni.ja` is the relevant file to patch. If you run a bash terminal, you might be able to run the script by just changing the paths.
AFAIR .ja format is compatible with .zip specification, but not all archivers follow it enough to understand some optimization made by Mozilla to load it faster - I had to use Info-ZIP under Windows.
It shouldn't be that hard to do manually.
The process is just extracting a ZIP file (omni.ja), editing modules/AppConstants.jsm to have MOZ_REQUIRE_SIGNING set to false, then put the ZIP file back together.
A quick Google search led me to https://udn.realityripple.com/docs/Mozilla/About_omni.ja_(fo..., which seems to have instructions for working with omni.ja on Windows.
The process is just extracting a ZIP file (omni.ja), editing modules/AppConstants.jsm to have MOZ_REQUIRE_SIGNING set to false, then put the ZIP file back together.
A quick Google search led me to https://udn.realityripple.com/docs/Mozilla/About_omni.ja_(fo..., which seems to have instructions for working with omni.ja on Windows.
https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...