ANDROID: Installing extensions from addons.mozilla.org is broken when mozAddonManager is unavailable/disabled
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
People
(Reporter: celenity, Unassigned, NeedInfo)
References
Details
When privacy.resistFingerprinting.block_mozAddonManager is set to true in the about:config (or via some other mechanism) on Android, installing add-ons from addons.mozilla.org is broken. For reference; when privacy.resistFingerprinting.block_mozAddonManager is set to true on desktop, addons.mozilla.org will fallback and still install extensions as expected. Android should have a similar fallback mechanism in place.
|
||
Comment 1•8 months ago
|
||
I reproduced the issue on the latest Nightly for Android (138.0a1- GV: 20250304094020) on an Oppo Reno 6 running Android 13.
Toggling the pref to “true” will treat the .xpi downloaded from addons.mozilla.org as a normal file and will simply download it/not offer to install it. On Desktop it will install it.
On Beta 137 and Release 136, I cannot access about:config to flip the pref due to Bug 1949695.
|
||
Comment 2•7 months ago
|
||
The severity field is not set for this bug.
:willdurand, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 3•7 months ago
|
||
We do not allow install on navigation on Firefox for Android (which is what you're describing), and that's on purpose. The alternative is to use "install from file" from the debug menu: https://firefox-source-docs.mozilla.org/mobile/android/fenix/Secret-settings-debug-menu-instructions.html
|
||
Comment 4•7 months ago
|
||
If you want to install add-ons on Firefox for Android from AMO, do not toggle the privacy.resistFingerprinting.block_mozAddonManager preference. The preference controls the ability for AMO to query installed extensions (so that it can show the Install or Remove button as needed) and to trigger new extension installations (when Install is clicked). It does not expose any functionality to any other websites, and you can check that for yourself in the source code: access control check and API definition.
For more context, this preference was introduced in bug 1384330, for the Tor Browser. The Tor browser discourages the installation of new add-ons (e.g. "strongly discouraged to install new add-ons in Tor Browser" at https://support.torproject.org/tbb/tbb-14/). In that light, removing functionality from AMO is an understandable trade-off between usability and strict privacy. If your intent is to install add-ons from AMO, it does not really make sense to disable the functionality on AMO.
On Android, regular websites cannot initiate extension installations. When the mozAddonManager functionality is dropped, AMO is unable to initiate extension installations. On desktop, a warning prompt is shown to warn of third-party installations, but that has not been implemented on Android (because there is no observer for the "addon-install-blocked" notification).
(In reply to Alex Cornestean from comment #1)
On Beta 137 and Release 136, I cannot access about:config to flip the pref due to Bug 1949695.
Side note: The removal of about:config on Beta was not intentional, so that functionality has been restored (in Beta 137).
|
Reporter | |
Comment 5•7 months ago
|
||
:robwu Thanks for your response, apologies for the late reply here (somehow I missed the notification...). I appreciate you taking the time to explain/elaborate on this.
If you want to install add-ons on Firefox for Android from AMO, do not toggle the privacy.resistFingerprinting.block_mozAddonManager preference. The preference controls the ability for AMO to query installed extensions (so that it can show the Install or Remove button as needed) and to trigger new extension installations (when Install is clicked). It does not expose any functionality to any other websites, and you can check that for yourself in the source code: access control check and API definition.
For more context, this preference was introduced in bug 1384330, for the Tor Browser. The Tor browser discourages the installation of new add-ons (e.g. "strongly discouraged to install new add-ons in Tor Browser" at https://support.torproject.org/tbb/tbb-14/). In that light, removing functionality from AMO is an understandable trade-off between usability and strict privacy. If your intent is to install add-ons from AMO, it does not really make sense to disable the functionality on AMO.
I understand your point; my concern was mainly just due to the differing behavior between Android and Desktop. On Desktop, users can still install extensions from the AMO when privacy.resistFingerprinting.block_mozAddonManager is set to true, so I don't think users see much of an impact from the loss in functionality in exchange for the privacy & security improvement that it provides. This is clearly not the case for Android; since disabling this as it stands breaks installing extensions from the AMO completely. I was just hoping there'd be some kind of fallback in place for Android like we have on desktop, but I understand why this isn't currently the case due to your next point below.
On Android, regular websites cannot initiate extension installations. When the mozAddonManager functionality is dropped, AMO is unable to initiate extension installations. On desktop, a warning prompt is shown to warn of third-party installations, but that has not been implemented on Android (because there is no observer for the "addon-install-blocked" notification).
To confirm, is this something eventually planned for Android?
|
|
||
Comment 6•7 months ago
|
||
We have no plans to support third-party installation from arbitrary websites on Android. As explained, there is no point in toggling the preference. If you really want to toggle the preference, and still want to install add-ons, use Nightly. After downloading the xpi file, the extension can be installed as explained in comment 3.
|
|
Reporter | |
Comment 7•7 months ago
|
||
:robwu
We have no plans to support third-party installation from arbitrary websites on Android.
OK, I think that's probably for the best, thanks for confirming.
|
|
Reporter | |
Comment 8•5 months ago
|
||
So after doing further research, it looks like Tor Browser actually went out of their way to create a patch to fix this exact issue (allowing the installation of addons from addons.mozilla.org without mozAddonManager - For reference, their related issue can be found here).
Would it not be possible to uplift their patch here or use something similar? This would benefit both Tor folks (as well as other derivatives - for instance, we (IronFox) would also use this), and advanced Firefox users who prefer to disable mozAddonManager due to the privacy & security concerns (at the cost of certain AMO functionality). It looks like Tor's patch also hardcodes the XPI handler to only allow installation of add-ons from https://addons.mozilla.org - so this would still prevent third party websites from being able to install add-ons.
For GeckoView embedders, we could presumably still disable the ability to install extensions by default with the xpinstall.enabled pref and a corresponding GeckoRuntimeSetting (something like what we currently have for ExtensionsWebAPIEnabled/extensions.webapi.enabled), and of course override it for Firefox.
In light of this information, I'll go ahead and re-open this; curious to hear thoughts.
|
||
Comment 9•5 months ago
|
||
We are always in for uplifting patches as long as they work for Firefox 😄️.
Cc'ing also Giorgio, who worked on this patch.
|
|
||
Comment 10•5 months ago
|
||
At this time, we still have no plans to support installs on navigation.
|
|
Reporter | |
Comment 11•5 months ago
|
||
At this time, we still have no plans to support installs on navigation.
You already support installing add-ons on navigation from addons.mozilla.org on Android though? The problem is that this currently requires the privileged mozAddonManager API, which poses privacy (fingerprinting - it allows Mozilla to enumerate a user's installed add-ons. It also prevents add-ons like uBlock Origin and NoScript from working on the AMO - though add-ons still can't access the AMO by default regardless, due to the extensions.webextensions.restrictedDomains pref), and security (adds additional attack surface) concerns for users. All this change would do is allow users who disable mozAddonManager (ex. via the privacy.resistFingerprinting.block_mozAddonManager/extensions.webapi.enabled prefs) to still install add-ons from addons.mozilla.org. To confirm, this change would NOT allow arbitrary websites to install add-ons; Tor's patch explicitly hardcodes it to only allow installation from addons.mozilla.org.
So I have to admit I'm very confused by this statement, and would appreciate it if you could elaborate on your position. This change would directly improve the privacy and security of users, by allowing them to disable the mozAddonManager API without sacrificing what many consider to be critical functionality (the ability to install add-ons from the AMO). The work is also already done here via Tor's patch (I assume you'd only need to make minor changes), and since this change would only impact those who disable the mozAddonManager API, IMO it'd be very low risk. I doubt there'd be a burden on maintenance here as well, as this just re-uses the XPI handler component from desktop.
This is also the current behavior on desktop (Add-ons can still be installed from the AMO without the mozAddonManager API), so It's unclear to me why this behavior is acceptable there, but not on Android (especially since unlike on desktop, this change still prevents arbitrary websites from being able to install add-ons)? Not implementing this also seems at odds with Mozilla's initiatives/stated goals, such as the Tor Uplift Project, which states:
The intention of Tor Uplift project is to land all Tor Browser patches so that Tor can directly use Firefox main trunk instead of a fork.
Of course, you should ultimately do what's best for Firefox. Due to the reasoning above (as well as other reasons) though, I would have to strongly disagree with the decision to not support this. I think there may have been a misunderstanding here based on your statement (I think you maybe thought I was requesting arbitrary websites be able to install add-ons?), so I hope this helped to provide you with more context, and I hope you'll be able to reconsider your position on this (and if not: it'd at least go a long way if you could provide more information/context for the reasoning here). If you still think it's best for Firefox on Android not to support this, I'll be disappointed - but will accept and respect your decision nonetheless. Thank you for your time and work on this.
Description
•