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!