There have been a number of situations in the past few weeks that have prompted modifications to our established Review Policies. Most of them have already been announced in a different number of ways, but it’s a good idea to sum them up in a single post.
The policy page won’t be updated until the next AMO release, sometime in mid April, but most of these policies are already in place, and the AMO Editor team is making sure they are followed.
Adding advertisements to web pages is strictly forbidden
Content producers often place ads on their sites in order to make money, and that’s OK. Ads can be annoying and intrusive, sometimes making the reading experience awkward or even impossible. So there are add-ons designed to filter out advertisements, and we think that’s OK as well.
What’s not OK in our minds is for add-ons to take advantage of web content and embed their own advertisements on it. To be able to filter ads in order to provide greater user control is one thing. To replace or extend advertisements for financial gain, at the expense of user control, is something else entirely.
We’ve never had to think about this before, but it was brought to our attention that a framework called FatPlug was designed for this specific purpose, and many add-on authors had been approached in order to include it in their add-ons.
To be perfectly clear: no add-ons using FatPlug will be allowed on AMO, not even in the sandbox. We’ll be adding a flag in our code validator very soon.
Generalization of No Surprises
Our No Surpises policy succinctly explains that we demand nothing less than complete transparency from add-ons:
Surprises can be appropriate in many situations, but they are not welcome when user security, privacy, and control are at stake. It is extremely important to be as transparent as possible when submitting an add-on for hosting on this site. A Mozilla user should be able to easily discern what the functionality of your add-on is and not be presented with unexpected user experiences post-install.
The policy document will be updated soon.
Conduit toolbar add-ons allowed, with restrictions
Conduit toolbars used to be forbidden on AMO, partly because of the sheer amount of add-ons being submitted, and more importantly because of problems with their quality and privacy standards. All of these issues have been worked out with Conduit and we have been in constant communication with them in order to make Conduit toolbars acceptable again on AMO.
A couple of months ago we finally reached the point where we all think it’s OK to allow Conduit add-ons. However, in order to make sure they are all held to the same standards, only Conduit-approved add-ons will be accepted for review. If you’re interested in listing your Conduit add-on on AMO, please contact Conduit about it.
Like I said, this isn’t a recent decision, but I was reminded of a promise made about announcing it.
Private Browsing Mode Support
PBM support will become a requirement beginning April. Make sure you read and understand that post. This will be included in our policy page very soon.
codebase_principal_support and enablePrivilege no longer allowed
Support for the signed.applets.codebase_principal_support preference and the enablePrivilege function will be dropped soon. Add-on authors that rely on this feature will need to find alternatives for it immediately, and editors are already rejecting add-ons that use it.
I wouldn’t count this as policy, but I thought it’d be good to include.