Draft: Add-on Policies V2

Showing 1-23 of 23 messages
Draft: Add-on Policies V2 Jorge Villalobos 7/19/12 4:27 PM
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.
person...@mozilla.com).

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>.
Re: Draft: Add-on Policies V2 Henri Sivonen 7/20/12 3:33 AM
On Fri, Jul 20, 2012 at 2:27 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
> * 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/].
...
> 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.

To me, it makes sense to give "a reasonable timeframe for the problems
to be corrected before a block is put in place" before blocking
extensions over accidental violations. Violations of the installation
guideline typically seem obviously intentional. I don't see why we
should give extension developers who violate the installation
guideline in a way that looks intentional the benefit of the doubt and
wait before blocklisting.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Re: Draft: Add-on Policies V2 David Bruant 7/20/12 3:40 AM
Le 20/07/2012 12:33, Henri Sivonen a �crit :
Not enabling to uninstall the extension, storing information in private
mode (I'm less sure for this one) or tampering with the application or
blocklist update systems. seems like things to be added to the list of
"intentional things that shouldn't require a delay before blocking".

For things that shows intentional harm, there shouldn't be a need for a
delay (to do a softblock), I agree.

David
Re: Draft: Add-on Policies V2 Mike Connor 7/20/12 9:18 AM

On 2012-07-20, at 6:40 AM, David Bruant wrote:

> storing information in private mode (I'm less sure for this one) or tampering with the application or blocklist update systems. seems like things to be added to the list of "intentional things that shouldn't require a delay before blocking".

I don't think "storing information in private mode" is a black and white rule.  Failing to observe state sanely is an easy mistake to make.  Deliberately subverting private mode is another story, of course.

-- Mike
Re: Draft: Add-on Policies V2 Kris Maglione 7/20/12 11:31 AM
Because it's quite often not done with malicious intent. External
installers, especially from things like anti-virus software, but often
enough from sites that for some reason make you download a .exe
installer rather than just installing the XPI directly, very often ask
users whether they want the add-on installed (though opt-out rather than
opt-in) and then bypass about:newaddon because they feel that
confirmation is enough. We disagree, which is why we give them the
opportunity to fix it before we simply block their add-ons. It also
doesn't help that quite a lot of users will be upset by having add-ons
disabled after they've asked that they be there.

Re: Draft: Add-on Policies V2 Henri Sivonen 7/23/12 12:40 AM
On Fri, Jul 20, 2012 at 9:31 PM, Kris Maglione <kmag...@mozilla.com> wrote:
> On 07/20/2012 06:33 AM, Henri Sivonen wrote:
>>
>> On Fri, Jul 20, 2012 at 2:27 AM, Jorge Villalobos<jo...@mozilla.com>
>> wrote:
>>>
>>> * 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/].
>>
>> ...
>>
>>> 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.
>>
>>
>> To me, it makes sense to give "a reasonable timeframe for the problems
>> to be corrected before a block is put in place" before blocking
>> extensions over accidental violations. Violations of the installation
>> guideline typically seem obviously intentional. I don't see why we
>> should give extension developers who violate the installation
>> guideline in a way that looks intentional the benefit of the doubt and
>> wait before blocklisting.
>
> Because it's quite often not done with malicious intent.

Well, even if extensions authors who do that think they don't have
malicious intent, surely it has to be clear to them that they are
deliberately circumventing a mechanism that Mozilla has put in place
to ensure that the user user is in control.

> External
> installers, especially from things like anti-virus software, but often
> enough from sites that for some reason make you download a .exe installer
> rather than just installing the XPI directly, very often ask users whether
> they want the add-on installed (though opt-out rather than opt-in) and then
> bypass about:newaddon because they feel that confirmation is enough. We
> disagree, which is why we give them the opportunity to fix it before we
> simply block their add-ons. It also doesn't help that quite a lot of users
> will be upset by having add-ons disabled after they've asked that they be
> there.

I think we shouldn't be giving add-ons that circumvent our mechanism
like that the benefit of the doubt. Therefore, I suggest we eliminate
the doubt by making identifiers used by our implementation obviously
self-documenting. I suggest we rename extensions.enabledScopes to
add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.enabledScopes,
extensions.autoDisableScopes to
add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.autoDisableScopes
and similarly prefixing other prefs or file names used for tracking
the add-on installation state. This way, we'd have no excuse to wait
before blocklisting add-ons that circumvent the mechanism that puts
users in control of add-on installation.
Re: Draft: Add-on Policies V2 Blair McBride 7/24/12 7:17 PM
On 20/07/2012 11:27 a.m., Jorge Villalobos wrote:
> * Add-ons installed globally using the Windows registry cannot be
> uninstalled (bug 640775), but they can be disabled to the same effect.

In Add-ons Manager terminology, this is a "locked location". The Windows
registry is only one of a few of these that we support - everything
outside the Firefox profile is a located location. For example, there's
a couple of standard system-wide directory locations (eg,
/usr/lib/mozilla/extensions), and one in the OS's user profile directory
(eg, ~/.mozilla/extensions).

So I'd reword that to be something like:
* Add-ons installed outside the Firefox profile directory (eg, using the
Windows registry) cannot be uninstalled (bug 640775), but they can be
disabled to the same effect.


Also, should the policy be using "Firefox", or some generic name for an
application? Presumably this policy applies to add-ons for other
applications that AMO supports.

- Blair
Re: Draft: Add-on Policies V2 Henri Sivonen 7/24/12 11:56 PM
On Mon, Jul 23, 2012 at 10:40 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> I think we shouldn't be giving add-ons that circumvent our mechanism
> like that the benefit of the doubt. Therefore, I suggest we eliminate
> the doubt by making identifiers used by our implementation obviously
> self-documenting. I suggest we rename extensions.enabledScopes to
> add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.enabledScopes,
> extensions.autoDisableScopes to
> add-ons_caught_touching_this_will_be_considered_to_be_malware.extensions.autoDisableScopes
> and similarly prefixing other prefs or file names used for tracking
> the add-on installation state. This way, we'd have no excuse to wait
> before blocklisting add-ons that circumvent the mechanism that puts
> users in control of add-on installation.

Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=777249
Re: Draft: Add-on Policies V2 Jorge Villalobos 7/25/12 8:42 AM
On 7/24/12 7:17 PM, Blair McBride wrote:
> Also, should the policy be using "Firefox", or some generic name for an
> application? Presumably this policy applies to add-ons for other
> applications that AMO supports.
>
> - Blair

While I don't think we'll be doing much to police issues for other
applications, I did try to avoid mentioning Firefox anywhere in the
policies to keep it open, but I see I missed a couple of places.

Jorge
Re: Draft: Add-on Policies V2 Jorge Villalobos 7/25/12 8:42 AM
On 7/24/12 7:17 PM, Blair McBride wrote:
> Also, should the policy be using "Firefox", or some generic name for an
> application? Presumably this policy applies to add-ons for other
> applications that AMO supports.
>
> - Blair

Re: Draft: Add-on Policies V2 Michael Verdi 8/17/12 3:38 PM
On Thursday, July 19, 2012 6:27:13 PM UTC-5, Jorge Villalobos wrote:
>  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!

Have these been posted yet? The Support team in particular is interested in hearing about these. Bad add-on behavior is historically our largest support issue. Larger than crashes and only recently eclipsed by Flash 11.3 troubles. Improving the situation is one of our top priorities.


> 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).
>

