User:Jorge.villalobos/AddonGuidelines

Core Add-on Guidelines [Draft]

Mozilla expects all add-ons, and their updates, hosted on AMO or elsewhere, to follow these guidelines. They aren't exhaustive and don't necessarily apply to all add-ons. There are additional policies add-ons must follow in order to be listed on AMO.

Some of these guidelines may also apply to customizations performed by installers that configure Firefox without using an add-on.

Be Transparent

• Add-ons must either be installed using the add-on install system, or be approved by the user via 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 they do not like the result. Add-ons installed through application installers should either use the regular install mechanism (loading the URL of an XPI in a Firefox) or use the Windows Registry (or similar mechanisms on other operating systems) so that the opt-in screen appears next time Firefox starts.
• It must always be possible to disable or uninstall add-ons via 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 which includes the identity of the owner (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. Firefox Magical Frobber, for instance, is likely to mislead users about the developer of the add-on, whereas Magical Frobber for Firefox is not.
• Add-ons should clearly communicate their intended purpose and active features to users before they are installed, including new and unexpected features when they are 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 before they install the add-on, or immediately on first run.

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 and default search URLs, network settings, and so forth. These preferences should be restored to their previous values when the add-on is uninstalled. Traditional, non-restartless add-ons can most 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 highly 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 contact mechanism, such as an email address or a support forum, for users and for Mozilla to contact them about any issues which may arise.
  • 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 not 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 unless this is their expressly stated purpose.
  • This includes features like tabbed browsing, Private Browsing Mode, and the location bar. Add-ons which users install specifically for these purposes are, of course, 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

• These guidelines do not apply to add-ons with the express purpose of breaking any of them 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 intentionally malicious, or whose developers have proven unreachable or unresponsive, in which case blocklisting may immediate.

Guideline violations should be reported via Bugzilla, under Tech Evangelism > Add-ons. Important: if the blocklisting request is for a security matter which could alert malicious parties to an attack vector, you should check the box merked Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved when filing the bug. Questions about these policies can be posted in the #addons IRC channel.