Warning: This document has been moved to MDN. The following is retained for archival purposes only.

Add-on Guidelines [Draft]

These add-on guidelines were created to foster an open and diverse add-on developer community while ensuring an excellent user experience. They apply to all add-ons and add-on updates regardless of where they are hosted, and may also apply to customizations performed by installers that configure Firefox without using an add-on. Add-ons hosted on AMO are subject to additional policies.

Be Transparent

• Add-ons must either be installed using the add-on web install system, or be approved by the user using the install opt-in dialog.
  • We want our users to be aware of what they are installing so that they are not unpleasantly surprised by an add-on they did not expect. We also want them to know what add-on to remove if they decide not to keep it. Add-ons installed through application installers should use the Windows Registry or equivalent global install methods so that Firefox displays the opt-in screen. The opt-in screen must not be tampered with in any way, including overlaying additional information or images on top of it.
• Add-ons must always be possible to uninstall or disable from the Add-ons Manager.
  • Add-ons installed globally using the Windows registry or global extension directories cannot be uninstalled (bug 640775), but they can be disabled to the same effect.
• Add-ons must use a single unique ID during their entire lifetime.
  • Using the same ID for multiple products, or multiple IDs for a single product, can lead to problems with automatic updates, as well as blocklisting conflicts. Add-ons may change their IDs due to ownership changes, as they commonly use an email address-like format (e.g., personasplus@mozilla.com).
• Add-ons must not use brand names, trademarks, or other terms in ways that deceive users. Using Mozilla trademarks must follow our policy.
• Add-ons should clearly communicate their intended purpose and active features, including features added through updates.
  • While we understand and support add-on developers who choose to monetize their products, this should not come at the expense of users' browsing experience. If an add-on inserts advertisements, affiliate codes, sponsored search results, or the like, into content web pages, the user should be made aware of this when the add-on is installed. Likewise, if some features require payment to use, or will require payment to remain active after a trial period, users should be made aware of this.

Be Respectful to Users

• Add-ons must remove all introduced code, executables, and application configuration changes when they are uninstalled.
  • Uninstalling an add-on using the regular uninstall process should generally suffice. This guideline primarily applies to changes made to preferences not specific to the add-on such as the homepage, default search URL, network settings, and so forth. These preferences should be restored to their previous values when the add-on is uninstalled. Most add-ons can easily accomplish this by making such changes via a default preferences file.
• Add-ons should respect the users' choices and not make unexpected changes, or limit users' ability to revert them.
  • For instance, users generally do not expect an add-on to change the Firefox homepage. Asking users to opt-in to such extra changes is recommended. Making them difficult or impossible to revert is discouraged.
• Add-ons should make it clear how private user data is being used.
  • Add-ons which send user data over the Internet should generally provide a Privacy Policy. Bonus points if it is concise and easily readable.
• Add-on developers should provide a mechanism for them to be contacted.
  • While developers are not required to provide a support channel for users, it is recommended. All add-on developers should have a contact form or public email address so that they can be contacted in case of emergencies, such as guideline violations that could lead to blocklisting.

Be Safe

• Add-ons must not cause harm to users' data, system, or online identities.
• Add-ons must not transmit users' private data unsafely, or expose it to third parties unnecessarily.
  • Private data should always be sent over a secure connection. This includes browsing data such as visited URLs and bookmarks.
  • Making the browser easier to fingerprint by adding text to the User-Agent string or adding custom headers is also a privacy concern, and should be avoided.
• Add-ons must not create or expose application or system vulnerabilities.
  • Security bugs happen, but once discovered they need to be addressed immediately. A popular add-on with a security vulnerability is a valuable attack vector for hackers, and in such cases we will move quickly to blocklist the add-on if there is no prompt response from the developer.
• Add-ons must not tamper with the application or blocklist update systems.
• Add-ons should not store any browsing data while in Private Browsing Mode.
  • It's worth stressing that PBM is about avoiding storing local data while browsing, not about sending data elsewhere. To learn more about PBM we recommend Ehsan's blog posts about it.

Be Stable

• Add-ons must not cause hangs or crashes.
• Add-ons should not break or disable core application features.
  • This includes features like tabbed browsing, Private Browsing Mode, and the location bar. Add-ons which users install specifically for these purposes are exempt.
• Add-ons should not cause memory leaks, or unnecessarily consume large amounts of memory.
• Add-ons should not slow down the application or system significantly.
• Add-ons should not consume network resources to an extent that affects regular application usage.
  • Downloading large amounts of data without user awareness can significantly disrupt regular browsing, and may result in unexpected charges for users who have network usage limitations (notably on mobile).

Exceptions

• Add-ons with the intended purpose of breaking any of these guidelines with non-malicious intent (e.g., a security exploit proof of concept).
• Add-ons deployed by administrators within workplaces, schools, kiosks, and so forth, are exempt from most guidelines.
• As add-ons can only run clean up code if they are uninstalled while Firefox is running and they are enabled, we do not require that they attempt to clean up after themselves when they are uninstalled under other circumstances. Application installers that configure Firefox without add-ons should, however, also revert any changes when uninstalled.
• Add-ons may leave behind preferences changes in private preference branches which do not affect Firefox when the add-on is not active, so that any previous add-on configuration is not lost if the user decides to re-install the add-on in the future.

Other exceptions may apply.

Enforcement

Add-ons that do not follow these guidelines may qualify for blocklisting, depending on the extent of the violations. Guidelines qualified with the word must are especially important, and violations thereof will most likely result in a blocklisting nomination.

The Add-ons Team will do their best to contact the add-on's developers and provide a reasonable time frame for the problems to be corrected before a block is put in place. Exceptions are made only for add-ons which are considered malicious, or whose developers have proven unreachable or unresponsive, in which case blocklisting may be immediate.

Guideline violations should be reported via Bugzilla, under Tech Evangelism > Add-ons. Questions can be posted in the #addons IRC channel.

These guidelines may change in the future. All updates will be announced in the Add-ons Blog.