Yes! This is great. I think it's crucial that these also apply to add-ons not hosted on AMO. I have a few more suggestions below that I think are important to doing right by our users.


> * Add-ons must remove all introduced code, executables, and application
>
> configuration changes once they are uninstalled.

I agree 100%. I also have some questions and concerns about things I've seen. The more I look into this, the more I see that Firefox preferences seem to be changed by a software installer that also installs an add-on. So, even if you get to opt-out of the add-on install, the preference change (home page and/or search) still happens and no method of reverting these changes is provided. What can we do about this? Does the "add-ons" term cover the software used to install them?

>
> * Add-ons should not disrespect the user's choices by making unexpected
>
> changes or limiting the user's ability to revert them.

I think this should be a "must not" rather than a "should not." This is the thing that sends 1.3 million people a month to SUMO looking for a solution. Many more people just live with the changes, not having the time or skill to seek out help. These are the practices that add-on makers use to ensnare users. These practices take away user sovereignty and they damage our brand.

The main practice that causes "unexpected changes" is the opt-out checkbox. Presenting add-on installs and preference changes as opt-out does not count as a user's intent. Millions of people have said this to us.



> * Exceptions *
>
> * 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.
>

Does this mean that if an add-on is removed by using it's program's associated uninstaller, it won't have to/can't revert Firefox preferences that it changed? If so is there anything that could be done to make this easier for users?


>
> * 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.

I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.


There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.


> The previous discussion was so long (and successful!) that I am creating
>
> a separate thread for this new draft, for the benefit of all.

