Today we published a blog post detailing the changes coming to our Add-ons Policies. The new policies will take effect on 4 August, 2025. Changes include:
See the blog post for details. If you have questions about these updated policies or would like to provide feedback, please post them here.
Hi, the User Scripts API seems to target Manifest v3 extensions,
Does those limitations to API applies to Manifest v2 extensions?
Like, Extensions that install custom scripts will be enforced to use Manifest v3 or everything will keep as is for v2?
Hello,
I’m also interested in the userScripts part.
My add-on allows users to generate fake and random data. One of the features is to allow users to generate their own custom data using JS code, which becomes executed with eval(). The eval function is only used for code added by the user and nothing else.
The add-on has already been live for years but I wanted to make sure that there is nothing that I have to worry about moving forward with the new policies.
Thank you!
Overall, I appreciate how clear the summary is. However, I share the confusion of other users about the userScripts API. I don’t know if it needs to be laid out explicitly in the policy, but I think it would help to have detail somewhere that explains the motivation behind this restriction.
Hey @marcussacana, @ibrahim1, and @raffle, thanks for the questions!
Firefox actually has two different Users Scripts API implementations.
| Name | Reqs. | Description |
|---|---|---|
| User Scripts | MV2 | A new API that was designed in the WebExtensions Community Group in coordination with engineers from other web browsers. Supported by Chromium and Gecko. |
| User Scripts (legacy) | MV3 | Firefox’s original implementation of User Scripts. Only ever supported by Firefox. |
The user script manager requirement applies to both versions of the User Scripts API. Firefox supports both MV2 and MV3, so developers are not required to adopt Manifest V3.
Note that both the current and updated Add-ons Policies forbid the execution of remote code. That restriction has not changed. For historical reasons, some Manifest V2 user script managers use content scripts to inject and execute user scripts rather than the legacy User Scripts API. These extensions are not required to adopt the User Scripts API, but the limitation that only user script managers may execute user scripts still applies.
I found a link to Fake Data in your post history, so I assume that’s the add-on you’re referring to. While I can’t pre-review your add-on or make guarantees about the future, I can share my perspective here based on conversations with the review team.
Assuming that the screenshots on your AMO listing accurately represent your add-on’s current user experience, it looks like your add-on allows users to write their own scripts that are executed in response to a user action. As such, I think this extension can be classified as a user script manager.
I’m glad to hear you liked the summary 
The policy isn’t the right place for that kind of information, but we recently published an FAQ page for the updated policies. That might be a good place to put this.
Here’s an abbreviated version: arbitrary code execution creates significant risks for users and prevents extension distributors (AMO, CWS, etc.) from accurately accessing an extension’s risk during the review process. By limiting this capability to user script managers, we’re trying to strike a balance between giving users very powerful (but very dangerous) customization options without putting the entire extension userbase at risk.
Ah, so that restriction is primarily about loading of remote code at runtime (which would bypass review). Makes sense.
Yes, that’s the add-on I was referring to. Thank you for your response and clarification!
Hey @dotproto - Our company, Pieces, has had our Firefox add-on publicly listed for quite some time now, and we just recently started to encounter issues with the submission process flagging our source code as obfuscated. As a result, the review team is requiring us to upload all source code and related dependencies for review. The recent flagging has significantly interrupted our submissions, and is leaving our existing users in the dust.
After reviewing these updated policies, it seems Firefox is moving towards this requirement for ALL uploads, regardless of obfuscation or minification. You can imagine this is quite a security & confidentiality concern.
My question is how you expect orgs/enterprises who employ a certain level of code security and access permissions for their own packages, which often contain security-related code, to submit their extensions for review?
Also, as a result of these policies, are you anticipating a number of these types of add-on developers to simply drop support for Firefox?
That isn’t an accurate summary. Mozilla has required that developers provide source code for any add-on that contains machine-generated code since April 1, 2018 and stopped allowing obfuscated code on June 10, 2019. This update does not made any changes to these requirements.
Besides white-space, the only Source Code Submission policy change in this update was the addition of the following sentence to the second paragraph:
All dependencies must either be included in the source code package directly or downloaded only through the respective official package managers during the build process.
This is a new requirement, but it’s directly related to preexisting guidance on the Source Code Submission and Third Party Library Usage pages. This new line clarifies the allowable ways of providing a dependency to the dependency’s official package manager or by statically including the dependency in the source zip. I don’t expect that this change will have much impact on enterprise extension developers.