Hello!
The previous discussion was so long (and successful!) that I am creating
a separate thread for this new draft, for the benefit of all. This takes
into account the feedback I've received so far, so if there's something
you think I overlooked, please bring it up again. This version will be
posted soon to the Add-ons Blog (also as a draft) in order to get more
feedback from the add-on developer community.
The changes include much more specific install and uninstall guidelines,
expanded Exceptions and Enforcement sections, a preface explaining what
this all means, and additional guidelines covering Private Browsing,
breaking core features, and consuming network resources.
I'm sorry for taking so long with this, but I was sidetracked with some
policy violations that were brought up in the previous discussion. I
also haven't yet posted the ideas that we have to improve our reaction
to add-on problems. That will have to wait a week or two, but it's coming!
Let me know your thoughts. Thanks!
Jorge
** Mozilla Add-on Policies (Draft) **
Mozilla expects all add-ons, and their updates, hosted on AMO or
elsewhere, to follow these guidelines. These guidelines are not
exhaustive and don't necessarily apply to all add-ons (see Exceptions).
* Be Transparent *
* Add-ons must be installed either using the add-on install system or
the install opt-in dialog
[https://blog.mozilla.org/addons/2011/08/11/strengthening-user-control-of-add-ons/].
* Add-ons must always be possible to uninstall or disable from the
Add-ons Manager.
* Add-ons must use a single unique id
[https://developer.mozilla.org/en/install_manifests#id] during their
entire lifetime.
* Add-ons must not use brand names, trademarks or terms in ways that
deceive users. Using Mozilla trademarks must follow our policy
[http://www.mozilla.org/foundation/trademarks/policy.html].
* Add-ons should clearly communicate their intended purpose and active
features, including features added through updates.
* Be Respectful to Users *
* Add-ons must remove all introduced code, executables, and application
configuration changes once they are uninstalled.
* Add-ons should not disrespect the user's choices by making unexpected
changes or limiting the user's ability to revert them.
* Add-ons should make it clear how private user data is being used.
* Add-on developers should provide a mechanism for them to be contacted.
* Be Safe *
* Add-ons must not cause harm to the user's data, system or online
identities.
* Add-ons must not unsafely transmit the user's private data or expose
it to third parties.
* Add-ons must not create or expose application or system vulnerabilities.
* 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.
* Be Stable *
* Add-ons must not cause hangs or crashes.
* Add-ons should not break or disable core application features.
* 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.
* Exceptions *
* Add-ons with the intended purpose of breaking any of these guidelines
with non-malicious intent. For example, a security exploit proof of concept.
* Add-ons installed globally using the Windows registry cannot be
uninstalled (bug 640775), but they can be disabled to the same effect.
* Add-ons deployed by administrators within workplaces, schools, kiosks,
etc., are exempt from most guidelines.
* Add-ons can only run clean up code if they are uninstalled while
Firefox is running and they are enabled. This is the only case where it
is a requirement for add-ons to clean up after themselves.
* Add-ons can leave behind preferences that have been changed in their
own preference branch. These have no effect in Firefox when the add-on
is not active.
* Add-ons may need to change their ids due to ownership changes, since
they are commonly in an email address format (e.g.
[email protected]).
Other exceptions may apply.
* Enforcement *
If an add-on breaks any of the /must/ guidelines, or one or more the
/should/ guidelines to a significant extent, it qualifies for blocklisting.
Per blocklisting policy [https://wiki.mozilla.org/Blocklisting], Mozilla
will do their best to contact the developer and provide a reasonable
time frame for the problems to be corrected before a block is put in
place. The only exception to this are add-ons that are considered to be
malicious or whose developers have proven to be unreachable or unresponsive.
Monitoring compliance and enforcing these guidelines is responsibility
of the Mozilla Add-ons Team. If you have any questions about them or you
would like to report a policy violation, please contact us at <TBD>.
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