I was expecting a followup in the other thread so I only just discovered this one today. :(

Re: Draft: Add-on Policies V2 Michael Verdi 8/17/12 3:38 PM
On Thursday, July 19, 2012 6:27:13 PM UTC-5, Jorge Villalobos wrote:
>  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!

Have these been posted yet? The Support team in particular is interested in hearing about these. Bad add-on behavior is historically our largest support issue. Larger than crashes and only recently eclipsed by Flash 11.3 troubles. Improving the situation is one of our top priorities.


> 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).
>

Yes! This is great. I think it's crucial that these also apply to add-ons not hosted on AMO. I have a few more suggestions below that I think are important to doing right by our users.


> * Add-ons must remove all introduced code, executables, and application
>
> configuration changes once they are uninstalled.

I agree 100%. I also have some questions and concerns about things I've seen. The more I look into this, the more I see that Firefox preferences seem to be changed by a software installer that also installs an add-on. So, even if you get to opt-out of the add-on install, the preference change (home page and/or search) still happens and no method of reverting these changes is provided. What can we do about this? Does the "add-ons" term cover the software used to install them?

>
> * Add-ons should not disrespect the user's choices by making unexpected
>
> changes or limiting the user's ability to revert them.

I think this should be a "must not" rather than a "should not." This is the thing that sends 1.3 million people a month to SUMO looking for a solution. Many more people just live with the changes, not having the time or skill to seek out help. These are the practices that add-on makers use to ensnare users. These practices take away user sovereignty and they damage our brand.

The main practice that causes "unexpected changes" is the opt-out checkbox. Presenting add-on installs and preference changes as opt-out does not count as a user's intent. Millions of people have said this to us.



> * Exceptions *
>
> * 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.
>

Does this mean that if an add-on is removed by using it's program's associated uninstaller, it won't have to/can't revert Firefox preferences that it changed? If so is there anything that could be done to make this easier for users?


>
> * 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.

I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.


There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.


> The previous discussion was so long (and successful!) that I am creating
>
> a separate thread for this new draft, for the benefit of all.

Re: Draft: Add-on Policies V2 Justin Lebar 8/17/12 3:41 PM
While we're resurrecting this thread: It was mentioned a few times
that your team has a plan for doing QA of existing add-ons, and that
we'd hear about this plan soon.  What is the status of this plan?

It's hard to overstate how important it is for us to test the software
our users actually run.
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
Re: Draft: Add-on Policies V2 Jorge Villalobos 8/17/12 4:51 PM
On 8/17/12 4:38 PM, Michael Verdi wrote:
> On Thursday, July 19, 2012 6:27:13 PM UTC-5, Jorge Villalobos wrote:
>>   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!
>
> Have these been posted yet? The Support team in particular is interested in hearing about these. Bad add-on behavior is historically our largest support issue. Larger than crashes and only recently eclipsed by Flash 11.3 troubles. Improving the situation is one of our top priorities.

A couple of people asked me to hold off on posting this until I got
their feedback about it. Since they are major stakeholders in this
process I have been waiting patiently. I have been putting some pressure
on them because I also really want this out soon.

>
>
>> 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).
>>
>
> Yes! This is great. I think it's crucial that these also apply to add-ons not hosted on AMO. I have a few more suggestions below that I think are important to doing right by our users.
>
>
>> * Add-ons must remove all introduced code, executables, and application
>>
>> configuration changes once they are uninstalled.
>
> I agree 100%. I also have some questions and concerns about things I've seen. The more I look into this, the more I see that Firefox preferences seem to be changed by a software installer that also installs an add-on. So, even if you get to opt-out of the add-on install, the preference change (home page and/or search) still happens and no method of reverting these changes is provided. What can we do about this? Does the "add-ons" term cover the software used to install them?
>

That's a good question, and I've been thinking about this too. While our
policies are meant for add-ons, I think that most of them apply to other
customizations introduced by external software. It might be worth
mentioning this in the opening statements in the policy.

>>
>> * Add-ons should not disrespect the user's choices by making unexpected
>>
>> changes or limiting the user's ability to revert them.
>
> I think this should be a "must not" rather than a "should not." This is the thing that sends 1.3 million people a month to SUMO looking for a solution. Many more people just live with the changes, not having the time or skill to seek out help. These are the practices that add-on makers use to ensnare users. These practices take away user sovereignty and they damage our brand.
>
> The main practice that causes "unexpected changes" is the opt-out checkbox. Presenting add-on installs and preference changes as opt-out does not count as a user's intent. Millions of people have said this to us.
>
>
>
>> * Exceptions *
>>
>> * 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.
>>
>
> Does this mean that if an add-on is removed by using it's program's associated uninstaller, it won't have to/can't revert Firefox preferences that it changed? If so is there anything that could be done to make this easier for users?

Program uninstallers are perfectly capable of making preference changes,
so that's another case that should be added there, yes.

>
>
>>
>> * 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.
>
> I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.

That is the first policy on the list.

>
>
> There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.
>

I don't know about that. In the case of AV vendors, I can see how
browser add-ons are a critical piece in the protection package, given
that the browser is one of the most frequent attack vectors. It can be
considered a core feature, and as such I think it makes sense for it to
be part of the recommended install.

Moreover, if we have our opt-in screen and we're already requiring them
to use it, asking them for a double opt-in seems unreasonable to me.

>
>> The previous discussion was so long (and successful!) that I am creating
>>
>> a separate thread for this new draft, for the benefit of all.
>
> I was expecting a followup in the other thread so I only just discovered this one today. :(
>

Ah, sorry for that.

Jorge

Re: Draft: Add-on Policies V2 Jorge Villalobos 8/17/12 4:51 PM
On 8/17/12 4:38 PM, Michael Verdi wrote:
> On Thursday, July 19, 2012 6:27:13 PM UTC-5, Jorge Villalobos wrote:
>>   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!
>
> Have these been posted yet? The Support team in particular is interested in hearing about these. Bad add-on behavior is historically our largest support issue. Larger than crashes and only recently eclipsed by Flash 11.3 troubles. Improving the situation is one of our top priorities.

A couple of people asked me to hold off on posting this until I got
their feedback about it. Since they are major stakeholders in this
process I have been waiting patiently. I have been putting some pressure
on them because I also really want this out soon.

>
>
>> 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).
>>
>
> Yes! This is great. I think it's crucial that these also apply to add-ons not hosted on AMO. I have a few more suggestions below that I think are important to doing right by our users.
>
>
>> * Add-ons must remove all introduced code, executables, and application
>>
>> configuration changes once they are uninstalled.
>
> I agree 100%. I also have some questions and concerns about things I've seen. The more I look into this, the more I see that Firefox preferences seem to be changed by a software installer that also installs an add-on. So, even if you get to opt-out of the add-on install, the preference change (home page and/or search) still happens and no method of reverting these changes is provided. What can we do about this? Does the "add-ons" term cover the software used to install them?
>

That's a good question, and I've been thinking about this too. While our
policies are meant for add-ons, I think that most of them apply to other
customizations introduced by external software. It might be worth
mentioning this in the opening statements in the policy.

>>
>> * Add-ons should not disrespect the user's choices by making unexpected
>>
>> changes or limiting the user's ability to revert them.
>
> I think this should be a "must not" rather than a "should not." This is the thing that sends 1.3 million people a month to SUMO looking for a solution. Many more people just live with the changes, not having the time or skill to seek out help. These are the practices that add-on makers use to ensnare users. These practices take away user sovereignty and they damage our brand.
>
> The main practice that causes "unexpected changes" is the opt-out checkbox. Presenting add-on installs and preference changes as opt-out does not count as a user's intent. Millions of people have said this to us.
>
>
>
>> * Exceptions *
>>
>> * 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.
>>
>
> Does this mean that if an add-on is removed by using it's program's associated uninstaller, it won't have to/can't revert Firefox preferences that it changed? If so is there anything that could be done to make this easier for users?

Program uninstallers are perfectly capable of making preference changes,
so that's another case that should be added there, yes.

>
>
>>
>> * 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.
>
> I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.

That is the first policy on the list.

>
>
> There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.
>

I don't know about that. In the case of AV vendors, I can see how
browser add-ons are a critical piece in the protection package, given
that the browser is one of the most frequent attack vectors. It can be
considered a core feature, and as such I think it makes sense for it to
be part of the recommended install.

Moreover, if we have our opt-in screen and we're already requiring them
to use it, asking them for a double opt-in seems unreasonable to me.

>
>> The previous discussion was so long (and successful!) that I am creating
>>
>> a separate thread for this new draft, for the benefit of all.
>
> I was expecting a followup in the other thread so I only just discovered this one today. :(
>

Re: Draft: Add-on Policies V2 Michael Verdi 8/20/12 1:56 PM
On Friday, August 17, 2012 6:51:51 PM UTC-5, Jorge Villalobos wrote:
>
> > I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.
>
>
>
> That is the first policy on the list.
>
>

Of course. I totally missed that.

>
> >
>
> >
>
> > There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.
>
> >
>
>
>
> I don't know about that. In the case of AV vendors, I can see how
>
> browser add-ons are a critical piece in the protection package, given
>
> that the browser is one of the most frequent attack vectors. It can be
>
> considered a core feature, and as such I think it makes sense for it to
>
> be part of the recommended install.
>
>
>
> Moreover, if we have our opt-in screen and we're already requiring them
>
> to use it, asking them for a double opt-in seems unreasonable to me.
>

Fair enough. Maybe this can be a "should not" thing with some guidelines? For example, out-out bundling of McAffee with a Flash update is not core functionality. Neither is the Ask Toolbar critical to the installation of Trillian. Those are the kinds of things I'm particularly concerned about. I was at my mother's house last night and she has Chrome installed but no idea how it got there (they've done a number of opt-out bundles).
Re: Draft: Add-on Policies V2 Michael Verdi 8/20/12 1:56 PM
On Friday, August 17, 2012 6:51:51 PM UTC-5, Jorge Villalobos wrote:
>
> > I agree with others in this thread that intentional violations should blocked right away. Specifically, I think this includes add-ons that try to circumvent, tamper or alter our install dialogs. I think we should call that out as a "must not" rule.
>
>
>
> That is the first policy on the list.
>
>

Of course. I totally missed that.

>
> >
>
> >
>
> > There is one more thing I'd like to suggest here. I think we should take a leadership position on behalf of all internet users and say that add-ons "should not" be bundled on an opt-out basis. That practice is such a problem - not only for us but other browser makers too. To me it feels like the kind of thing that an organization that promises "We answer to no one buy you" would do. Of course simply stating that doesn't mean software makers will just change their behavior but we have a good history of being able to promote ideas that are good for the web and getting people and companies to get on board.
>
> >
>
>
>
> I don't know about that. In the case of AV vendors, I can see how
>
> browser add-ons are a critical piece in the protection package, given
>
> that the browser is one of the most frequent attack vectors. It can be
>
> considered a core feature, and as such I think it makes sense for it to
>
> be part of the recommended install.
>
>
>
> Moreover, if we have our opt-in screen and we're already requiring them
>
> to use it, asking them for a double opt-in seems unreasonable to me.
>

Re: Draft: Add-on Policies V2 Jorge Villalobos 9/6/12 10:29 AM
I have finally posted the guidelines in the blog:
https://blog.mozilla.org/addons/2012/09/06/introducing-the-add-on-guidelines/

The updated guidelines (V3) are on this wiki page:
https://wiki.mozilla.org/User:Jorge.villalobos/AddonGuidelines

You can leave your feedback on this thread or in the comments in the
blog post. The plan is to give some time for the community to give their
input, and then we will call them official and put them up somewhere
more prominent.

I apologize for all of the delays, but there are lots of people involved
in this process and I didn't want to leave them out.

Jorge
Re: Draft: Add-on Policies V2 Jorge Villalobos 9/6/12 10:29 AM
Re: Draft: Add-on Policies V2 Blair McBride 9/6/12 8:13 PM
This is great, Jorge.


> It's worth stressing that PBM is about not storing local data while browsing, not about sending data elsewhere.

This feels awkwardly worded, I had to re-read it to get it. Maybe
replace the first "not" with "avoiding"?

- Blair
Re: Draft: Add-on Policies V2 Jorge Villalobos 9/7/12 8:01 AM
Fixed, thanks.
Re: Draft: Add-on Policies V2 Jorge Villalobos 9/7/12 8:01 AM
On 9/6/12 9:12 PM, Blair McBride wrote:
Fixed, thanks.
Re: Draft: Add-on Policies V2 Lawrence Mandel 1/3/13 8:29 AM
Taking a late look at the draft guidelines, I think we should be stronger in our stance against add-ons that impact the usability and performance of Firefox by changing a number of "should" statements to "must" statements. These guidelines should make it clear to both add-on developers and Mozilla (so that we know when we can blocklist an add-on) what behaviour is acceptable for an add-on.

"Add-ons should not store any browsing data while in Private Browsing Mode."
I think the guidelines (or some other document) should clarify the term "browsing data" and this statement should be changed to a "must". Any browsing data stored by an add-on runs the risk of violating the user expectation of this feature.

"Add-ons should not break or disable core application features."
This reads like a "must" to me. We don't want add-ons breaking the browser. It may be prudent to list the specific core application features that we will be particularly vigilant in defending.

"Add-ons should not cause memory leaks, or unnecessarily consume large amounts of memory."
I think we should add a statement about taking strong action against add-ons that are found to leak significant memory. We may also want to flag add-ons that legitimately consume significant memory so that users can make a conscious choice about their installation.

"Add-ons should not slow down the application or system significantly."
I think this is a "must" as well. The statement is already vague in its use of the term "significantly". We should not be soft on application performance.

"Add-ons should not consume network resources to an extent that affects regular application usage."
Again, this reads to me as a "must" as it has the potential to affect Firefox or other application usage.

Lawrence
More topics »