Draft: Add-on Policies

Showing 1-99 of 99 messages
Draft: Add-on Policies Jorge Villalobos 6/28/12 4:34 PM
Hello,

The Add-ons Team is working on creating a general add-on policy that
applies to both AMO and non-AMO add-ons. This will allow us to
articulate what we expect from all add-on developers, and to make
clearer what kind of behavior will not be tolerated.

We'd like to get your feedback on the current draft, included below. My
idea is to keep it short and concise, and to add a link in each section
pointing to more detailed documentation explaining what's acceptable or
unacceptable in the different areas.

** Mozilla Add-on Policies (Draft) **

* Be Transparent *

* Add-ons must not be installed without user approval.
* 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 always be possible to uninstall or disable from the
Add-ons Manager.
* Add-ons should clearly communicate their intended purpose and active
features.

* 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 information is being used.
* Add-on developers should provide a support channel for their users.

* Be Safe *

* Add-ons must not cause harm to the user's online identities, data or
system.
* Add-ons must not expose or unsafely transmit the user's private data.
* Add-ons must not create or expose application or system vulnerabilities.

* Be Fast *

* Add-ons must not cause hangs or crashes.
* Add-ons should not consume excessive amounts of memory or cause memory
leaks.
* Add-ons should not slow the application down significantly.

* Enforcement *

If an add-on breaks any of the /must/ guidelines or many of the /should/
guidelines, it qualifies for blocklisting (remote disabling).

Per blocklisting policy, 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.

Exceptions to these policies include add-ons with the intended purpose
of breaking them with non-malicious intent. For example, security
exploit proofs of concept.

Jorge
Re: Draft: Add-on Policies Nicholas Nethercote 6/28/12 5:31 PM
On Thu, Jun 28, 2012 at 4:34 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
>
> The Add-ons Team is working on creating a general add-on policy that applies
> to both AMO and non-AMO add-ons. This will allow us to articulate what we
> expect from all add-on developers, and to make clearer what kind of behavior
> will not be tolerated.

This sounds *great*!  My first question is -- how does vary from the
status quo?  Do we already have some guidelines, but these new ones
would be stronger than the existing ones?  Or do we not have official
guidelines?


> * Add-ons must not be installed without user approval.

What does that mean, exactly?  E.g. would overlaying a giant green
arrow that says "check this box!" on the confirmation page be a
violation? :)


> * Be Fast *
>
> * Add-ons must not cause hangs or crashes.
> * Add-ons should not consume excessive amounts of memory or cause memory
> leaks.
> * Add-ons should not slow the application down significantly.

There is a large grey area with these ones.  I'm not sure how to
reduce the size of that grey area, though.  I guess precedent will be
important.

Nit: hangs or crashes aren't really related to "Be Fast".


> * Enforcement *
>
> If an add-on breaks any of the /must/ guidelines or many of the /should/
> guidelines, it qualifies for blocklisting (remote disabling).

Is "many" too restrictive?  E.g. if one of the /should/ guidelines is
violated badly, that should be sufficient grounds for action.

There's no distinction between soft blocks and hard blocks in this
policy.  Should there be?

It would be nice if there was a punishment less severe than
blocklisting, such as a warning at install-time and/or in
about:addons, because that could be used more frequently than
block-listing.

Nickc
Re: Draft: Add-on Policies justin...@gmail.com 6/29/12 6:04 AM
> We'd like to get your feedback on the current draft, included below.

I think this is a really good start.  I particularly like the fact that the individual guidelines are clear and concise.

> * Add-ons must not be installed without user approval.

Does "user approval" mean "explicit user approval", or is some kind of implicit "you installed an anti-virus tool, so you approve of an AV extension" acceptable?

Does such explicit user approval need to be opt-in?  That is, must the checkbox be unchecked by default?

(I know these are detailed questions you don't intend to address in this high-level document; we can deal with the details separately, if you'd like.)

> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager.

Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a MUST except under certain conditions?

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

Yay.

> * Be fast *

I think we should add here that add-ons MUST NOT use our APIs in "unsafe" ways, i.e., ways which may cause crashes or security vulnerabilities.

For example, add-ons MUST NOT use main-thread objects off the main thread.  In cases where this happens, it's often difficult for us to prove that the add-on is causing crashes.  Using a main-thread-only object off the main thread can cause general heap corruption and crash during a random malloc or free, and we can't trace that back to a particular add-on.  So doing something unsafe, even if it's not provably crashy, should be disallowed.

> If an add-on breaks any of the /must/ guidelines or many of the /should/
> guidelines, it qualifies for blocklisting (remote disabling).

Like njn, I don't think the right criterion is "many of the SHOULD guidelines".  Instead, it should be a question of degree: How badly does it violate the guidelines?

> Per blocklisting policy, 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.

"The only exception to this" is in fact more permissive than our current policy: We will currently unilaterally blacklist an add-on which causes lots of crashes, right?

Looking through this list, it seems to me that flagrant violations of the MUST violations should result in immediate blocklisting, whereas we might tolerate some delay fixing venal violations of SHOULD criteria.  Again, this mirrors our current policy with respect to crashes, as I understand it.

We would want to institute this policy after some grace period, of course, and we'd work with anyone in violation of the MUST policies during the grace period.  But I propose that after that period, a non-venial MUST violation would be cause for immediate blocklisting.

---

Separately, I think we ought to reserve the right to stop working with a given developer.  For example, a developer might be reachable and responsive, but effectively using Mozilla as their QA lab and our users as their testers, pushing buggy changes and expecting us to debug them.

Under this proposed policy, we wouldn't be able to do anything except continue to work with this developer to improve their code, while our users continue to suffer.  At some point, we should be able to say that enough is enough.

---

This isn't a question of add-on policy per se, but has the add-ons or QA team considered how they are going to check for violations of this policy?  Are there plans to regularly test the most-popular add-ons?  What is the proposed frequency of testing, and what are the proposed criteria for determining whether an add-on warrants our attention?
Re: Draft: Add-on Policies Justin Lebar 6/29/12 6:04 AM
> We'd like to get your feedback on the current draft, included below.

I think this is a really good start.  I particularly like the fact that the individual guidelines are clear and concise.

> * Add-ons must not be installed without user approval.

Does "user approval" mean "explicit user approval", or is some kind of implicit "you installed an anti-virus tool, so you approve of an AV extension" acceptable?

Does such explicit user approval need to be opt-in?  That is, must the checkbox be unchecked by default?

(I know these are detailed questions you don't intend to address in this high-level document; we can deal with the details separately, if you'd like.)

> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager.

Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a MUST except under certain conditions?

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

Yay.

> * Be fast *

I think we should add here that add-ons MUST NOT use our APIs in "unsafe" ways, i.e., ways which may cause crashes or security vulnerabilities.

For example, add-ons MUST NOT use main-thread objects off the main thread.  In cases where this happens, it's often difficult for us to prove that the add-on is causing crashes.  Using a main-thread-only object off the main thread can cause general heap corruption and crash during a random malloc or free, and we can't trace that back to a particular add-on.  So doing something unsafe, even if it's not provably crashy, should be disallowed.

> If an add-on breaks any of the /must/ guidelines or many of the /should/
> guidelines, it qualifies for blocklisting (remote disabling).

Like njn, I don't think the right criterion is "many of the SHOULD guidelines".  Instead, it should be a question of degree: How badly does it violate the guidelines?

> Per blocklisting policy, 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.

Re: Draft: Add-on Policies David Rajchenbach-Teller 6/29/12 6:11 AM
On 6/29/12 2:31 AM, Nicholas Nethercote wrote:
>> * Be Fast *
>>
>> * Add-ons must not cause hangs or crashes.
>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>> * Add-ons should not slow the application down significantly.
>
> There is a large grey area with these ones.  I'm not sure how to
> reduce the size of that grey area, though.  I guess precedent will be
> important.
>
> Nit: hangs or crashes aren't really related to "Be Fast".

Do you think it is clear for everybody that "fast" is not just about
speed but about responsiveness?

In case of doubt, I would add something along the lines of:

* Add-ons should not make the application unresponsive for its users or
for the operating system.

> It would be nice if there was a punishment less severe than
> blocklisting, such as a warning at install-time and/or in
> about:addons, because that could be used more frequently than
> block-listing.

Good idea.

Cheers,
 David


--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



Re: Draft: Add-on Policies Majken Connor 6/29/12 6:20 AM
I like that providing support is a "should" but I think this might still be
strong enough wording to scare some authors off. I think it depends on the
complexity whether or not the author should provide support. For many
add-ons it's a perfectly acceptable alternative to uninstall the add-on and
find another. I think dropping maintenance of an add-on probably affects
users much more than lack of support.

Maybe the criteria should be to make it clear to users whether or not there
is active support for the add-on or if they will have to uninstall it if it
breaks.
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>
Re: Draft: Add-on Policies Benjamin Smedberg 6/29/12 6:48 AM
On 6/28/12 7:34 PM, Jorge Villalobos wrote:

> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager.
MUST?
> * Add-on developers should provide a support channel for their users.
I think I disagree with this policy. I certainly don't have the time or
energy to provide an official support channel for the addons that I have
published. I try to respond to emails about them, but for the most part
the answer is "sorry I don't have time to support the addon beyond what
I've already done." Is that a support channel? I think it should be ok
to state that addons are available as-is without support. Unless AMO
wants to provide per-addon support forums where users can help eachother
without my involvement...

--BDS

Re: Draft: Add-on Policies David Bruant 6/29/12 7:06 AM
Hi,

I appreciate this effort and I think it's necessary, but I don't
necessarily agree with a good share of the rules as I think it should be
enforced by the platform and not add-on developers will.

Le 29/06/2012 01:34, Jorge Villalobos a écrit :
> Hello,
>
> The Add-ons Team is working on creating a general add-on policy that
> applies to both AMO and non-AMO add-ons. This will allow us to
> articulate what we expect from all add-on developers, and to make
> clearer what kind of behavior will not be tolerated.
>
> We'd like to get your feedback on the current draft, included below.
> My idea is to keep it short and concise, and to add a link in each
> section pointing to more detailed documentation explaining what's
> acceptable or unacceptable in the different areas.
>
> ** Mozilla Add-on Policies (Draft) **
>
> * Be Transparent *
>
> * Add-ons must not be installed without user approval.
How can an Firefox add-on bypass user approval? It seems that Firefox
should be able to impose that.

> * 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 always be possible to uninstall or disable from the
> Add-ons Manager.
The Add-on platform could impose add-ons to always comply to this last part.

> * Add-ons should clearly communicate their intended purpose and active
> features.
>
> * Be Respectful to Users *
>
> * Add-ons must remove all introduced code, executables, and
> application configuration changes once they are uninstalled.
The Add-on platform could restrict add-ons to always comply to this part.

> * Add-ons should not disrespect the user's choices by making
> unexpected changes or limiting the user's ability to revert them.
To some extent, the Add-on platform can enforce that.

> * Add-ons should make it clear how private user information is being used.
To some extent, add-on APIs can enforce that as well. The
geolocalisation is in part a good example of how an API can be designed
to share the program intent to the user and ask for explicit consent.
The ability to provide a custom message would be nice.

> * Add-on developers should provide a support channel for their users.
Are you planning to blocklist add-ons based on this part?
I think this should be dealt by natural competition that is to say that
if an add-on doesn't provide enough support, someone else will just
create the same add-on with the support and the former will die out. But
that shouldn't be AMO's role to impose that. Even less for non-AMO add-ons.

> * Be Safe *
>
> * Add-ons must not cause harm to the user's online identities, data or
> system.
> * Add-ons must not expose or unsafely transmit the user's private data.
> * Add-ons must not create or expose application or system
> vulnerabilities.
For the 3 of them, again, the API could enforce that either totally or
partially depending on the exact definition of the different parts.

> * Be Fast *
The same add-on used on mobile or desktop will have different
characteristics here. Can an add-on be blocked on a per-platform basis?

> * Add-ons must not cause hangs or crashes.
> * Add-ons should not consume excessive amounts of memory or cause
> memory leaks.
> * Add-ons should not slow the application down significantly.
Firefox can largely

> * Enforcement *
>
> If an add-on breaks any of the /must/ guidelines or many of the
> /should/ guidelines, it qualifies for blocklisting (remote disabling).
Can you do remote disabling of non-AMO add-ons? This sounds scary.

> Per blocklisting policy, 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.
Does it all apply only to *the* Firefox officially shipped by Mozilla or
forks as well?
It would be nice to list all products to which this applies. Fennec?
Thunderbird? B2G apps on B2G? Firefox for Android?


The object capability discipline is one that encouraging applying POLA
(Principle Of Least Authority) to object-oriented programming. The basic
POLA principle is the following: don't give authority to people when
they don't need it.
Since you're in control of the platform the add-ons run on, it's up to
you to not give abusive authority. Specifically for:
* Add-ons should always be possible to uninstall or disable from the
Add-ons Manager
* Add-ons must remove all introduced code, executables, and application
configuration changes once they are uninstalled.
There should be no need to ask for add-on developers to do that. You're
in control of the platform, just create an API that enforces these
points. At the end of the day, you will reduce the developer choices
from "comply, don't comply or don't write the add-on" to "comply or
don't write the add-on".
Where would be a good place to have discussions about Add-on API design
that enforce rules?


I'd like to point out that we know the dictatorian Apple App review
model, we have seen Chrome moving to a model where it's much more
difficult for users to install non-Chrome Store apps/extensions [1].
The ability to remote-disable an add-on in itself is pretty much as
scary. I think it's the first time I read something from Mozilla saying
"we keep some control over what you can or cannot use after the install"
The add-on policy is a first step towards transparency from Mozilla to
make explicit what the rules are to be a "good add-on". I think it would
be a good idea to continue in that direction and communicate clearly
Mozilla's intention with this add-on policy.

David

[1]
http://techie-buzz.com/browsers/chrome-blocking-extension-apps-scripts-chrome-web-store.html
Re: Draft: Add-on Policies Asa Dotzler 6/29/12 8:31 AM
On 6/29/2012 6:20 AM, Majken Connor wrote:
> I like that providing support is a "should" but I think this might still be
> strong enough wording to scare some authors off. I think it depends on the
> complexity whether or not the author should provide support. For many
> add-ons it's a perfectly acceptable alternative to uninstall the add-on and
> find another. I think dropping maintenance of an add-on probably affects
> users much more than lack of support.
>
> Maybe the criteria should be to make it clear to users whether or not there
> is active support for the add-on or if they will have to uninstall it if it
> breaks.

I disaggree. Not violently, though.

Being allowed into Firefox is a privilege, not a right. Our mission says
we keep the Web open. We keep Firefox open to extending (and breaking)
by third parties at our digression and saying that we believe those
parties should support their users is, IMO, totally legitimate. If
getting the message out that we don't want them abandoning users costs
us a few future extensions, I think it's still well worth it.

- A
Re: Draft: Add-on Policies Asa Dotzler 6/29/12 8:33 AM
That's why it's a "should" and not a "must". Not everyone has the
ability or the willingness to do it. That's fine. That doesn't mean we
shouldn't encourage it by calling it out as a "should".

- A
Re: Draft: Add-on Policies Boris Zbarsky 6/29/12 8:50 AM
On 6/29/12 10:06 AM, David Bruant wrote:
> How can an Firefox add-on bypass user approval? It seems that Firefox
> should be able to impose that.

Keep in mind that this all applies to non-AMO add-ons too.  An add-on
installed by executable code running on the user's computer (e.g. the
various antivirus addons) can just modify the Firefox files in-place to
make the add-on look installed.  We want to make it clear that this is
not OK and will be cause for the add-on being blocked.

In fact, in the above situation the add-on could even bypass the blocks
we use to disable misbehaving addons, but at that point it would have
clearly crossed into the "malware" category in the court of public
opinion....

>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
> The Add-on platform could impose add-ons to always comply to this last
> part.

No, see above.

>> * Add-ons must remove all introduced code, executables, and
>> application configuration changes once they are uninstalled.
> The Add-on platform could restrict add-ons to always comply to this part.

No, see above.

>> * Add-ons should not disrespect the user's choices by making
>> unexpected changes or limiting the user's ability to revert them.
> To some extent, the Add-on platform can enforce that.

No, see above.  Note that a number of add-ons come with binary blobs
that basically load into the Firefox address space, so they're not using
"the Add-on platform".

> To some extent, add-on APIs can enforce that as well.

You're assuming add-ons stick to "add-on APIs".  The most troublesome
ones do not.

>> If an add-on breaks any of the /must/ guidelines or many of the
>> /should/ guidelines, it qualifies for blocklisting (remote disabling).
> Can you do remote disabling of non-AMO add-ons?

Yes, if they're playing nice and registering as add-ons (which makes it
_our_ job to load their code, which we can then just refuse to do) as
opposed to just jamming themselves into the process address space at
runtime.  Note that we could do this even without the blocklist
infrastructure by just issuing Firefox updates; all the blocklist buys
us is the ability to not have to update Firefox as a whole to block an
add-on.

> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager
> * Add-ons must remove all introduced code, executables, and application
> configuration changes once they are uninstalled.
> There should be no need to ask for add-on developers to do that. You're
> in control of the platform, just create an API that enforces these
> points.

The point is that we want to make it clear to add-on developers that
they have to use said API if they don't want to be blacklisted.

-Boris
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:34 AM
On 6/29/12 7:04 AM, justin...@gmail.com wrote:
>> We'd like to get your feedback on the current draft, included below.
>
> I think this is a really good start.  I particularly like the fact that the individual guidelines are clear and concise.
>
>> * Add-ons must not be installed without user approval.
>
> Does "user approval" mean "explicit user approval", or is some kind of implicit "you installed an anti-virus tool, so you approve of an AV extension" acceptable?
>
> Does such explicit user approval need to be opt-in?  That is, must the checkbox be unchecked by default?
>
> (I know these are detailed questions you don't intend to address in this high-level document; we can deal with the details separately, if you'd like.)


I this case, it would mean "if you're installing your add-on externally,
you should go through the third-party install dialog, otherwise use the
regular add-on installation system". Things aren't quite as simple, of
course, but we want to keep the policies as simple as possible.


>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
>
> Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a MUST except under certain conditions?


If you install an extension externally, in the way we recommend (through
the registry), there's no way to uninstall it. You can only disable it.
This policy was initially written as a MUST, but it'll have to wait for
the Add-ons Manager to support uninstalling these sorts of add-on.


>> * Be fast *
>
> I think we should add here that add-ons MUST NOT use our APIs in "unsafe" ways, i.e., ways which may cause crashes or security vulnerabilities.
>
> For example, add-ons MUST NOT use main-thread objects off the main thread.  In cases where this happens, it's often difficult for us to prove that the add-on is causing crashes.  Using a main-thread-only object off the main thread can cause general heap corruption and crash during a random malloc or free, and we can't trace that back to a particular add-on.  So doing something unsafe, even if it's not provably crashy, should be disallowed.
>

The policies are focused on the consequences of the developer's actions,
and not the specific coding practices that lead to these issues. There
are policies covering security and stability, and the additional docs
would explain what kinds of bad practices can lead to the problems the
policies cover. So, I feel that this addition would be too low-level and
redundant.


>> If an add-on breaks any of the /must/ guidelines or many of the /should/
>> guidelines, it qualifies for blocklisting (remote disabling).
>
> Like njn, I don't think the right criterion is "many of the SHOULD guidelines".  Instead, it should be a question of degree: How badly does it violate the guidelines?

Do you think the must/should distinction is unnecessary then? Or is this
something that should only be changed for the SHOULD guidelines?

>
>> Per blocklisting policy, 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.
>
> "The only exception to this" is in fact more permissive than our current policy: We will currently unilaterally blacklist an add-on which causes lots of crashes, right?

No, we always try to contact the developers first. We've never had a
crash rate serious enough that can't wait for a couple of days before
blocklisting.

>
> Looking through this list, it seems to me that flagrant violations of the MUST violations should result in immediate blocklisting, whereas we might tolerate some delay fixing venal violations of SHOULD criteria.  Again, this mirrors our current policy with respect to crashes, as I understand it.
>
> We would want to institute this policy after some grace period, of course, and we'd work with anyone in violation of the MUST policies during the grace period.  But I propose that after that period, a non-venial MUST violation would be cause for immediate blocklisting.
>

That doesn't match our current policies and I don't think we should take
them in that direction. Being cooperative has always been the best way
to get results from developers in my experience.

>
> Separately, I think we ought to reserve the right to stop working with a given developer.  For example, a developer might be reachable and responsive, but effectively using Mozilla as their QA lab and our users as their testers, pushing buggy changes and expecting us to debug them.
>
> Under this proposed policy, we wouldn't be able to do anything except continue to work with this developer to improve their code, while our users continue to suffer.  At some point, we should be able to say that enough is enough.
>

That's the "reasonable timeframe" bit. We wouldn't just wait
indefinitely for a fix. At some point, if blocklisting is the only way
to get things fixed and the developer is being too slow, we'll do it.
This is the way it works now.


>
> This isn't a question of add-on policy per se, but has the add-ons or QA team considered how they are going to check for violations of this policy?  Are there plans to regularly test the most-popular add-ons?  What is the proposed frequency of testing, and what are the proposed criteria for determining whether an add-on warrants our attention?

We have discussed ways to increase our reach and knowledge of non-AMO
add-ons, but I think that is off-topic for this discussion. We also
think that these policies are valuable on their own, even with only the
feedback systems we currently have.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:39 AM
Providing a support channel for users is something any responsible
developer should do, but I can see how casual developers would see that
as a time sink. Note that we're asking for this but we don't set any
expectations on how responsive the developer must be, so this is really
up to them to decide. It should also be noted that these support
channels are often the only way we can get in touch with developers in
the case of an emergency, like a security bug or a top crash.

What we're trying to articulate with this policy is that there should be
*some* way for users and Mozilla to get in touch with the developer.

Jorge
Re: Draft: Add-on Policies David Ascher 6/29/12 9:40 AM
My (biased) perspective is that if we require all addons uniformly to have the qualities of a finished product (no perf issues, no bugs, etc.), then we make it very hard for anything new to come up and get usage, which is required for feedback, which is required for detecting issues and fixing them.

So, while I think the policy as stated is great for what I'd call "production add-ons", I think we should be clear about the need to allow for addons that "aren't there yet", make sure that users who install those addons are appropriately informed that the software isn't finished, etc.

--david

Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:50 AM
On 6/28/12 6:31 PM, Nicholas Nethercote wrote:
> On Thu, Jun 28, 2012 at 4:34 PM, Jorge Villalobos<jo...@mozilla.com>  wrote:
>>
>> The Add-ons Team is working on creating a general add-on policy that applies
>> to both AMO and non-AMO add-ons. This will allow us to articulate what we
>> expect from all add-on developers, and to make clearer what kind of behavior
>> will not be tolerated.
>
> This sounds *great*!  My first question is -- how does vary from the
> status quo?  Do we already have some guidelines, but these new ones
> would be stronger than the existing ones?  Or do we not have official
> guidelines?

We have AMO guidelines and unwritten general add-on guidelines. This
aims to create a public, baseline add-on policy that applies to all.

>
>
>> * Add-ons must not be installed without user approval.
>
> What does that mean, exactly?  E.g. would overlaying a giant green
> arrow that says "check this box!" on the confirmation page be a
> violation? :)

See my reply to Justin.

>
>
>> * Be Fast *
>>
>> * Add-ons must not cause hangs or crashes.
>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>> * Add-ons should not slow the application down significantly.
>
> There is a large grey area with these ones.  I'm not sure how to
> reduce the size of that grey area, though.  I guess precedent will be
> important.
>
> Nit: hangs or crashes aren't really related to "Be Fast".

We're not aiming for precision but general principles. The idea is that
we would link to more detailed technical guidelines that explain the
"how" and maybe quantify some of these policies.

>
> There's no distinction between soft blocks and hard blocks in this
> policy.  Should there be?
>

Hard blocks are normally reserved for malicious add-ons. We generally
want users to be able to revert a block at their own risk. So, I think
the soft/hard block choice is unrelated to the policies.

> It would be nice if there was a punishment less severe than
> blocklisting, such as a warning at install-time and/or in
> about:addons, because that could be used more frequently than
> block-listing.

Yes, this is something we discussed in the work week and there are some
plans we'll be working on to have some intermediate actions in our toolbox.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:53 AM
On 6/29/12 7:48 AM, Benjamin Smedberg wrote:
> On 6/28/12 7:34 PM, Jorge Villalobos wrote:
>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
> MUST?

When the AOM supports uninstalling add-ons that are installed through
the registry, sure :)
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:34 AM
On 6/29/12 7:04 AM, justin...@gmail.com wrote:
>> We'd like to get your feedback on the current draft, included below.
>
> I think this is a really good start.  I particularly like the fact that the individual guidelines are clear and concise.
>
>> * Add-ons must not be installed without user approval.
>
> Does "user approval" mean "explicit user approval", or is some kind of implicit "you installed an anti-virus tool, so you approve of an AV extension" acceptable?
>
> Does such explicit user approval need to be opt-in?  That is, must the checkbox be unchecked by default?
>
> (I know these are detailed questions you don't intend to address in this high-level document; we can deal with the details separately, if you'd like.)


I this case, it would mean "if you're installing your add-on externally,
you should go through the third-party install dialog, otherwise use the
regular add-on installation system". Things aren't quite as simple, of
course, but we want to keep the policies as simple as possible.


>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
>
> Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a MUST except under certain conditions?


If you install an extension externally, in the way we recommend (through
the registry), there's no way to uninstall it. You can only disable it.
This policy was initially written as a MUST, but it'll have to wait for
the Add-ons Manager to support uninstalling these sorts of add-on.


>> * Be fast *
>
> I think we should add here that add-ons MUST NOT use our APIs in "unsafe" ways, i.e., ways which may cause crashes or security vulnerabilities.
>
> For example, add-ons MUST NOT use main-thread objects off the main thread.  In cases where this happens, it's often difficult for us to prove that the add-on is causing crashes.  Using a main-thread-only object off the main thread can cause general heap corruption and crash during a random malloc or free, and we can't trace that back to a particular add-on.  So doing something unsafe, even if it's not provably crashy, should be disallowed.
>

The policies are focused on the consequences of the developer's actions,
and not the specific coding practices that lead to these issues. There
are policies covering security and stability, and the additional docs
would explain what kinds of bad practices can lead to the problems the
policies cover. So, I feel that this addition would be too low-level and
redundant.


>> If an add-on breaks any of the /must/ guidelines or many of the /should/
>> guidelines, it qualifies for blocklisting (remote disabling).
>
> Like njn, I don't think the right criterion is "many of the SHOULD guidelines".  Instead, it should be a question of degree: How badly does it violate the guidelines?

Do you think the must/should distinction is unnecessary then? Or is this
something that should only be changed for the SHOULD guidelines?

>
>> Per blocklisting policy, 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.
>
> "The only exception to this" is in fact more permissive than our current policy: We will currently unilaterally blacklist an add-on which causes lots of crashes, right?

No, we always try to contact the developers first. We've never had a
crash rate serious enough that can't wait for a couple of days before
blocklisting.

>
> Looking through this list, it seems to me that flagrant violations of the MUST violations should result in immediate blocklisting, whereas we might tolerate some delay fixing venal violations of SHOULD criteria.  Again, this mirrors our current policy with respect to crashes, as I understand it.
>
> We would want to institute this policy after some grace period, of course, and we'd work with anyone in violation of the MUST policies during the grace period.  But I propose that after that period, a non-venial MUST violation would be cause for immediate blocklisting.
>

That doesn't match our current policies and I don't think we should take
them in that direction. Being cooperative has always been the best way
to get results from developers in my experience.

>
> Separately, I think we ought to reserve the right to stop working with a given developer.  For example, a developer might be reachable and responsive, but effectively using Mozilla as their QA lab and our users as their testers, pushing buggy changes and expecting us to debug them.
>
> Under this proposed policy, we wouldn't be able to do anything except continue to work with this developer to improve their code, while our users continue to suffer.  At some point, we should be able to say that enough is enough.
>

That's the "reasonable timeframe" bit. We wouldn't just wait
indefinitely for a fix. At some point, if blocklisting is the only way
to get things fixed and the developer is being too slow, we'll do it.
This is the way it works now.


>
> This isn't a question of add-on policy per se, but has the add-ons or QA team considered how they are going to check for violations of this policy?  Are there plans to regularly test the most-popular add-ons?  What is the proposed frequency of testing, and what are the proposed criteria for determining whether an add-on warrants our attention?

Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:50 AM
On 6/28/12 6:31 PM, Nicholas Nethercote wrote:
> On Thu, Jun 28, 2012 at 4:34 PM, Jorge Villalobos<jo...@mozilla.com>  wrote:
>>
>> The Add-ons Team is working on creating a general add-on policy that applies
>> to both AMO and non-AMO add-ons. This will allow us to articulate what we
>> expect from all add-on developers, and to make clearer what kind of behavior
>> will not be tolerated.
>
> This sounds *great*!  My first question is -- how does vary from the
> status quo?  Do we already have some guidelines, but these new ones
> would be stronger than the existing ones?  Or do we not have official
> guidelines?

We have AMO guidelines and unwritten general add-on guidelines. This
aims to create a public, baseline add-on policy that applies to all.

>
>
>> * Add-ons must not be installed without user approval.
>
> What does that mean, exactly?  E.g. would overlaying a giant green
> arrow that says "check this box!" on the confirmation page be a
> violation? :)

See my reply to Justin.

>
>
>> * Be Fast *
>>
>> * Add-ons must not cause hangs or crashes.
>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>> * Add-ons should not slow the application down significantly.
>
> There is a large grey area with these ones.  I'm not sure how to
> reduce the size of that grey area, though.  I guess precedent will be
> important.
>
> Nit: hangs or crashes aren't really related to "Be Fast".

We're not aiming for precision but general principles. The idea is that
we would link to more detailed technical guidelines that explain the
"how" and maybe quantify some of these policies.

>
> There's no distinction between soft blocks and hard blocks in this
> policy.  Should there be?
>

Hard blocks are normally reserved for malicious add-ons. We generally
want users to be able to revert a block at their own risk. So, I think
the soft/hard block choice is unrelated to the policies.

> It would be nice if there was a punishment less severe than
> blocklisting, such as a warning at install-time and/or in
> about:addons, because that could be used more frequently than
> block-listing.

Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:39 AM
Providing a support channel for users is something any responsible
developer should do, but I can see how casual developers would see that
as a time sink. Note that we're asking for this but we don't set any
expectations on how responsive the developer must be, so this is really
up to them to decide. It should also be noted that these support
channels are often the only way we can get in touch with developers in
the case of an emergency, like a security bug or a top crash.

What we're trying to articulate with this policy is that there should be
*some* way for users and Mozilla to get in touch with the developer.

Jorge

On 6/29/12 7:20 AM, Majken Connor wrote:
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 9:53 AM
On 6/29/12 7:48 AM, Benjamin Smedberg wrote:
> On 6/28/12 7:34 PM, Jorge Villalobos wrote:
>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
> MUST?

Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 10:10 AM
Which is these policies do you think only apply to production add-ons?

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 10:10 AM
On 6/29/12 10:40 AM, David Ascher wrote:
Re: Draft: Add-on Policies David Ascher 6/29/12 10:34 AM

> Which is these policies do you think only apply to production add-ons?
>
>
>



I think the performance requirement is likely the one most likely to surface stop energy. I'll re-read the policies and check, it's a good question!

--da

Re: Draft: Add-on Policies David Bruant 6/29/12 10:56 AM
Le 29/06/2012 17:50, Boris Zbarsky a écrit :
> On 6/29/12 10:06 AM, David Bruant wrote:
>> How can an Firefox add-on bypass user approval? It seems that Firefox
>> should be able to impose that.
>
> Keep in mind that this all applies to non-AMO add-ons too.  An add-on
> installed by executable code running on the user's computer (e.g. the
> various antivirus addons) can just modify the Firefox files in-place
> to make the add-on look installed.  We want to make it clear that this
> is not OK and will be cause for the add-on being blocked.
It's possible to keep a list of add-ons and their state
(enabled/disabled) as it was during last Firefox close. If a new add-on
has been installed before the next startup, you can detect it by
comparing the list and the current state. If new addons are detected,
you can ask for the user confirmation.

> In fact, in the above situation the add-on could even bypass the
> blocks we use to disable misbehaving addons, but at that point it
> would have clearly crossed into the "malware" category in the court of
> public opinion....
True. And if an add-on adds itself to the suggested list, it's a malware
as well.

Based on that statement, I'll make the assumption for now on that either
an add-on running on Firefox has been installed with user consent or
it's a malware.

I think that I should rephrase all what I said above and change "the
add-on platform can enforce that" to "the add-on platform can enforce
that or prove that the add-on is a malware". Both solutions are great
news in my opinion.

Also, if a malware infects a computer and can modify Firefox files, then
Firefox is compromised and nothing is reliable, so it's not even worth
talking about it because it's beyond Firefox responsibility and reach.

Some of my replies below assume the add-on is not made of binary, but
with pure JS. I'll address binary at the point you mention it.

>>> * Add-ons should always be possible to uninstall or disable from the
>>> Add-ons Manager.
>> The Add-on platform could impose add-ons to always comply to this last
>> part.
> No, see above.
I guess it's the same thing here. Firefox can record the user intent. If
an add-on re-enables itself without user consent, it's equally a
malware, so Firefox can impose either impose this constraint or prove
it's a malware.

>>> * Add-ons must remove all introduced code, executables, and
>>> application configuration changes once they are uninstalled.
>> The Add-on platform could restrict add-ons to always comply to this
>> part.
> No, see above.
If an add-on is not proven to be a malware, then the user did consent to
its execution. If so, then Firefox can run the add-on within the
boundaries it decides. Specifically, it can record what the add-on
changes for configurations and likely which files were generated by the
add-on, etc. and reverse things that are reversible when the user asks
for "uninstall".
It may not be the case today, but it's technically possible (harder with
binary, but I'm coming to that). So in theory, Firefox could remove
everything when the user asks.

>
>>> * Add-ons should not disrespect the user's choices by making
>>> unexpected changes or limiting the user's ability to revert them.
>> To some extent, the Add-on platform can enforce that.
>
> No, see above.  Note that a number of add-ons come with binary blobs
> that basically load into the Firefox address space, so they're not
> using "the Add-on platform".
That's true. My answer to that is that Firefox can detect whether the
add-on has a binary part or not and declare an add-on "fully safe" or
"partially safe" (the terminology isn't perfect, sorry). Indeed, an
add-on with a binary part is potentially dangerous. Users should be
informed of that.



>> To some extent, add-on APIs can enforce that as well.
>
> You're assuming add-ons stick to "add-on APIs".  The most troublesome
> ones do not.
Firefox can detect (probably even statically) whether the add-ons does
stick to "add-on APIs" or not, it can tell the user.

>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager
>> * Add-ons must remove all introduced code, executables, and application
>> configuration changes once they are uninstalled.
>> There should be no need to ask for add-on developers to do that. You're
>> in control of the platform, just create an API that enforces these
>> points.
>
> The point is that we want to make it clear to add-on developers that
> they have to use said API if they don't want to be blacklisted.
It seems that add-on performance and security is becoming an increasing
concern and imposing an API (which you need to do anyway when creating a
platform) seems to be a nice way to limit add-on developers to only do
harmless add-ons

David
Re: Draft: Add-on Policies Boris Zbarsky 6/29/12 11:33 AM
On 6/29/12 1:56 PM, David Bruant wrote:
> If new addons are detected,
> you can ask for the user confirmation.

Yes, that's similar to what we do now.  The point of the policy is that
addons are not supposed to subvert this mechanism (e.g. by automatically
adding themselves to the stored list as it was during last Firefox close)!

> True. And if an add-on adds itself to the suggested list, it's a malware
> as well.

Addons have done that in the past.  The point of the policy it to make
that explicitly not ok.

> Also, if a malware infects a computer and can modify Firefox files, then
> Firefox is compromised and nothing is reliable, so it's not even worth
> talking about it because it's beyond Firefox responsibility and reach.

Sure.  Do you consider antivirus software to be "malware" by your
definition?  ;)

> It may not be the case today, but it's technically possible (harder with
> binary, but I'm coming to that). So in theory, Firefox could remove
> everything when the user asks.

Well, sure.  I think the policy as written is meant to apply today, this
minute.  Clearly as platform capabilities change the policy can change
accordingly.

> Firefox can detect (probably even statically) whether the add-ons does
> stick to "add-on APIs" or not

You can't do it statically, even for JS, given that JS has eval.

> it can tell the user.

Who doesn't really care what APIs the add-on is using....

>> The point is that we want to make it clear to add-on developers that
>> they have to use said API if they don't want to be blacklisted.
> It seems that add-on performance and security is becoming an increasing
> concern and imposing an API (which you need to do anyway when creating a
> platform) seems to be a nice way to limit add-on developers to only do
> harmless add-ons

Sure.  We should provide better APIs as needed.  No one is arguing
against that.

-Boris
Re: Draft: Add-on Policies Gijs Kruitbosch 6/29/12 12:50 PM
Can't we just outright require (ie 'MUST') support as well as performance etc.
for add-ons that monetize or are part of monetized platforms (*cough*
Skype/antivirus *cough*)? That seems like a good trade-off in terms of not
requiring it for 'casual' devs, and adding roadblocks to greyware (not directly,
but by giving us a good reason to blocklist / kick them off AMO if they don't
place nice). Or would that be considered too unfair discrimination?

Cheers,
Gijs

On 29/06/2012 18:39 PM, Jorge Villalobos wrote:
> Providing a support channel for users is something any responsible developer
> should do, but I can see how casual developers would see that as a time sink.
> Note that we're asking for this but we don't set any expectations on how
> responsive the developer must be, so this is really up to them to decide. It
> should also be noted that these support channels are often the only way we can
> get in touch with developers in the case of an emergency, like a security bug or
> a top crash.
>
> What we're trying to articulate with this policy is that there should be *some*
> way for users and Mozilla to get in touch with the developer.
>
> Jorge
>
> On 6/29/12 7:20 AM, Majken Connor wrote:
>> I like that providing support is a "should" but I think this might still be
>> strong enough wording to scare some authors off. I think it depends on the
>> complexity whether or not the author should provide support. For many
>> add-ons it's a perfectly acceptable alternative to uninstall the add-on and
>> find another. I think dropping maintenance of an add-on probably affects
>> users much more than lack of support.
>>
>> Maybe the criteria should be to make it clear to users whether or not there
>> is active support for the add-on or if they will have to uninstall it if it
>> breaks.
>>
>> On Fri, Jun 29, 2012 at 3:04 PM,<justin...@gmail.com>  wrote:
>>
>>>> We'd like to get your feedback on the current draft, included below.
>>>
>>> I think this is a really good start.  I particularly like the fact that
>>> the individual guidelines are clear and concise.
>>>
>>>> * Add-ons must not be installed without user approval.
>>>
>>> Does "user approval" mean "explicit user approval", or is some kind of
>>> implicit "you installed an anti-virus tool, so you approve of an AV
>>> extension" acceptable?
>>>
>>> Does such explicit user approval need to be opt-in?  That is, must the
>>> checkbox be unchecked by default?
>>>
>>> (I know these are detailed questions you don't intend to address in this
>>> high-level document; we can deal with the details separately, if you'd
>>> like.)
>>>
>>>> * Add-ons should always be possible to uninstall or disable from the
>>>> Add-ons Manager.
>>>
>>> Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a
>>> MUST except under certain conditions?
>>>
>>>> * Add-ons must remove all introduced code, executables, and application
>>>> configuration changes once they are uninstalled.
>>>
>>> Yay.
>>>
>>>> * Be fast *
>>>
>>> I think we should add here that add-ons MUST NOT use our APIs in "unsafe"
>>> ways, i.e., ways which may cause crashes or security vulnerabilities.
>>>
>>> For example, add-ons MUST NOT use main-thread objects off the main thread.
>>>   In cases where this happens, it's often difficult for us to prove that the
>>> add-on is causing crashes.  Using a main-thread-only object off the main
>>> thread can cause general heap corruption and crash during a random malloc
>>> or free, and we can't trace that back to a particular add-on.  So doing
>>> something unsafe, even if it's not provably crashy, should be disallowed.
>>>
>>>> If an add-on breaks any of the /must/ guidelines or many of the /should/
>>>> guidelines, it qualifies for blocklisting (remote disabling).
>>>
>>> Like njn, I don't think the right criterion is "many of the SHOULD
>>> guidelines".  Instead, it should be a question of degree: How badly does it
>>> violate the guidelines?
>>>
>>>> Per blocklisting policy, 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.
>>>
>>> "The only exception to this" is in fact more permissive than our current
>>> policy: We will currently unilaterally blacklist an add-on which causes
>>> lots of crashes, right?
>>>
>>> Looking through this list, it seems to me that flagrant violations of the
>>> MUST violations should result in immediate blocklisting, whereas we might
>>> tolerate some delay fixing venal violations of SHOULD criteria.  Again,
>>> this mirrors our current policy with respect to crashes, as I understand it.
>>>
>>> We would want to institute this policy after some grace period, of course,
>>> and we'd work with anyone in violation of the MUST policies during the
>>> grace period.  But I propose that after that period, a non-venial MUST
>>> violation would be cause for immediate blocklisting.
>>>
>>> ---
>>>
>>> Separately, I think we ought to reserve the right to stop working with a
>>> given developer.  For example, a developer might be reachable and
>>> responsive, but effectively using Mozilla as their QA lab and our users as
>>> their testers, pushing buggy changes and expecting us to debug them.
>>>
>>> Under this proposed policy, we wouldn't be able to do anything except
>>> continue to work with this developer to improve their code, while our users
>>> continue to suffer.  At some point, we should be able to say that enough is
>>> enough.
>>>
>>> ---
>>>
>>> This isn't a question of add-on policy per se, but has the add-ons or QA
>>> team considered how they are going to check for violations of this policy?
>>>   Are there plans to regularly test the most-popular add-ons?  What is the
>>> proposed frequency of testing, and what are the proposed criteria for
>>> determining whether an add-on warrants our attention?
>>> _______________________________________________
>>> governance mailing list
>>> gover...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/governance
>>>
>


Re: Draft: Add-on Policies David Bruant 6/29/12 3:21 PM
Le 29/06/2012 20:33, Boris Zbarsky a écrit :
> On 6/29/12 1:56 PM, David Bruant wrote:
>> If new addons are detected,
>> you can ask for the user confirmation.
>
> Yes, that's similar to what we do now.  The point of the policy is
> that addons are not supposed to subvert this mechanism (e.g. by
> automatically adding themselves to the stored list as it was during
> last Firefox close)!
The policy should make that explicit in my opinion.

>> True. And if an add-on adds itself to the suggested list, it's a malware
>> as well.
>
> Addons have done that in the past.  The point of the policy it to make
> that explicitly not ok.
>
>> Also, if a malware infects a computer and can modify Firefox files, then
>> Firefox is compromised and nothing is reliable, so it's not even worth
>> talking about it because it's beyond Firefox responsibility and reach.
>
> Sure.  Do you consider antivirus software to be "malware" by your
> definition?  ;)
Antivirus-related addons could decide to go with the normal way and not
impose themselves in the user browsers

>> It may not be the case today, but it's technically possible (harder with
>> binary, but I'm coming to that). So in theory, Firefox could remove
>> everything when the user asks.
>
> Well, sure.  I think the policy as written is meant to apply today,
> this minute.  Clearly as platform capabilities change the policy can
> change accordingly.
>
>> Firefox can detect (probably even statically) whether the add-ons does
>> stick to "add-on APIs" or not
>
> You can't do it statically, even for JS, given that JS has eval.
By limiting the APIs available to add-on JavaScript, you can ensure some
properties.
You also don't necessarily need to stick to ES5 and provide a useful yet
secure subset such as SES.
http://code.google.com/p/es-lab/wiki/SecureEcmaScript
I'm convince the vast majority of add-ons wouldn't break by these rules.
The rest of the static analysis is more or less figuring out whether
there are binary parts.


>> it can tell the user.
> Who doesn't really care what APIs the add-on is using....
Not directly, but the user cares about Mozilla's opinion on an add-on I
would assume. If Mozilla puts a "secure" stamp on an add-on is likely to
perceived differently than a "maybe secure" stamp.


>
>>> The point is that we want to make it clear to add-on developers that
>>> they have to use said API if they don't want to be blacklisted.
>> It seems that add-on performance and security is becoming an increasing
>> concern and imposing an API (which you need to do anyway when creating a
>> platform) seems to be a nice way to limit add-on developers to only do
>> harmless add-ons
>
> Sure.  We should provide better APIs as needed.  No one is arguing
> against that.
Where is the best place to have a discussion to move this topic of
add-on APIs forward?

Thanks,

David
Re: Draft: Add-on Policies Boris Zbarsky 6/29/12 3:27 PM
On 6/29/12 6:21 PM, David Bruant wrote:
> The policy should make that explicit in my opinion.

I would be fine with that.

>> Sure.  Do you consider antivirus software to be "malware" by your
>> definition?  ;)
> Antivirus-related addons could decide to go with the normal way and not
> impose themselves in the user browsers

That doesn't answer my question, unfortunately...

(For the record, I _do_ consider the antivirus addons to be "malware" by
most reasonable definitions.)

>> You can't do it statically, even for JS, given that JS has eval.
> By limiting the APIs available to add-on JavaScript, you can ensure some
> properties.

Yes, that's true, but only at the cost of severely curtailing what
add-ons can do.  Which is fine, but I don't think we want to require
that add-ons live in a sandbox to be installable.  If we _do_ want to
require them, then of course enforcing that the add-ons play nice gets
much simpler.

> You also don't necessarily need to stick to ES5 and provide a useful yet
> secure subset such as SES.
> http://code.google.com/p/es-lab/wiki/SecureEcmaScript
> I'm convince the vast majority of add-ons wouldn't break by these rules.

I'm convinced they would, but I would love any evidence for or against.  ;)

> Where is the best place to have a discussion to move this topic of
> add-on APIs forward?

..platform.

-Boris
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 4:57 PM
On 6/29/12 4:21 PM, David Bruant wrote:
> Le 29/06/2012 20:33, Boris Zbarsky a écrit :
>> On 6/29/12 1:56 PM, David Bruant wrote:
>>> If new addons are detected,
>>> you can ask for the user confirmation.
>>
>> Yes, that's similar to what we do now.  The point of the policy is
>> that addons are not supposed to subvert this mechanism (e.g. by
>> automatically adding themselves to the stored list as it was during
>> last Firefox close)!
> The policy should make that explicit in my opinion.

The policy is already explicit about requiring using consent. How this
consent occurs is not part of the policy and can change depending on
circumstances. I want to have a policy that is concise and future-proof,
and I don't think this would add value to it.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 6/29/12 4:57 PM
On 6/29/12 4:21 PM, David Bruant wrote:
> Le 29/06/2012 20:33, Boris Zbarsky a écrit :
>> On 6/29/12 1:56 PM, David Bruant wrote:
>>> If new addons are detected,
>>> you can ask for the user confirmation.
>>
>> Yes, that's similar to what we do now.  The point of the policy is
>> that addons are not supposed to subvert this mechanism (e.g. by
>> automatically adding themselves to the stored list as it was during
>> last Firefox close)!
> The policy should make that explicit in my opinion.

Re: Draft: Add-on Policies Blair McBride 6/29/12 6:16 PM
I wonder if we want to include something about:
* A user's freedom to use the web (ie, not filter parts of the web)
* Disallowing addons that convey hate messages
* Addon updates that significantly change what an addon does


On 29/06/2012 11:34 a.m., Jorge Villalobos wrote:
> * Add-ons must use a single unique id
> [https://developer.mozilla.org/en/install_manifests#id] during their
> entire lifetime.

The trouble is that this is a supported and advertised feature. We added
support for changing an addon's ID via their update manifest in Fx4 (in
fact, support for that was explicitly requested by Fligtar - see bug
412819). It's mentioned in the docs here:
https://developer.mozilla.org/index.php?title=en/Extension_Versioning%2C_Update_and_Compatibility#Automatic_Add-on_Update_Checking

I'm not sure if AMO supports it or not (I thought it did, but see bug
765717).


> * Add-on developers should provide a support channel for their users.

Do you consider anything AMO currently has as being an acceptable
support channel? I'm leaning towards "no", but I think it should.


> * Add-ons must not cause harm to the user's online identities, data or system.

What about offline implications?


> * Add-ons must not cause hangs or crashes.

What about bugs? If its a blanket ban on any possibility of a
crash/hang, Firefox itself wouldn't pass the test.


> * Add-ons should not consume excessive amounts of memory or cause memory
> leaks.

I'd modify that to something like "should not unnecessarily consume
excessive amounts of memory". For some things, you just need to use
bucket loads of memory - more than the user would expect ("How hard can
a self-aware AI be to code? It shouldn't need to use THAT much memory!").

- Blair
Re: Draft: Add-on Policies Blair McBride 6/29/12 6:25 PM
On 30/06/2012 2:06 a.m., David Bruant wrote:
> Since you're in control of the platform the add-ons run on, it's up to
> you to not give abusive authority. Specifically for:
> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager
> * Add-ons must remove all introduced code, executables, and application
> configuration changes once they are uninstalled.

Indeed, these are things we need to work on.

- Blair
Re: Draft: Add-on Policies Nicholas Nethercote 6/29/12 8:13 PM
On Sat, Jun 30, 2012 at 2:39 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
> Providing a support channel for users is something any responsible developer
> should do, but I can see how casual developers would see that as a time
> sink. Note that we're asking for this but we don't set any expectations on
> how responsive the developer must be, so this is really up to them to
> decide. It should also be noted that these support channels are often the
> only way we can get in touch with developers in the case of an emergency,
> like a security bug or a top crash.
>
> What we're trying to articulate with this policy is that there should be
> *some* way for users and Mozilla to get in touch with the developer.

The unclear definition of "support channel" is causing confusion here.
 Some people might interpret that as e.g. "must provide a bug
tracker", but it sounds like "must provide an email contact" is more
like it.  Clarifying this would be good.

Nick
Re: Draft: Add-on Policies Mook 6/29/12 11:29 PM
On 6/28/2012 4:34 PM, Jorge Villalobos wrote:
> The Add-ons Team is working on creating a general add-on policy that
> applies to both AMO and non-AMO add-ons. This will allow us to
> articulate what we expect from all add-on developers, and to make
> clearer what kind of behavior will not be tolerated.

Yay! Having this in a policy is definitely a good thing, I think, so
addon authors can know what they should do without having to poke people
to find out (or worse, trip and get blocklisted to find out).  I'm in
general for this; I'm going to skip over the parts I have no argument
with, though, so this might sound harsher than intended.  (I'm assuming
RFC 2119 style SHOULD/MUST.)

 > Exceptions to these policies include add-ons with the intended
 > purpose of breaking them with non-malicious intent. For example,
 > security exploit proofs of concept.

(Moved this part up) This... basically counteracts most of the things
listed, I think; how do you judge intent?  Also, what about
unintentionally breaking the policies (i.e. bugs)?  Unintentionally
exposing vulnerabilities, for example.

> * Add-ons must not be installed without user approval.

What about administrator approval (corporate security policy, kiosk
deployments)?

> * Add-ons must use a single unique id
> [https://developer.mozilla.org/en/install_manifests#id] during their
> entire lifetime.

Isn't this the definition of an addon lifetime?  I can claim to be a new
addon in that case... (I can also see a legitimate use for, say,
different IDs for different releases in the way you get yearly releases
of FIFA soccer games from EA...)

> * Add-ons should always be possible to uninstall or disable from the
> Add-ons Manager.

I see the not-installed-via-Addon-Manager case is why this is a
"should"; if that's the case, that should be called out explicitly.
I've also been involved in at least one case where the addon cannot be
disabled, because that's how branding was provided - it was a partner
build (of not-Firefox); I assume this won't matter because Mozilla will
never go that route (and this only applies to mozilla.org blocklists)?

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

I don't believe this is currently technically feasible; you can hop into
safe mode, then uninstall without the addon having a chance to run code.
  "Application configuration changes" also means you can't
uninstall/reinstall an addon as a troubleshooting step; Firefox
currently doesn't remove its own profile when uninstalled either.  (I
don't know if Firefox resets the system default browser on uninstall.)
I'd also be annoyed if, say, the locale changer changed things back on
uninstall, even if I just forgot about it for a year.

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

See administrator-deployed addons above.  Beside, reverting should
always be covered by uninstalling the addon, if the rule above is obeyed...

> * Add-on developers should provide a support channel for their users.

(Covered elsewhere; I write a bunch of unsupported addons too, but I try
to be clear about the unsupported status before users get near them.)

> * Add-ons must not expose or unsafely transmit the user's private data.
Huh, I have a password manager addon (thanks Kairo!) that exposes my
passwords to me in the UI (but not over the network).  This should
probably be rewords to "without explicit consent" or something.

> * Add-ons must not cause hangs or crashes.

I've got an extension that provides a JS shell; that can cause hangs if
I tell it to infinite loop.  I'd like to keep it though, because 1)
that's my own fault, 2) I believe my life is better off with the hangs
than without the add-on.  As a user, will I no longer have a choice?

> * Add-ons should not consume excessive amounts of memory or cause memory
> leaks.

"Excessive" will be fun to define - especially if the user expects it.

 > * Add-ons should not slow the application down significantly.

Hmm, that's a trade-off, I think.  Old versions of Firebug (haven't
needed it for a while) did slow down the application significantly, on
account of Gecko limitations; it was generally still pretty useful
installed (especially into a development profile where you know things
will be slow).

> Per blocklisting policy, 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.

So far, most blocklisting discussion seems to be happening in public
bugs; please keep that up!  That's awesome, and really makes me feel
safe knowing seeing the proof that Mozilla (/ people involved) tries
hard to avoid blocklisting.  It's a big hammer, and it should be wielded
carefully (but used when appropriate).

In general, my stance is that users should be allowed to shoot their
feet if they know they're doing it; I suspect others don't agree, though.
--
Mook
Re: Draft: Add-on Policies David Bruant 6/30/12 2:34 AM
Le 30/06/2012 03:25, Blair McBride a écrit :
> On 30/06/2012 2:06 a.m., David Bruant wrote:
>> Since you're in control of the platform the add-ons run on, it's up to
>> you to not give abusive authority. Specifically for:
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager
>> * Add-ons must remove all introduced code, executables, and application
>> configuration changes once they are uninstalled.
>
> Indeed, these are things we need to work on.
Good to know. Is there a bug number or link to discussion to follow the
progress or participate one that?

Thanks,

David
Re: Draft: Add-on Policies David Bruant 6/30/12 2:37 AM
Le 30/06/2012 01:57, Jorge Villalobos a écrit :
I think it doesn't to hurt be explicit regarding add-ons not being
allowed to modify Firefox files (for whatever purpose)

David

Re: Draft: Add-on Policies David Bruant 6/30/12 2:47 AM
Le 30/06/2012 03:16, Blair McBride a écrit :
>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>
> I'd modify that to something like "should not unnecessarily consume
> excessive amounts of memory". For some things, you just need to use
> bucket loads of memory - more than the user would expect ("How hard
> can a self-aware AI be to code? It shouldn't need to use THAT much
> memory!").
The MemShrink effort showed that add-ons were absuing or leaking memory.
It's my understading that they created a bunch of tools to monitor
memory consumed by Firefox, inculding add-ons.
Maybe a restriction could be put on memory for add-ons. When reaching
some limit (25Mo? 50Mo?), the user would be prompted "such add-on is
using a lot of memory. It may degrade your overall experience. Do you
want to disable it, uninstall it, allow it to use more memory, tell AMO
about it, tell the developer about it?". (this list of choices is just
an idea)
If add-ons devs had feedback on users disabling addons because of
memory, they would maybe be more careful (though that's completely
unproven). It would also be a way for Firefox to put the blame on who
should carry it. Firefox should not be accused of bad performance if
it's because of add-ons and if a user sees regularly the prompt coming
for a particular add-on, they will know that the overall performance may
be degraded because of this add-on and not necesarily Firefox.

Anonymous data could be collected to understand memory usage of addons
and reported back to the developer, maybe.

David
Re: Draft: Add-on Policies Robert Kaiser 7/1/12 4:50 PM
Jorge Villalobos schrieb:
> On 6/29/12 7:48 AM, Benjamin Smedberg wrote:
>> On 6/28/12 7:34 PM, Jorge Villalobos wrote:
>>
>>> * Add-ons should always be possible to uninstall or disable from the
>>> Add-ons Manager.
>> MUST?
>
> When the AOM supports uninstalling add-ons that are installed through
> the registry, sure :)


Well, it supports disabling, and you have "uninstall or disable" there,
so IMHO with that "or" in place it should be turned to a MUST. At least
disabling must be possible and doing so should revert anything the
add-on does (or even must for that as well?), I think.

Robert Kaiser
Re: Draft: Add-on Policies Blair McBride 7/1/12 6:44 PM
I'm assuming we have the usual grey area for corporate/managed
environments. We support dropping extensions in
APPDIR/distribution/bundles (which is used in these types of
environments). Addons in that directory aren't managed by the Add-ons
Manager - meaning they won't show up there, so there's no way to disable
or uninstall them.

- Blair
Re: Draft: Add-on Policies Blair McBride 7/1/12 7:24 PM
On 30/06/2012 9:47 p.m., David Bruant wrote:
> The MemShrink effort showed that add-ons were absuing or leaking memory.
> It's my understading that they created a bunch of tools to monitor
> memory consumed by Firefox, inculding add-ons.

We don't have any tools for automatically tracing issues back to add-ons
yet. And the semi-automated methods for getting data about memory
consumption is dependent on how the addon is written (though we can
mostly get a good idea about SDK-based add-ons). Most of the plans
around this type of thing revolve around manual testing, supported by
tools.

We tried marking add-ons as resource-intensive in the past, and it
didn't work well. It relied on automated testing, and automated flagging
of add-ons - both of which were flawed approaches. In reality there are
a lot more grey areas - it depends on what you're measuring, how you're
measuring it, and the specific case. And in general, giving addon
authors the right tools, telling them when we know there's an issue, and
having documentation on what to look out for/how to fix it, is a more
effective approach in getting addons fixed.

- Blair
Re: Draft: Add-on Policies Gervase Markham 7/2/12 3:47 AM
On 29/06/12 14:20, Majken Connor wrote:
> I like that providing support is a "should" but I think this might still be
> strong enough wording to scare some authors off. I think it depends on the
> complexity whether or not the author should provide support. For many
> add-ons it's a perfectly acceptable alternative to uninstall the add-on and
> find another. I think dropping maintenance of an add-on probably affects
> users much more than lack of support.

I agree. Open source code often comes explicitly with no warranty or
promise of fitness for a particular purpose. This is actually a feature,
not a bug. People are more likely to share their code if they are not
going to get grief (or lawsuits!) for doing so.

We have a reputation system built into AMO which should be the mechanism
by which users deal with addons which don't work very well. An addon
developer should not be forced to provide support for his addon, or be
penalized for not doing so. If people can't figure out how to use it,
they'll support each other, or it'll get downvoted.

> Maybe the criteria should be to make it clear to users whether or not there
> is active support for the add-on or if they will have to uninstall it if it
> breaks.

I think that's fine. As long as users are told "no support" up front, I
think providing no support should be a valid and legitimate option.

I agree with Jorge that it's important for _Mozilla_ to be able to get
in touch with a developer, but I disagree that developers _should_
provide some way for _users_ to get in touch with them.

I would be much more sympathetic to a MUST requirement for paid addons,
as Gijs suggests.

Gerv
Re: Draft: Add-on Policies Justin Lebar 7/2/12 4:31 AM
I'd like to understand the structure for making decisions about this policy.
Who specifically is involved in the final decision-making process?  I'd like to
make sure in particular that the platform group is represented among the
deciders here, as there can be no doubt that this policy affects the stability
and performance of our platform.

>> Why isn't this a MUST, at least for disabling the add-on?  Perhaps it's a
>> MUST except under certain conditions?
>
> If you install an extension externally, in the way we recommend (through the
> registry), there's no way to uninstall it. You can only disable it. This
> policy was initially written as a MUST, but it'll have to wait for the
> Add-ons Manager to support uninstalling these sorts of add-on.

Sorry, I wasn't clear.

I understand that not all add-ons can be uninstalled at the moment, and until
we fix that, that can't be a MUST.  (Indeed, inasmuch as our recommended way of
installing an add-on keeps it from being uninstalled, I don't think it should
be a SHOULD either.)

But what I mean is, can we say that every add-on MUST be disableable?  And can
we say that, upon disabling an add-on, all modified user prefs MUST be reset?

>> I think we should add here that add-ons MUST NOT use our APIs in "unsafe"
>> ways, i.e., ways which may cause crashes or security vulnerabilities.
>>
>> For example, add-ons MUST NOT use main-thread objects off the main thread.
>> [snip]
>
> The policies are focused on the consequences of the developer's actions, and
> not the specific coding practices that lead to these issues. There are
> policies covering security and stability, and the additional docs would
> explain what kinds of bad practices can lead to the problems the policies
> cover. So, I feel that this addition would be too low-level and redundant.

What I would like changed in the policy is an explicit mention somewhere of the
fact that it's not OK to do stupid things which likely cause crashes, even when
we can't prove beyond a reasonable doubt that the stupid things /do/ cause
crashes.

This is an important case for us, because it puts the burden on add-on
developers to do things the Right Way, instead of on us to make an often
difficult case that the Wrong Way is causing Firefox to misbehave.

>> Like njn, I don't think the right criterion is "many of the SHOULD
>> guidelines".  Instead, it should be a question of degree: How badly does it
>> violate the guidelines?
>
> Do you think the must/should distinction is unnecessary then? Or is this
> something that should only be changed for the SHOULD guidelines?

I think the basic idea behind the MUST/SHOULD distinction is sound -- some
criteria are more important than others.

Perhaps instead we could have guidelines for how long we might be willing to
wait for a fix to each type of issue.  We're willing to wait longer for
less-important things.

>>> Per blocklisting policy, 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.
>>
>> "The only exception to this" is in fact more permissive than our current
>> policy: We will currently unilaterally blacklist an add-on which causes lots
>> of crashes, right?
>
> No, we always try to contact the developers first. We've never had a crash
> rate serious enough that can't wait for a couple of days before
> blocklisting.

Understood.

I guess my question is about the amount of time we're willing to wait for a
fix.  To be concrete: We waited two months for McAfee to ship a full leak fix
to users.

Suppose things had gone as they did: McAfee shipped an improved version three
weeks after we notified them, but the add-on still leaked far beyond acceptable
levels.  Would we have taken action at that point?

In general: In order to evaluate this proposed policy, I'd like to understand
how we would have acted differently in this and other similar cases we've
encountered in the past.

>> Looking through this list, it seems to me that flagrant violations of the
>> MUST violations should result in immediate blocklisting, whereas we might
>> tolerate some delay fixing venal violations of SHOULD criteria.  Again, this
>> mirrors our current policy with respect to crashes, as I understand it.
>>
>> We would want to institute this policy after some grace period, of course,
>> and we'd work with anyone in violation of the MUST policies during the grace
>> period.  But I propose that after that period, a non-venial MUST violation
>> would be cause for immediate blocklisting.
>
> That doesn't match our current policies and I don't think we should take
> them in that direction. Being cooperative has always been the best way to
> get results from developers in my experience.

Being cooperative with people who are cooperative with us is great.

But if our policy says that an add-on author "must" do something, and they
flagrantly ignore our rules, it's hard to cast that behavior as "cooperative".

Perhaps "non-venal" isn't the right criterion for the kind of policy violation
I'm talking about.  Maybe "flagrant and intentional" is better.

If the objection is to "immediately take unilateral action", I'm OK with
"contact the developer and give them X days to release a fix to users" for all
but the worst-imaginable cases, for some small X.

But note that it's "X days to release a fix", not "X days to respond and say
they're working on it."

>> Separately, I think we ought to reserve the right to stop working with a
>> given developer.  For example, a developer might be reachable and
>> responsive, but effectively using Mozilla as their QA lab and our users as
>> their testers, pushing buggy changes and expecting us to debug them.
>>
>> Under this proposed policy, we wouldn't be able to do anything except
>> continue to work with this developer to improve their code, while our users
>> continue to suffer.  At some point, we should be able to say that enough is
>> enough.
>
> That's the "reasonable timeframe" bit. We wouldn't just wait indefinitely
> for a fix. At some point, if blocklisting is the only way to get things
> fixed and the developer is being too slow, we'll do it. This is the way it
> works now.

Again, not to pick on McAfee, but we've had a lot of critical issues with
SiteAdvisor and friends in the past [1].

My feeling is that, when an add-on (particularly a commercial add-on) exhausts
our patience (*), they should no longer be allowed to use our users as testers.

Instead, they should be required to submit their add-on to Mozilla for testing
and approval /before/ they ship to users.  That's the only way we're going to
guarantee the quality of add-ons with a bad history.

Users not on our testing branches are not testers, and it's not acceptable for
add-on developers to use them in that way.

(*) Not to beg the question as to whether McAfee in particular has.

> We have discussed ways to increase our reach and knowledge of non-AMO
> add-ons, but I think that is off-topic for this discussion.

I'm happy to hear that this has been discussed.  When can we expect to hear
about the results of these discussions and the actions you plan to take as a
result?

[1] https://bugzilla.mozilla.org/buglist.cgi?short_desc=siteadvisor;query_format=advanced;short_desc_type=allwordssubstr;list_id=3588227
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:06 AM
On 6/30/12 12:29 AM, Mook wrote:
>  > Exceptions to these policies include add-ons with the intended
>  > purpose of breaking them with non-malicious intent. For example,
>  > security exploit proofs of concept.
>
> (Moved this part up) This... basically counteracts most of the things
> listed, I think; how do you judge intent?

That'll be up to the Add-ons Team to decide. In the majority of cases I
think it will be fairly obvious what the intent is.

> Also, what about
> unintentionally breaking the policies (i.e. bugs)? Unintentionally
> exposing vulnerabilities, for example.

I expect most policy violations to be unintentional, but there are still
violations and will be subject to their consequences. We will try to
work with the developers to get the problem fixed before taking any
other action, as always.

>> * Add-ons must not be installed without user approval.
>
> What about administrator approval (corporate security policy, kiosk
> deployments)?

That's an exception.

>> * Add-ons must use a single unique id
>> [https://developer.mozilla.org/en/install_manifests#id] during their
>> entire lifetime.
>
> Isn't this the definition of an addon lifetime? I can claim to be a new
> addon in that case... (I can also see a legitimate use for, say,
> different IDs for different releases in the way you get yearly releases
> of FIFA soccer games from EA...)

No. If you're using a different id to denote different versions of the
same product, you're doing it wrong. Having multiple IDs makes our work
much more difficult, which is why we require it.

>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
>
> I see the not-installed-via-Addon-Manager case is why this is a
> "should"; if that's the case, that should be called out explicitly. I've
> also been involved in at least one case where the addon cannot be
> disabled, because that's how branding was provided - it was a partner
> build (of not-Firefox); I assume this won't matter because Mozilla will
> never go that route (and this only applies to mozilla.org blocklists)?

If what you're asking is whether bundled add-ons won't qualify for this
policy, the opinion is that they will.

>> * Add-ons must remove all introduced code, executables, and application
>> configuration changes once they are uninstalled.
>
> I don't believe this is currently technically feasible; you can hop into
> safe mode, then uninstall without the addon having a chance to run code.

That's a bit of an edge case, but thanks for bringing it up. I hadn't
considered it.

> "Application configuration changes" also means you can't
> uninstall/reinstall an addon as a troubleshooting step; Firefox
> currently doesn't remove its own profile when uninstalled either. (I
> don't know if Firefox resets the system default browser on uninstall.)
> I'd also be annoyed if, say, the locale changer changed things back on
> uninstall, even if I just forgot about it for a year.

I think most users expect that when they remove an add-on, all of its
effects on their Firefox are reverted. Why would you uninstall it otherwise?

>> * Add-ons must not expose or unsafely transmit the user's private data.
> Huh, I have a password manager addon (thanks Kairo!) that exposes my
> passwords to me in the UI (but not over the network). This should
> probably be rewords to "without explicit consent" or something.

That's not the intended meaning of "expose" in this policy. I guess I
should reword it to "expose to others" or something like that.

>
>> * Add-ons must not cause hangs or crashes.
>
> I've got an extension that provides a JS shell; that can cause hangs if
> I tell it to infinite loop. I'd like to keep it though, because 1)
> that's my own fault, 2) I believe my life is better off with the hangs
> than without the add-on. As a user, will I no longer have a choice?

At this point I realize that you're taking this way too literally ;).
This is a series of guidelines, not a legal document or a program. Yes,
you'll still be allowed to create add-ons that have the potential to
hang or even crash in some cases due to user input.

> In general, my stance is that users should be allowed to shoot their
> feet if they know they're doing it; I suspect others don't agree, though.

Very few users know they're shooting their feet, though.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:06 AM
On 6/30/12 12:29 AM, Mook wrote:
>  > Exceptions to these policies include add-ons with the intended
>  > purpose of breaking them with non-malicious intent. For example,
>  > security exploit proofs of concept.
>
> (Moved this part up) This... basically counteracts most of the things
> listed, I think; how do you judge intent?

That'll be up to the Add-ons Team to decide. In the majority of cases I
think it will be fairly obvious what the intent is.

> Also, what about
> unintentionally breaking the policies (i.e. bugs)? Unintentionally
> exposing vulnerabilities, for example.

I expect most policy violations to be unintentional, but there are still
violations and will be subject to their consequences. We will try to
work with the developers to get the problem fixed before taking any
other action, as always.

>> * Add-ons must not be installed without user approval.
>
> What about administrator approval (corporate security policy, kiosk
> deployments)?

That's an exception.

>> * Add-ons must use a single unique id
>> [https://developer.mozilla.org/en/install_manifests#id] during their
>> entire lifetime.
>
> Isn't this the definition of an addon lifetime? I can claim to be a new
> addon in that case... (I can also see a legitimate use for, say,
> different IDs for different releases in the way you get yearly releases
> of FIFA soccer games from EA...)

No. If you're using a different id to denote different versions of the
same product, you're doing it wrong. Having multiple IDs makes our work
much more difficult, which is why we require it.

>
>> * Add-ons should always be possible to uninstall or disable from the
>> Add-ons Manager.
>
> I see the not-installed-via-Addon-Manager case is why this is a
> "should"; if that's the case, that should be called out explicitly. I've
> also been involved in at least one case where the addon cannot be
> disabled, because that's how branding was provided - it was a partner
> build (of not-Firefox); I assume this won't matter because Mozilla will
> never go that route (and this only applies to mozilla.org blocklists)?

If what you're asking is whether bundled add-ons won't qualify for this
policy, the opinion is that they will.

>> * Add-ons must remove all introduced code, executables, and application
>> configuration changes once they are uninstalled.
>
> I don't believe this is currently technically feasible; you can hop into
> safe mode, then uninstall without the addon having a chance to run code.

That's a bit of an edge case, but thanks for bringing it up. I hadn't
considered it.

> "Application configuration changes" also means you can't
> uninstall/reinstall an addon as a troubleshooting step; Firefox
> currently doesn't remove its own profile when uninstalled either. (I
> don't know if Firefox resets the system default browser on uninstall.)
> I'd also be annoyed if, say, the locale changer changed things back on
> uninstall, even if I just forgot about it for a year.

I think most users expect that when they remove an add-on, all of its
effects on their Firefox are reverted. Why would you uninstall it otherwise?

>> * Add-ons must not expose or unsafely transmit the user's private data.
> Huh, I have a password manager addon (thanks Kairo!) that exposes my
> passwords to me in the UI (but not over the network). This should
> probably be rewords to "without explicit consent" or something.

That's not the intended meaning of "expose" in this policy. I guess I
should reword it to "expose to others" or something like that.

>
>> * Add-ons must not cause hangs or crashes.
>
> I've got an extension that provides a JS shell; that can cause hangs if
> I tell it to infinite loop. I'd like to keep it though, because 1)
> that's my own fault, 2) I believe my life is better off with the hangs
> than without the add-on. As a user, will I no longer have a choice?

At this point I realize that you're taking this way too literally ;).
This is a series of guidelines, not a legal document or a program. Yes,
you'll still be allowed to create add-ons that have the potential to
hang or even crash in some cases due to user input.

> In general, my stance is that users should be allowed to shoot their
> feet if they know they're doing it; I suspect others don't agree, though.

Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:31 AM
On 7/2/12 5:31 AM, Justin Lebar wrote:
> I'd like to understand the structure for making decisions about this policy.
> Who specifically is involved in the final decision-making process?  I'd like to
> make sure in particular that the platform group is represented among the
> deciders here, as there can be no doubt that this policy affects the stability
> and performance of our platform.

I'm not proposing any alternatives to the way things currently work,
which is that anyone can bring up policy violations and it is up to the
Add-ons Team to contact the developers and determine whether to
blocklist or take other actions. For more problematic cases (crashes,
widespread malware) the release drivers team would need to be in the
loop as well. If you want to discuss alternatives to this process, I
think we should start a different thread for it.

> But what I mean is, can we say that every add-on MUST be disableable?

We could say that yes, though I think it makes the policy a little
harder to parse.

> And can
> we say that, upon disabling an add-on, all modified user prefs MUST be reset?

There's a separate point in the policy covering this. Unless I'm
mistaken, if an add-on makes all pref changes in the default prefs file,
when the add-on is disabled the preferences are set back to their
previous value.

> What I would like changed in the policy is an explicit mention somewhere of the
> fact that it's not OK to do stupid things which likely cause crashes, even when
> we can't prove beyond a reasonable doubt that the stupid things /do/ cause
> crashes.
>
> This is an important case for us, because it puts the burden on add-on
> developers to do things the Right Way, instead of on us to make an often
> difficult case that the Wrong Way is causing Firefox to misbehave.

I don't think this should be part of the policy. Crashes are not OK
regardless of the reason behind them, and "don't do stupid things" is
hardly a productive thing to communicate to developers.

> I think the basic idea behind the MUST/SHOULD distinction is sound -- some
> criteria are more important than others.
>
> Perhaps instead we could have guidelines for how long we might be willing to
> wait for a fix to each type of issue.  We're willing to wait longer for
> less-important things.

I think time waiting time is too variable and it would be hard to add it
to the policy without us breaking our own rules all the time. Having two
levels makes it easier for everybody to understand what we mean and get
a general idea of how we'll react.

> I guess my question is about the amount of time we're willing to wait for a
> fix.  To be concrete: We waited two months for McAfee to ship a full leak fix
> to users.
>
> Suppose things had gone as they did: McAfee shipped an improved version three
> weeks after we notified them, but the add-on still leaked far beyond acceptable
> levels.  Would we have taken action at that point?
>
> In general: In order to evaluate this proposed policy, I'd like to understand
> how we would have acted differently in this and other similar cases we've
> encountered in the past.

I don't consider this to be a change in our policy, but more a
formalization of the unwritten policy that we already have. There are a
couple of new things in this one for sure, but the enforcement part is
pretty much the same. We will always reach out to the developers,
evaluate the severity of the problem, and determine how long should we
wait for a fix and whether blocklisting should be considered or not.
These things take time, but we believe it's the best way to get these
problems resolved.

> If the objection is to "immediately take unilateral action", I'm OK with
> "contact the developer and give them X days to release a fix to users" for all
> but the worst-imaginable cases, for some small X.
>
> But note that it's "X days to release a fix", not "X days to respond and say
> they're working on it."

While this sounds fair, we always need to weigh the cost and benefit of
using the blocklist. Once we have a better warning system we won't need
to worry about this, but in the meantime things aren't as clear cut.
Blocklisting an add-on punishes users as much (or even more) than it
punishes developers, so we need to use it with caution.

> Instead, they should be required to submit their add-on to Mozilla for testing
> and approval /before/ they ship to users.  That's the only way we're going to
> guarantee the quality of add-ons with a bad history.

Well, that's a separate discussion, and you already know that I disagree
with this.

> I'm happy to hear that this has been discussed.  When can we expect to hear
> about the results of these discussions and the actions you plan to take as a
> result?

Yes, there are a couple of things from the Add-ons Work Week I need to
get in order before they can be presented as an actual plan. Hopefully
it won't be long.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:31 AM
On 7/2/12 5:31 AM, Justin Lebar wrote:
> I'd like to understand the structure for making decisions about this policy.
> Who specifically is involved in the final decision-making process?  I'd like to
> make sure in particular that the platform group is represented among the
> deciders here, as there can be no doubt that this policy affects the stability
> and performance of our platform.

I'm not proposing any alternatives to the way things currently work,
which is that anyone can bring up policy violations and it is up to the
Add-ons Team to contact the developers and determine whether to
blocklist or take other actions. For more problematic cases (crashes,
widespread malware) the release drivers team would need to be in the
loop as well. If you want to discuss alternatives to this process, I
think we should start a different thread for it.

> But what I mean is, can we say that every add-on MUST be disableable?

We could say that yes, though I think it makes the policy a little
harder to parse.

> And can
> we say that, upon disabling an add-on, all modified user prefs MUST be reset?

There's a separate point in the policy covering this. Unless I'm
mistaken, if an add-on makes all pref changes in the default prefs file,
when the add-on is disabled the preferences are set back to their
previous value.

> What I would like changed in the policy is an explicit mention somewhere of the
> fact that it's not OK to do stupid things which likely cause crashes, even when
> we can't prove beyond a reasonable doubt that the stupid things /do/ cause
> crashes.
>
> This is an important case for us, because it puts the burden on add-on
> developers to do things the Right Way, instead of on us to make an often
> difficult case that the Wrong Way is causing Firefox to misbehave.

I don't think this should be part of the policy. Crashes are not OK
regardless of the reason behind them, and "don't do stupid things" is
hardly a productive thing to communicate to developers.

> I think the basic idea behind the MUST/SHOULD distinction is sound -- some
> criteria are more important than others.
>
> Perhaps instead we could have guidelines for how long we might be willing to
> wait for a fix to each type of issue.  We're willing to wait longer for
> less-important things.

I think time waiting time is too variable and it would be hard to add it
to the policy without us breaking our own rules all the time. Having two
levels makes it easier for everybody to understand what we mean and get
a general idea of how we'll react.

> I guess my question is about the amount of time we're willing to wait for a
> fix.  To be concrete: We waited two months for McAfee to ship a full leak fix
> to users.
>
> Suppose things had gone as they did: McAfee shipped an improved version three
> weeks after we notified them, but the add-on still leaked far beyond acceptable
> levels.  Would we have taken action at that point?
>
> In general: In order to evaluate this proposed policy, I'd like to understand
> how we would have acted differently in this and other similar cases we've
> encountered in the past.

I don't consider this to be a change in our policy, but more a
formalization of the unwritten policy that we already have. There are a
couple of new things in this one for sure, but the enforcement part is
pretty much the same. We will always reach out to the developers,
evaluate the severity of the problem, and determine how long should we
wait for a fix and whether blocklisting should be considered or not.
These things take time, but we believe it's the best way to get these
problems resolved.

> If the objection is to "immediately take unilateral action", I'm OK with
> "contact the developer and give them X days to release a fix to users" for all
> but the worst-imaginable cases, for some small X.
>
> But note that it's "X days to release a fix", not "X days to respond and say
> they're working on it."

While this sounds fair, we always need to weigh the cost and benefit of
using the blocklist. Once we have a better warning system we won't need
to worry about this, but in the meantime things aren't as clear cut.
Blocklisting an add-on punishes users as much (or even more) than it
punishes developers, so we need to use it with caution.

> Instead, they should be required to submit their add-on to Mozilla for testing
> and approval /before/ they ship to users.  That's the only way we're going to
> guarantee the quality of add-ons with a bad history.

Well, that's a separate discussion, and you already know that I disagree
with this.

> I'm happy to hear that this has been discussed.  When can we expect to hear
> about the results of these discussions and the actions you plan to take as a
> result?

Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:34 AM
Yes, corporate deployments would be an exception for this rule.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:34 AM
On 7/1/12 7:44 PM, Blair McBride wrote:
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:34 AM
On 7/1/12 7:44 PM, Blair McBride wrote:
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:35 AM
What do you mean by Firefox files? The files in the application
directory? What if an add-on changes these files and reverts them to
their original state after it is uninstalled?

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:35 AM
On 6/30/12 3:37 AM, David Bruant wrote:
Re: Draft: Add-on Policies Benjamin Smedberg 7/2/12 8:38 AM
On 7/2/2012 11:35 AM, Jorge Villalobos wrote:
>
>
> What do you mean by Firefox files? The files in the application
> directory? What if an add-on changes these files and reverts them to
> their original state after it is uninstalled?
That is not acceptable. Any change to the install directory should be
disallowed. Not only would it require admin privileges on Windows, but
extensions cannot reliably take any actions when they are uninstalled.
And modifying install files can cause partial updates to fail.

--BDS

Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:56 AM
On 6/29/12 7:16 PM, Blair McBride wrote:
> I wonder if we want to include something about:
> * A user's freedom to use the web (ie, not filter parts of the web)

You mean something against add-ons that oppress users? I think that most
add-ons used this way would be used in situations where we can't /
shouldn't intervene, like corporate deployments and certain countries.

> * Disallowing addons that convey hate messages

I don't think we should have this. What constitutes hate is a very grey
area and it is culture-dependent. We have policies for this on AMO,
where they are certainly necessary, but I don't think we should police
this for the rest of the world.

> * Addon updates that significantly change what an addon does

This is somewhat covered in the transparency section, where it says that
add-ons should be clear about the features they include. This might need
some clarification, though.


> On 29/06/2012 11:34 a.m., Jorge Villalobos wrote:
>> * Add-ons must use a single unique id
>> [https://developer.mozilla.org/en/install_manifests#id] during their
>> entire lifetime.
>
> The trouble is that this is a supported and advertised feature. We added
> support for changing an addon's ID via their update manifest in Fx4 (in
> fact, support for that was explicitly requested by Fligtar - see bug
> 412819). It's mentioned in the docs here:
> https://developer.mozilla.org/index.php?title=en/Extension_Versioning%2C_Update_and_Compatibility#Automatic_Add-on_Update_Checking
>
>
> I'm not sure if AMO supports it or not (I thought it did, but see bug
> 765717).

I think we should generally disallow ID switching because it makes
add-ons very hard to track and block. I can see in bug 412819 that there
are valid cases for changing an ID, so I guess those should be
considered as exceptions.

>> * Add-on developers should provide a support channel for their users.
>
> Do you consider anything AMO currently has as being an acceptable
> support channel? I'm leaning towards "no", but I think it should.

This is the policy that has brought up the most questions, so it is
clear that it needs some work :). Just having a contact point like an
email address of a contact form should suffice to satisfy this policy IMO.

>> * Add-ons must not cause harm to the user's online identities, data or
>> system.
>
> What about offline implications?

The online bit only applies to identities, not the rest. So, "data"
means "all data" and "system" means "anything on their computer". This
needs some rewording to make it clearer.

>> * Add-ons must not cause hangs or crashes.
>
> What about bugs? If its a blanket ban on any possibility of a
> crash/hang, Firefox itself wouldn't pass the test.

Any crash or hang should be taken seriously, and depending on its
severity it could lead to blocklisting. But the process remains the
same: we'll contact the developers and work with them to get the problem
fixed. We won't outright block an add-on unless it is crashing half of
the world.

>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>
> I'd modify that to something like "should not unnecessarily consume
> excessive amounts of memory". For some things, you just need to use
> bucket loads of memory - more than the user would expect ("How hard can
> a self-aware AI be to code? It shouldn't need to use THAT much memory!").

Makes sense.

Thanks!

Jorge

Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:56 AM
On 6/29/12 7:16 PM, Blair McBride wrote:
> I wonder if we want to include something about:
> * A user's freedom to use the web (ie, not filter parts of the web)

You mean something against add-ons that oppress users? I think that most
add-ons used this way would be used in situations where we can't /
shouldn't intervene, like corporate deployments and certain countries.

> * Disallowing addons that convey hate messages

I don't think we should have this. What constitutes hate is a very grey
area and it is culture-dependent. We have policies for this on AMO,
where they are certainly necessary, but I don't think we should police
this for the rest of the world.

> * Addon updates that significantly change what an addon does

This is somewhat covered in the transparency section, where it says that
add-ons should be clear about the features they include. This might need
some clarification, though.


> On 29/06/2012 11:34 a.m., Jorge Villalobos wrote:
>> * Add-ons must use a single unique id
>> [https://developer.mozilla.org/en/install_manifests#id] during their
>> entire lifetime.
>
> The trouble is that this is a supported and advertised feature. We added
> support for changing an addon's ID via their update manifest in Fx4 (in
> fact, support for that was explicitly requested by Fligtar - see bug
> 412819). It's mentioned in the docs here:
> https://developer.mozilla.org/index.php?title=en/Extension_Versioning%2C_Update_and_Compatibility#Automatic_Add-on_Update_Checking
>
>
> I'm not sure if AMO supports it or not (I thought it did, but see bug
> 765717).

I think we should generally disallow ID switching because it makes
add-ons very hard to track and block. I can see in bug 412819 that there
are valid cases for changing an ID, so I guess those should be
considered as exceptions.

>> * Add-on developers should provide a support channel for their users.
>
> Do you consider anything AMO currently has as being an acceptable
> support channel? I'm leaning towards "no", but I think it should.

This is the policy that has brought up the most questions, so it is
clear that it needs some work :). Just having a contact point like an
email address of a contact form should suffice to satisfy this policy IMO.

>> * Add-ons must not cause harm to the user's online identities, data or
>> system.
>
> What about offline implications?

The online bit only applies to identities, not the rest. So, "data"
means "all data" and "system" means "anything on their computer". This
needs some rewording to make it clearer.

>> * Add-ons must not cause hangs or crashes.
>
> What about bugs? If its a blanket ban on any possibility of a
> crash/hang, Firefox itself wouldn't pass the test.

Any crash or hang should be taken seriously, and depending on its
severity it could lead to blocklisting. But the process remains the
same: we'll contact the developers and work with them to get the problem
fixed. We won't outright block an add-on unless it is crashing half of
the world.

>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>
> I'd modify that to something like "should not unnecessarily consume
> excessive amounts of memory". For some things, you just need to use
> bucket loads of memory - more than the user would expect ("How hard can
> a self-aware AI be to code? It shouldn't need to use THAT much memory!").

Makes sense.

Thanks!

Jorge

Re: Draft: Add-on Policies Jorge Villalobos 7/2/12 8:56 AM
On 6/29/12 7:16 PM, Blair McBride wrote:
> I wonder if we want to include something about:
> * A user's freedom to use the web (ie, not filter parts of the web)

You mean something against add-ons that oppress users? I think that most
add-ons used this way would be used in situations where we can't /
shouldn't intervene, like corporate deployments and certain countries.

> * Disallowing addons that convey hate messages

I don't think we should have this. What constitutes hate is a very grey
area and it is culture-dependent. We have policies for this on AMO,
where they are certainly necessary, but I don't think we should police
this for the rest of the world.

> * Addon updates that significantly change what an addon does

This is somewhat covered in the transparency section, where it says that
add-ons should be clear about the features they include. This might need
some clarification, though.


> On 29/06/2012 11:34 a.m., Jorge Villalobos wrote:
>> * Add-ons must use a single unique id
>> [https://developer.mozilla.org/en/install_manifests#id] during their
>> entire lifetime.
>
> The trouble is that this is a supported and advertised feature. We added
> support for changing an addon's ID via their update manifest in Fx4 (in
> fact, support for that was explicitly requested by Fligtar - see bug
> 412819). It's mentioned in the docs here:
> https://developer.mozilla.org/index.php?title=en/Extension_Versioning%2C_Update_and_Compatibility#Automatic_Add-on_Update_Checking
>
>
> I'm not sure if AMO supports it or not (I thought it did, but see bug
> 765717).

I think we should generally disallow ID switching because it makes
add-ons very hard to track and block. I can see in bug 412819 that there
are valid cases for changing an ID, so I guess those should be
considered as exceptions.

>> * Add-on developers should provide a support channel for their users.
>
> Do you consider anything AMO currently has as being an acceptable
> support channel? I'm leaning towards "no", but I think it should.

This is the policy that has brought up the most questions, so it is
clear that it needs some work :). Just having a contact point like an
email address of a contact form should suffice to satisfy this policy IMO.

>> * Add-ons must not cause harm to the user's online identities, data or
>> system.
>
> What about offline implications?

The online bit only applies to identities, not the rest. So, "data"
means "all data" and "system" means "anything on their computer". This
needs some rewording to make it clearer.

>> * Add-ons must not cause hangs or crashes.
>
> What about bugs? If its a blanket ban on any possibility of a
> crash/hang, Firefox itself wouldn't pass the test.

Any crash or hang should be taken seriously, and depending on its
severity it could lead to blocklisting. But the process remains the
same: we'll contact the developers and work with them to get the problem
fixed. We won't outright block an add-on unless it is crashing half of
the world.

>> * Add-ons should not consume excessive amounts of memory or cause memory
>> leaks.
>
> I'd modify that to something like "should not unnecessarily consume
> excessive amounts of memory". For some things, you just need to use
> bucket loads of memory - more than the user would expect ("How hard can
> a self-aware AI be to code? It shouldn't need to use THAT much memory!").

Makes sense.

Thanks!

Jorge

Re: Draft: Add-on Policies Justin Lebar 7/2/12 9:12 AM
>> I'd like to understand the structure for making decisions about this
>> policy.
>> Who specifically is involved in the final decision-making process?  I'd
>> like to
>> make sure in particular that the platform group is represented among the
>> deciders here, as there can be no doubt that this policy affects the
>> stability
>> and performance of our platform.
>
> I'm not proposing any alternatives to the way things currently work, which
> is that anyone can bring up policy violations and it is up to the Add-ons
> Team to contact the developers and determine whether to blocklist or take
> other actions. For more problematic cases (crashes, widespread malware) the
> release drivers team would need to be in the loop as well. If you want to
> discuss alternatives to this process, I think we should start a different
> thread for it.

I don't mean, who decides when to blocklist an add-on, although in
that case too do I think it's critical that platform engineers have a
say.  The release drivers is, imo, not exactly the right group of
people to involve, since their charter is not to police the add-ons
space.  We have engineers who own performance and stability, separate
from release-drivers, and they should have a say in decisions which
affect the performance and stability of our product.

This is a critical part of the add-ons policy, and I don't think
that's at all a separate discussion from this thread.

But that's not what I meant to bring up.

What I mean is, what group of people decides which of these policy
changes proposed here to enact?  Is this entirely your decision?

> There's a separate point in the policy covering this. Unless I'm mistaken,
> if an add-on makes all pref changes in the default prefs file, when the
> add-on is disabled the preferences are set back to their previous value.

I believe you are mistaken.  As far as I can tell, we have no way to
tell whether a pref change came from FF chrome or from an add-on.
Without that mechanism, we have no way to direct the pref change to an
"add-on-specific" prefs file.  And without that, we have no way to
roll back all of an add-on's pref changes once the add-on is disabled.

>> What I would like changed in the policy is an explicit mention somewhere
>> of the
>> fact that it's not OK to do stupid things which likely cause crashes, even
>> when
>> we can't prove beyond a reasonable doubt that the stupid things /do/ cause
>> crashes.
>>
>> This is an important case for us, because it puts the burden on add-on
>> developers to do things the Right Way, instead of on us to make an often
>> difficult case that the Wrong Way is causing Firefox to misbehave.
>
> I don't think this should be part of the policy. Crashes are not OK
> regardless of the reason behind them, and "don't do stupid things" is hardly
> a productive thing to communicate to developers.

I must not be articulating my point well.  This is a question of
whether we bear the burden of proof that an add-on is crashy, or
whether, upon observing plainly bad code, we can treat that code as
the equivalent of crashy code.

I think the decision about how to handle this should be made by those
who regularly triage such bugs on the platform side and might see the
kinds of effects I'm describing -- people like marcia and bsmedberg.

>> If the objection is to "immediately take unilateral action", I'm OK with
>> "contact the developer and give them X days to release a fix to users" for
>> all
>> but the worst-imaginable cases, for some small X.
>>
>> But note that it's "X days to release a fix", not "X days to respond and
>> say
>> they're working on it."
>
> While this sounds fair, we always need to weigh the cost and benefit of
> using the blocklist. Once we have a better warning system we won't need to
> worry about this, but in the meantime things aren't as clear cut.
> Blocklisting an add-on punishes users as much (or even more) than it
> punishes developers, so we need to use it with caution.

So then it seems to me that a critical part of any change to the
add-ons policy will involve considering alternative ways to mitigate
the harm of an add-on.  Nick brought this up earlier.  I don't think
it's correct for us to punt on this -- it's been brought up many, many
times before, and I've observed zero concrete action on the subject.
If we're not going to figure it out now, when will we?

>> I'm happy to hear that this has been discussed.  When can we expect to
>> hear
>> about the results of these discussions and the actions you plan to take as
>> a
>> result?
>
> Yes, there are a couple of things from the Add-ons Work Week I need to get
> in order before they can be presented as an actual plan. Hopefully it won't
> be long.

Can you please give us a date at which we can expect to expect to have
heard about this?  This way, I can put it in my calendar and forget
about it until then, instead of bringing it up every time add-ons
policy is broached.

>> In general: In order to evaluate this proposed policy, I'd like to
>> understand
>> how we would have acted differently in this and other similar cases we've
>> encountered in the past.
>
> I don't consider this to be a change in our policy, but more a formalization
> of the unwritten policy that we already have. There are a couple of new
> things in this one for sure, but the enforcement part is pretty much the
> same.

If this is not a change in policy but rather a formalization of how
things have been done, I can't say I'm in favor of this proposal,
because I consider the current system to be broken.

Given your stance that this proposal does not reflect a policy change,
I also don't understand how to give further feedback here.  Every
change I suggest will be answered with "that's not in scope of this
discussion" or "that's not how we do things", right?

Starting this thread was a great gesture.  But I feel like we're back
where we always end up in these discussions -- I say things, you say
"I disagree", and that's the end of it.  I can't say I'm interested in
having more discussions of this form.

If you're not proposing that we take a hard look at our current policy
and consider whether it's the best way to protect our users, and if
you're not proposing that others be involved in the decision-making
process (with respect both to the policy itself and to the decisions
the policy asks us to make), then I propose that we convene a working
group to consider actual policy changes.  And I propose that this
working group be composed of people from across the community, not
just from the add-ons team, since it's clear that these problems
affect us all.

If your stance is that there are no decisions to be made here save how
to formalize an existing process, then I don't understand what you'd
like feedback on, since you're unquestionably the expert on how the
existing process works.

-Justin
Re: Draft: Add-on Policies David Bruant 7/2/12 1:43 PM
Le 02/07/2012 17:35, Jorge Villalobos a écrit :
> On 6/30/12 3:37 AM, David Bruant wrote:
>> Le 30/06/2012 01:57, Jorge Villalobos a écrit :
>>> On 6/29/12 4:21 PM, David Bruant wrote:
>>>> Le 29/06/2012 20:33, Boris Zbarsky a écrit :
>>>>> On 6/29/12 1:56 PM, David Bruant wrote:
>>>>>> If new addons are detected,
>>>>>> you can ask for the user confirmation.
>>>>>
>>>>> Yes, that's similar to what we do now.  The point of the policy is
>>>>> that addons are not supposed to subvert this mechanism (e.g. by
>>>>> automatically adding themselves to the stored list as it was during
>>>>> last Firefox close)!
>>>> The policy should make that explicit in my opinion.
>>>
>>> The policy is already explicit about requiring using consent. How this
>>> consent occurs is not part of the policy and can change depending on
>>> circumstances. I want to have a policy that is concise and
>>> future-proof, and I don't think this would add value to it.
>> I think it doesn't to hurt be explicit regarding add-ons not being
>> allowed to modify Firefox files (for whatever purpose)
>>
>> David
>>
>
> What do you mean by Firefox files? The files in the application
> directory? What if an add-on changes these files and reverts them to
> their original state after it is uninstalled?
It's not really about the files themselves.
There are things that are allowed to add-ons and things that aren't (or
shouldn't be). If an add-on has a legitimate change to do to a file and
this change will be undone either through a pre-uninstall script or
through the uninstallation process, there should be a dedicated API for
it in my opinion and the add-on shouldn't have to mess around with files.
Besides security, it's a matter of (add-on) maintainability. If an
add-on has to hack in Firefox application files, this add-on will be
broken the day the files change of structure. If there is a dedicated
API, Firefox is free to change the underneath implementation and the
add-on will not break.

Also, I'd like to say, I appologize for having diverged the discussion
to APIs and what the add-on platform "should be". It is definitely a
very enriching discussion (for me at least) but I should have started it
elsewhere.
Some details need to be ironed out for the add-on policy, but it's
overall a good idea and I'm looking forward to seeing the add-on
platform improving toward enforcing some of the rules as discussed
instead of purely relying on add-on developer trust and competency.

David
Re: Draft: Add-on Policies Gavin Sharp 7/3/12 5:45 AM
On Mon, Jul 2, 2012 at 12:12 PM, Justin Lebar <justin...@gmail.com> wrote:
> I believe you are mistaken.  As far as I can tell, we have no way to
> tell whether a pref change came from FF chrome or from an add-on.
> Without that mechanism, we have no way to direct the pref change to an
> "add-on-specific" prefs file.  And without that, we have no way to
> roll back all of an add-on's pref changes once the add-on is disabled.

Jorge was referring to add-ons that ship a defaults pref file to make
their pref changes (as opposed to making them programmatically). In
those cases, the behavior is as he describes (prefs effectively get
"reset" when the add-on is disabled/uninstalled, since the default
prefs from that bundle aren't loaded). Not all add-ons make use of
this mechanism, and not all of them can - it doesn't allow you to
change values dynamically, for example.

Gavin
Re: Draft: Add-on Policies Jorge Villalobos 7/3/12 6:06 AM
On 7/2/12 10:12 AM, Justin Lebar wrote:
> What I mean is, what group of people decides which of these policy
> changes proposed here to enact?  Is this entirely your decision?

The idea here is to get feedback from incrementally bigger groups of
people. Once we're done with this discussion we'll make a new draft and
publish it in the blog, so we can get feedback from from add-on
developers and add-on users. Once we're done with that, I think we'll be
ready to call the policy finished.

If there are other people you want to invite to this discussion, please
do so. We thought this would be the most appropriate channel to talk
about this, but there are certainly others who might be interested in it.

>> There's a separate point in the policy covering this. Unless I'm mistaken,
>> if an add-on makes all pref changes in the default prefs file, when the
>> add-on is disabled the preferences are set back to their previous value.
>
> I believe you are mistaken.  As far as I can tell, we have no way to
> tell whether a pref change came from FF chrome or from an add-on.
> Without that mechanism, we have no way to direct the pref change to an
> "add-on-specific" prefs file.  And without that, we have no way to
> roll back all of an add-on's pref changes once the add-on is disabled.

That's not correct. There are 2 ways to change a preference value. One
is through code, which is the case you describe, and the other is
through a default preferences file. In that case, when the add-on isn't
loaded, the preference change doesn't apply.

>> I don't think this should be part of the policy. Crashes are not OK
>> regardless of the reason behind them, and "don't do stupid things" is hardly
>> a productive thing to communicate to developers.
>
> I must not be articulating my point well.  This is a question of
> whether we bear the burden of proof that an add-on is crashy, or
> whether, upon observing plainly bad code, we can treat that code as
> the equivalent of crashy code.

We shouldn't assume code is crashy just because it looks crashy, IMO. Of
course there's no harm in contacting developers if we find code in their
add-ons that we believe is potentially unstable, and offer alternatives.
I don't think we'll ever block an add-on because it might crash. It's
usually fairly easy to look at crash stats and determine if a crash is
real or not and whether it is correlated to a particular add-on.

> I think the decision about how to handle this should be made by those
> who regularly triage such bugs on the platform side and might see the
> kinds of effects I'm describing -- people like marcia and bsmedberg.

The QA and Stability team are constantly triaging crash bugs and they
bring us in the loop whenever a crash becomes interesting or its
correlation to an add-on is clear. That's one of the ways we get
blocklist candidates now. Is this what you mean?

> So then it seems to me that a critical part of any change to the
> add-ons policy will involve considering alternative ways to mitigate
> the harm of an add-on.  Nick brought this up earlier.  I don't think
> it's correct for us to punt on this -- it's been brought up many, many
> times before, and I've observed zero concrete action on the subject.
> If we're not going to figure it out now, when will we?
> ...
> Can you please give us a date at which we can expect to expect to have
> heard about this?  This way, I can put it in my calendar and forget
> about it until then, instead of bringing it up every time add-ons
> policy is broached.

Like I said elsewhere, this is a separate discussion that was had in the
work week. I'm responsible for taking that and turning it into a plan,
but I don't have it ready yet. I'll try to do this either later this
week or next week, and post back.

> Given your stance that this proposal does not reflect a policy change,
> I also don't understand how to give further feedback here.  Every
> change I suggest will be answered with "that's not in scope of this
> discussion" or "that's not how we do things", right?

There are plenty of suggestions that have been given that I've thought
are good ideas and will be included as part of the policy. That in
general this is not a policy change doesn't mean that policy changes
won't be considered or accepted. I'm just saying that the main purpose
here is to formalize what we've already been doing.

What I want to focus this discussion on is the "what" we police, rather
than the "how" we enforce it. You can see this in the policy itself,
where the enforcement section is just a couple of paragraphs explaining
what we already do. This policy is a way for us to tell developers what
we expect from them, so I do think that whatever process we use to
determine whether there's a violation, and which actions are taken
depending on severity belong to a separate discussion.

> If you're not proposing that we take a hard look at our current policy
> and consider whether it's the best way to protect our users, and if
> you're not proposing that others be involved in the decision-making
> process (with respect both to the policy itself and to the decisions
> the policy asks us to make), then I propose that we convene a working
> group to consider actual policy changes.  And I propose that this
> working group be composed of people from across the community, not
> just from the add-ons team, since it's clear that these problems
> affect us all.

Well, this isn't the discussion you were looking for. This is about the
developer-facing side of things, not the internal process that you think
is so obscure.

> If your stance is that there are no decisions to be made here save how
> to formalize an existing process, then I don't understand what you'd
> like feedback on, since you're unquestionably the expert on how the
> existing process works.

See the initial post where I explain what this discussion was intended
to accomplish.

Jorge

Re: Draft: Add-on Policies Jorge Villalobos 7/3/12 6:06 AM
On 7/2/12 10:12 AM, Justin Lebar wrote:
> What I mean is, what group of people decides which of these policy
> changes proposed here to enact?  Is this entirely your decision?

The idea here is to get feedback from incrementally bigger groups of
people. Once we're done with this discussion we'll make a new draft and
publish it in the blog, so we can get feedback from from add-on
developers and add-on users. Once we're done with that, I think we'll be
ready to call the policy finished.

If there are other people you want to invite to this discussion, please
do so. We thought this would be the most appropriate channel to talk
about this, but there are certainly others who might be interested in it.

>> There's a separate point in the policy covering this. Unless I'm mistaken,
>> if an add-on makes all pref changes in the default prefs file, when the
>> add-on is disabled the preferences are set back to their previous value.
>
> I believe you are mistaken.  As far as I can tell, we have no way to
> tell whether a pref change came from FF chrome or from an add-on.
> Without that mechanism, we have no way to direct the pref change to an
> "add-on-specific" prefs file.  And without that, we have no way to
> roll back all of an add-on's pref changes once the add-on is disabled.

That's not correct. There are 2 ways to change a preference value. One
is through code, which is the case you describe, and the other is
through a default preferences file. In that case, when the add-on isn't
loaded, the preference change doesn't apply.

>> I don't think this should be part of the policy. Crashes are not OK
>> regardless of the reason behind them, and "don't do stupid things" is hardly
>> a productive thing to communicate to developers.
>
> I must not be articulating my point well.  This is a question of
> whether we bear the burden of proof that an add-on is crashy, or
> whether, upon observing plainly bad code, we can treat that code as
> the equivalent of crashy code.

We shouldn't assume code is crashy just because it looks crashy, IMO. Of
course there's no harm in contacting developers if we find code in their
add-ons that we believe is potentially unstable, and offer alternatives.
I don't think we'll ever block an add-on because it might crash. It's
usually fairly easy to look at crash stats and determine if a crash is
real or not and whether it is correlated to a particular add-on.

> I think the decision about how to handle this should be made by those
> who regularly triage such bugs on the platform side and might see the
> kinds of effects I'm describing -- people like marcia and bsmedberg.

The QA and Stability team are constantly triaging crash bugs and they
bring us in the loop whenever a crash becomes interesting or its
correlation to an add-on is clear. That's one of the ways we get
blocklist candidates now. Is this what you mean?

> So then it seems to me that a critical part of any change to the
> add-ons policy will involve considering alternative ways to mitigate
> the harm of an add-on.  Nick brought this up earlier.  I don't think
> it's correct for us to punt on this -- it's been brought up many, many
> times before, and I've observed zero concrete action on the subject.
> If we're not going to figure it out now, when will we?
> ...
> Can you please give us a date at which we can expect to expect to have
> heard about this?  This way, I can put it in my calendar and forget
> about it until then, instead of bringing it up every time add-ons
> policy is broached.

Like I said elsewhere, this is a separate discussion that was had in the
work week. I'm responsible for taking that and turning it into a plan,
but I don't have it ready yet. I'll try to do this either later this
week or next week, and post back.

> Given your stance that this proposal does not reflect a policy change,
> I also don't understand how to give further feedback here.  Every
> change I suggest will be answered with "that's not in scope of this
> discussion" or "that's not how we do things", right?

There are plenty of suggestions that have been given that I've thought
are good ideas and will be included as part of the policy. That in
general this is not a policy change doesn't mean that policy changes
won't be considered or accepted. I'm just saying that the main purpose
here is to formalize what we've already been doing.

What I want to focus this discussion on is the "what" we police, rather
than the "how" we enforce it. You can see this in the policy itself,
where the enforcement section is just a couple of paragraphs explaining
what we already do. This policy is a way for us to tell developers what
we expect from them, so I do think that whatever process we use to
determine whether there's a violation, and which actions are taken
depending on severity belong to a separate discussion.

> If you're not proposing that we take a hard look at our current policy
> and consider whether it's the best way to protect our users, and if
> you're not proposing that others be involved in the decision-making
> process (with respect both to the policy itself and to the decisions
> the policy asks us to make), then I propose that we convene a working
> group to consider actual policy changes.  And I propose that this
> working group be composed of people from across the community, not
> just from the add-ons team, since it's clear that these problems
> affect us all.

Well, this isn't the discussion you were looking for. This is about the
developer-facing side of things, not the internal process that you think
is so obscure.

> If your stance is that there are no decisions to be made here save how
> to formalize an existing process, then I don't understand what you'd
> like feedback on, since you're unquestionably the expert on how the
> existing process works.

Re: Draft: Add-on Policies Justin Lebar 7/3/12 6:19 AM
>> What I mean is, what group of people decides which of these policy
>> changes proposed here to enact?  Is this entirely your decision?
>
> The idea here is to get feedback from incrementally bigger groups of people.
> Once we're done with this discussion we'll make a new draft and publish it
> in the blog, so we can get feedback from from add-on developers and add-on
> users. Once we're done with that, I think we'll be ready to call the policy
> finished.

So to be clear, this is entirely your decision?  People can give you
feedback here, and you'll listen to that and make changes to the
policy as you see appropriate, correct?
Re: Draft: Add-on Policies Jorge Villalobos 7/3/12 6:28 AM
The Add-ons Team make the final policy decisions, yes.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/3/12 6:28 AM
On 7/3/12 7:19 AM, Justin Lebar wrote:
Re: Draft: Add-on Policies Kris Maglione 7/3/12 8:34 AM
On Monday, July 2, 2012 12:12:11 PM UTC-4, Justin Lebar wrote:
>>There's a separate point in the policy covering this. Unless I'm
>>mistaken, if an add-on makes all pref changes in the default prefs
>>file, when the add-on is disabled the preferences are set back to
>>their previous value.
>
>I believe you are mistaken.  As far as I can tell, we have no way
>to tell whether a pref change came from FF chrome or from an
>add-on. Without that mechanism, we have no way to direct the pref
>change to an "add-on-specific" prefs file.  And without that, we
>have no way to roll back all of an add-on's pref changes once the
>add-on is disabled.

If an add-on makes changes to the default preference branch, those
changes are reset when Firefox is restarted, and if the add-on is no
longer there to make them at startup, they revert to their original
default values. For the common case of non-restartless add-ons that
make such changes via pref() rather than user_pref() statements in
defaults/preferences/*.js files, this is correct. For those that
make user pref changes at runtime or via user_pref() statments, it's
not.

Re: Draft: Add-on Policies Kris Maglione 7/3/12 8:34 AM
On Monday, July 2, 2012 12:12:11 PM UTC-4, Justin Lebar wrote:
>>There's a separate point in the policy covering this. Unless I'm
>>mistaken, if an add-on makes all pref changes in the default prefs
>>file, when the add-on is disabled the preferences are set back to
>>their previous value.
>
>I believe you are mistaken.  As far as I can tell, we have no way
>to tell whether a pref change came from FF chrome or from an
>add-on. Without that mechanism, we have no way to direct the pref
>change to an "add-on-specific" prefs file.  And without that, we
>have no way to roll back all of an add-on's pref changes once the
>add-on is disabled.

Re: Draft: Add-on Policies Mook 7/5/12 11:34 PM
On 7/2/2012 8:06 AM, Jorge Villalobos wrote:
> On 6/30/12 12:29 AM, Mook wrote:

 > At this point I realize that you're taking this way too literally ;).
 > This is a series of guidelines, not a legal document or a program. Yes,
 > you'll still be allowed to create add-ons that have the potential to
 > hang or even crash in some cases due to user input.
 >

(Moving stuff around again... XD )

Yep, that's because in the past where I _wasn't_ overly literal and pipe
up, thing got implemented in the strictest way possible; when we hit
problems later on, the response was basically "you didn't mention it
during discussion, too bad" :(

In general, given how much the add-ons team has tried to avoid enforcing
blocklisting, if this is just meant to be a formalization of current
policies it'll will probably be fine.

(Snipped stuff on the assumption that blocklisting will forever remain a
last resort)

>> "Application configuration changes" also means you can't
>> uninstall/reinstall an addon as a troubleshooting step; Firefox
>> currently doesn't remove its own profile when uninstalled either. (I
>> don't know if Firefox resets the system default browser on uninstall.)
>> I'd also be annoyed if, say, the locale changer changed things back on
>> uninstall, even if I just forgot about it for a year.
>
> I think most users expect that when they remove an add-on, all of its
> effects on their Firefox are reverted. Why would you uninstall it
> otherwise?

Prefs in extensions.foobar.* branches (as in, setCharPref, not default
prefs) are left behind; I believe having those remain is sensible, for
example, IRC network settings / nicknames for Chatzilla.  (They wouldn't
have an effect on Firefox until the add-on is installed again, other
than minutely slowing startup / shutdown / memory because prefs are
all-or-nothing.)  As for why you would uninstall it - for the same
reason a "Reset Nightly" option exists in about:support - people
uninstall Firefox and reinstall it in the hopes of solving problems, or
turning the computer off and back on.  It's (effective or not) often one
of the early steps of troubleshooting.

If you actually meant "add-ons should attempt to revert their effects on
Firefox and the system overall when disabled or uninstalled", that I
would agree.  (Should, because if the user set their desktop wallpaper
through an explicit action or something, that probably shouldn't get
reverted.)  I'm guessing you were actually thinking of search engines,
keyword.URL, and things of that nature?  (The typical monetization points)

>> In general, my stance is that users should be allowed to shoot their
>> feet if they know they're doing it; I suspect others don't agree, though.
>
> Very few users know they're shooting their feet, though.
>
Right; I think things that try to label their foot-shootiness should get
more leeway than things that don't make it clear to their users.
Venkman is pretty foot-shooty for me (buggy, and nobody has enough
cycles to fix it up), but on the balance I find it to be worthwhile
enough that I keep it around as an option, just avoid invoking it when I
don't need to.

--
Mook
Re: Draft: Add-on Policies Blair McBride 7/6/12 12:46 AM


On 4/07/2012 12:45 a.m., Gavin Sharp wrote:
> On Mon, Jul 2, 2012 at 12:12 PM, Justin Lebar <justin...@gmail.com> wrote:
>> I believe you are mistaken.  As far as I can tell, we have no way to
>> tell whether a pref change came from FF chrome or from an add-on.
>> Without that mechanism, we have no way to direct the pref change to an
>> "add-on-specific" prefs file.  And without that, we have no way to
>> roll back all of an add-on's pref changes once the add-on is disabled.
>
> Jorge was referring to add-ons that ship a defaults pref file to make
> their pref changes (as opposed to making them programmatically). In
> those cases, the behavior is as he describes (prefs effectively get
> "reset" when the add-on is disabled/uninstalled, since the default
> prefs from that bundle aren't loaded). Not all add-ons make use of
> this mechanism, and not all of them can - it doesn't allow you to
> change values dynamically, for example.

This only applies to non-restartless add-ons, however (bug 564675).

- Blair
Re: Draft: Add-on Policies Cheng Wang 7/10/12 9:10 PM
Top level post because following threads is messy.

Jorge Villalobos wrote:
> Hello,
>
> The Add-ons Team is working on creating a general add-on policy that
> applies to both AMO and non-AMO add-ons. This will allow us to
> articulate what we expect from all add-on developers, and to make
> clearer what kind of behavior will not be tolerated.
>
> We'd like to get your feedback on the current draft, included below. My
> idea is to keep it short and concise, and to add a link in each section
> pointing to more detailed documentation explaining what's acceptable or
> unacceptable in the different areas.
>
> ** Mozilla Add-on Policies (Draft) **
>
> * Be Transparent *
>
> * Add-ons must not be installed without user approval.

I like the sentiment but I think a little more clarity here would be good.

> * 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 always be possible to uninstall or disable from the
> Add-ons Manager.
> * Add-ons should clearly communicate their intended purpose and active
> features.

I'd like to add: Add-ons must not interfere with, modify or change any
of the add-on manager UI, dialogs, warnings or access points; hide
themselves from the add-ons manager; or otherwise be non-obvious that
they're installed. (Yes, this happens and please fix my wording --
perhaps add modify the blocklist as a no-no).

Also related, a restriction on affecting core Firefox functionality
(like removing the location bar and replacing it with theirs) or
breaking tabs.

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

Perhaps a little clarity here?

> * Add-ons should make it clear how private user information is being used.
> * Add-on developers should provide a support channel for their users.

I know this is contentious but I don't think it's unreasonable to ask
developers to be upfront about their support or lack thereof. Perhaps a
better phrasing is that add-ons must have a clear support policy
(including expected response times): if they say "email
x...@add-ondev.com for support and I'll answer in a week", they should
actually answer. I think clearly opting out of supporting users is fine,
too -- but we should maybe have a guideline that we don't recommend
add-ons that offer no support or something like that.

I'd also like some policy point on updating add-ons. Developers should
either commit to updating or be OK with having their add-ons deprecated
if any of the APIs used have changed/deprecated.  And it has to be in a
reasonable amount of time... not 5 weeks after GA release.

>
> * Be Safe *
>
> * Add-ons must not cause harm to the user's online identities, data or
> system.

I'd clarify this a little.

> * Add-ons must not expose or unsafely transmit the user's private data.

Perhaps "without consent"? Or some text about having a reasonable
privacy policy in instances where they do this? (I know this is above,
so perhaps it's already covered...)

> * Add-ons must not create or expose application or system vulnerabilities.

Do plugins count as add-ons in this case?

>
> * Be Fast *
>
> * Add-ons must not cause hangs or crashes.
> * Add-ons should not consume excessive amounts of memory or cause memory
> leaks.
> * Add-ons should not slow the application down significantly.

Maybe more clarity here? Mention CPU usage or something like that. Also,
possibly add a comment about not hogging network resources.

>
> * Enforcement *
>
> If an add-on breaks any of the /must/ guidelines or many of the /should/
> guidelines, it qualifies for blocklisting (remote disabling).

I think we should be stricter. Add-ons that break any of these
guidelines qualify for blocklisting or other corrective actions
(including legal action if warranted?). The action taken, if any, will
be at the discretion of _______.


>
> Per blocklisting policy, 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 think the bar for immediate action shouldn't be "malicious" which
implies negative intent but instead "excessively damaging" or something
like that. An accidental code change that crashes Firefox on startup
isn't malicious but it's immediate blocklist-worthy.

>
> Exceptions to these policies include add-ons with the intended purpose
> of breaking them with non-malicious intent. For example, security
> exploit proofs of concept.
>
> Jorge


Overall, my other feedback is that while these are great for the current
state of Firefox, I'd actually like to see the policy be more
forward-aware. If we're going to be changing APIs to restrict what
add-ons do, we should explicitly put that here: Add-ons should aim to
use explicit Firefox APIs and not code around them to bypass
user-warnings or other restrictions, something like that.  If we're
going to add more levels of blocklisting/warning, we should mention that
other corrective action may be taken and the options may change.

Also, we probably need to implement a mechanism for users/community
members to report violations to us.  Bugzilla may do for now but it's
not very user-friendly.

Cheng.

Re: Draft: Add-on Policies Jorge Villalobos 7/11/12 9:28 AM
>> * Add-ons must not be installed without user approval.
>
> I like the sentiment but I think a little more clarity here would be good.

Ok.

>> * Add-ons should clearly communicate their intended purpose and active
>> features.
>
> I'd like to add: Add-ons must not interfere with, modify or change any
> of the add-on manager UI, dialogs, warnings or access points;

I don't think we should require this. Add-ons are allowed to do this
currently, and the only add-on I know that messed up the Add-ons Manager
badly was Personas Plus (irony!).

> hide
> themselves from the add-ons manager; or otherwise be non-obvious that
> they're installed. (Yes, this happens and please fix my wording --
> perhaps add modify the blocklist as a no-no).

This is covered in the "all add-ons should be possible to uninstall from
the AOM" policy.

> Also related, a restriction on affecting core Firefox functionality
> (like removing the location bar and replacing it with theirs) or
> breaking tabs.

If that's the add-on's purpose and it is communicated clearly, I don't
think it should be disallowed. Breaking core features to the point
they're unusable is certainly missing from this policy. I'll add it.

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

Do you mean examples, or is something else missing?

> I'd also like some policy point on updating add-ons. Developers should
> either commit to updating or be OK with having their add-ons deprecated
> if any of the APIs used have changed/deprecated. And it has to be in a
> reasonable amount of time... not 5 weeks after GA release.

I think all other policies have this covered. If an add-on breaks in the
latest Firefox, the extent of its breakage should be evaluated based on
our policies and then we'll decide what to do about it. We can either
mark it as incompatible or block it in extreme cases. We already do this
based mostly on the feedback we get from users through the Add-on
Compatibility reporter.


>> * Add-ons must not expose or unsafely transmit the user's private data.
>
> Perhaps "without consent"? Or some text about having a reasonable
> privacy policy in instances where they do this? (I know this is above,
> so perhaps it's already covered...)

There's an exceptions section at the bottom that I think I will expand,
to make it clear that there are cases where it is obvious what the
add-on is doing and it can be exempt from the rules. I'd like to keep
the policy concise and not turn it into an exhaustive listing of what
can or can't be done.

>> * Add-ons must not create or expose application or system
>> vulnerabilities.
>
> Do plugins count as add-ons in this case?

Yes. This applies to all add-on types.

>> * Add-ons should not slow the application down significantly.
>
> Maybe more clarity here? Mention CPU usage or something like that. Also,
> possibly add a comment about not hogging network resources.

Is hogging the network a common add-on problem? Can you give me some
examples?

>> If an add-on breaks any of the /must/ guidelines or many of the /should/
>> guidelines, it qualifies for blocklisting (remote disabling).
>
> I think we should be stricter. Add-ons that break any of these
> guidelines qualify for blocklisting or other corrective actions
> (including legal action if warranted?). The action taken, if any, will
> be at the discretion of _______.

I don't think legal action has ever been considered, and I would find
that too threatening to be productive. Making it clear who is
responsible for these enforcement calls is a good idea.

> I think the bar for immediate action shouldn't be "malicious" which
> implies negative intent but instead "excessively damaging" or something
> like that. An accidental code change that crashes Firefox on startup
> isn't malicious but it's immediate blocklist-worthy.

Even in the case of startup crashes we make some effort to contact the
developers before we blocklist. We've only immediately blocklisted
add-ons that are malicious in nature.

All potential blocklist cases are handled immediately, though, and we
try to have them resolved as soon as possible. Perhaps that's what's
missing there.

> Overall, my other feedback is that while these are great for the current
> state of Firefox, I'd actually like to see the policy be more
> forward-aware. If we're going to be changing APIs to restrict what
> add-ons do, we should explicitly put that here: Add-ons should aim to
> use explicit Firefox APIs and not code around them to bypass
> user-warnings or other restrictions, something like that. If we're going
> to add more levels of blocklisting/warning, we should mention that other
> corrective action may be taken and the options may change.

Neither of these things are happening in the near future, probably not
even this year, so I think we should revisit the policies once they
require updating. I think it would be confusing to mention things that
*might* happen in the long term.


> Also, we probably need to implement a mechanism for users/community
> members to report violations to us. Bugzilla may do for now but it's not
> very user-friendly.

We have Abuse reports for AMO add-ons, but we don't have a good
reporting tool for their non-AMO relatives. This is another thing we
discussed in the work week and there were a couple of ideas on how to
address this. I really need to put these ideas in order and post back
soon. Sorry for the delay!

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/11/12 9:28 AM
>> * Add-ons must not be installed without user approval.
>
> I like the sentiment but I think a little more clarity here would be good.

Ok.

>> * Add-ons should clearly communicate their intended purpose and active
>> features.
>
> I'd like to add: Add-ons must not interfere with, modify or change any
> of the add-on manager UI, dialogs, warnings or access points;

I don't think we should require this. Add-ons are allowed to do this
currently, and the only add-on I know that messed up the Add-ons Manager
badly was Personas Plus (irony!).

> hide
> themselves from the add-ons manager; or otherwise be non-obvious that
> they're installed. (Yes, this happens and please fix my wording --
> perhaps add modify the blocklist as a no-no).

This is covered in the "all add-ons should be possible to uninstall from
the AOM" policy.

> Also related, a restriction on affecting core Firefox functionality
> (like removing the location bar and replacing it with theirs) or
> breaking tabs.

If that's the add-on's purpose and it is communicated clearly, I don't
think it should be disallowed. Breaking core features to the point
they're unusable is certainly missing from this policy. I'll add it.

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

Do you mean examples, or is something else missing?

> I'd also like some policy point on updating add-ons. Developers should
> either commit to updating or be OK with having their add-ons deprecated
> if any of the APIs used have changed/deprecated. And it has to be in a
> reasonable amount of time... not 5 weeks after GA release.

I think all other policies have this covered. If an add-on breaks in the
latest Firefox, the extent of its breakage should be evaluated based on
our policies and then we'll decide what to do about it. We can either
mark it as incompatible or block it in extreme cases. We already do this
based mostly on the feedback we get from users through the Add-on
Compatibility reporter.


>> * Add-ons must not expose or unsafely transmit the user's private data.
>
> Perhaps "without consent"? Or some text about having a reasonable
> privacy policy in instances where they do this? (I know this is above,
> so perhaps it's already covered...)

There's an exceptions section at the bottom that I think I will expand,
to make it clear that there are cases where it is obvious what the
add-on is doing and it can be exempt from the rules. I'd like to keep
the policy concise and not turn it into an exhaustive listing of what
can or can't be done.

>> * Add-ons must not create or expose application or system
>> vulnerabilities.
>
> Do plugins count as add-ons in this case?

Yes. This applies to all add-on types.

>> * Add-ons should not slow the application down significantly.
>
> Maybe more clarity here? Mention CPU usage or something like that. Also,
> possibly add a comment about not hogging network resources.

Is hogging the network a common add-on problem? Can you give me some
examples?

>> If an add-on breaks any of the /must/ guidelines or many of the /should/
>> guidelines, it qualifies for blocklisting (remote disabling).
>
> I think we should be stricter. Add-ons that break any of these
> guidelines qualify for blocklisting or other corrective actions
> (including legal action if warranted?). The action taken, if any, will
> be at the discretion of _______.

I don't think legal action has ever been considered, and I would find
that too threatening to be productive. Making it clear who is
responsible for these enforcement calls is a good idea.

> I think the bar for immediate action shouldn't be "malicious" which
> implies negative intent but instead "excessively damaging" or something
> like that. An accidental code change that crashes Firefox on startup
> isn't malicious but it's immediate blocklist-worthy.

Even in the case of startup crashes we make some effort to contact the
developers before we blocklist. We've only immediately blocklisted
add-ons that are malicious in nature.

All potential blocklist cases are handled immediately, though, and we
try to have them resolved as soon as possible. Perhaps that's what's
missing there.

> Overall, my other feedback is that while these are great for the current
> state of Firefox, I'd actually like to see the policy be more
> forward-aware. If we're going to be changing APIs to restrict what
> add-ons do, we should explicitly put that here: Add-ons should aim to
> use explicit Firefox APIs and not code around them to bypass
> user-warnings or other restrictions, something like that. If we're going
> to add more levels of blocklisting/warning, we should mention that other
> corrective action may be taken and the options may change.

Neither of these things are happening in the near future, probably not
even this year, so I think we should revisit the policies once they
require updating. I think it would be confusing to mention things that
*might* happen in the long term.


> Also, we probably need to implement a mechanism for users/community
> members to report violations to us. Bugzilla may do for now but it's not
> very user-friendly.

Re: Draft: Add-on Policies gro...@gmail.com 7/11/12 10:08 AM
This looks excellent. A great move in the right direction.

One simple comment:

> &gt;&gt; * Add-ons should not disrespect the user&#39;s choices by making unexpected
> &gt;&gt; changes or limiting the user&#39;s ability to revert them.
> &gt;
> &gt; Perhaps a little clarity here?
>
> Do you mean examples, or is something else missing?

I'm not sure if Cheng meant this but my read is that we need to remove the grey areas. Policies need to be crystal clear and not open to interpretations.

Some of the points require sharper definitions, with actual numbers or description of what is the bar. A definition from a diferent context: Nudity is disallowed, where nudity means no nipples can be visible. We need something similar for each of this to avoid open interpretations.

Best,
Ibai

On Wednesday, July 11, 2012 9:28:00 AM UTC-7, Jorge Villalobos wrote:
> &gt;&gt; * Add-ons must not be installed without user approval.
> &gt;
> &gt; I like the sentiment but I think a little more clarity here would be good.
>
> Ok.
>
> &gt;&gt; * Add-ons should clearly communicate their intended purpose and active
> &gt;&gt; features.
> &gt;
> &gt; I&#39;d like to add: Add-ons must not interfere with, modify or change any
> &gt; of the add-on manager UI, dialogs, warnings or access points;
>
> I don&#39;t think we should require this. Add-ons are allowed to do this
> currently, and the only add-on I know that messed up the Add-ons Manager
> badly was Personas Plus (irony!).
>
> &gt; hide
> &gt; themselves from the add-ons manager; or otherwise be non-obvious that
> &gt; they&#39;re installed. (Yes, this happens and please fix my wording --
> &gt; perhaps add modify the blocklist as a no-no).
>
> This is covered in the &quot;all add-ons should be possible to uninstall from
> the AOM&quot; policy.
>
> &gt; Also related, a restriction on affecting core Firefox functionality
> &gt; (like removing the location bar and replacing it with theirs) or
> &gt; breaking tabs.
>
> If that&#39;s the add-on&#39;s purpose and it is communicated clearly, I don&#39;t
> think it should be disallowed. Breaking core features to the point
> they&#39;re unusable is certainly missing from this policy. I&#39;ll add it.
>

>
> &gt; I&#39;d also like some policy point on updating add-ons. Developers should
> &gt; either commit to updating or be OK with having their add-ons deprecated
> &gt; if any of the APIs used have changed/deprecated. And it has to be in a
> &gt; reasonable amount of time... not 5 weeks after GA release.
>
> I think all other policies have this covered. If an add-on breaks in the
> latest Firefox, the extent of its breakage should be evaluated based on
> our policies and then we&#39;ll decide what to do about it. We can either
> mark it as incompatible or block it in extreme cases. We already do this
> based mostly on the feedback we get from users through the Add-on
> Compatibility reporter.
>
>
> &gt;&gt; * Add-ons must not expose or unsafely transmit the user&#39;s private data.
> &gt;
> &gt; Perhaps &quot;without consent&quot;? Or some text about having a reasonable
> &gt; privacy policy in instances where they do this? (I know this is above,
> &gt; so perhaps it&#39;s already covered...)
>
> There&#39;s an exceptions section at the bottom that I think I will expand,
> to make it clear that there are cases where it is obvious what the
> add-on is doing and it can be exempt from the rules. I&#39;d like to keep
> the policy concise and not turn it into an exhaustive listing of what
> can or can&#39;t be done.
>
> &gt;&gt; * Add-ons must not create or expose application or system
> &gt;&gt; vulnerabilities.
> &gt;
> &gt; Do plugins count as add-ons in this case?
>
> Yes. This applies to all add-on types.
>
> &gt;&gt; * Add-ons should not slow the application down significantly.
> &gt;
> &gt; Maybe more clarity here? Mention CPU usage or something like that. Also,
> &gt; possibly add a comment about not hogging network resources.
>
> Is hogging the network a common add-on problem? Can you give me some
> examples?
>
> &gt;&gt; If an add-on breaks any of the /must/ guidelines or many of the /should/
> &gt;&gt; guidelines, it qualifies for blocklisting (remote disabling).
> &gt;
> &gt; I think we should be stricter. Add-ons that break any of these
> &gt; guidelines qualify for blocklisting or other corrective actions
> &gt; (including legal action if warranted?). The action taken, if any, will
> &gt; be at the discretion of _______.
>
> I don&#39;t think legal action has ever been considered, and I would find
> that too threatening to be productive. Making it clear who is
> responsible for these enforcement calls is a good idea.
>
> &gt; I think the bar for immediate action shouldn&#39;t be &quot;malicious&quot; which
> &gt; implies negative intent but instead &quot;excessively damaging&quot; or something
> &gt; like that. An accidental code change that crashes Firefox on startup
> &gt; isn&#39;t malicious but it&#39;s immediate blocklist-worthy.
>
> Even in the case of startup crashes we make some effort to contact the
> developers before we blocklist. We&#39;ve only immediately blocklisted
> add-ons that are malicious in nature.
>
> All potential blocklist cases are handled immediately, though, and we
> try to have them resolved as soon as possible. Perhaps that&#39;s what&#39;s
> missing there.
>
> &gt; Overall, my other feedback is that while these are great for the current
> &gt; state of Firefox, I&#39;d actually like to see the policy be more
> &gt; forward-aware. If we&#39;re going to be changing APIs to restrict what
> &gt; add-ons do, we should explicitly put that here: Add-ons should aim to
> &gt; use explicit Firefox APIs and not code around them to bypass
> &gt; user-warnings or other restrictions, something like that. If we&#39;re going
> &gt; to add more levels of blocklisting/warning, we should mention that other
> &gt; corrective action may be taken and the options may change.
>
> Neither of these things are happening in the near future, probably not
> even this year, so I think we should revisit the policies once they
> require updating. I think it would be confusing to mention things that
> *might* happen in the long term.
>
>
> &gt; Also, we probably need to implement a mechanism for users/community
> &gt; members to report violations to us. Bugzilla may do for now but it&#39;s not
> &gt; very user-friendly.
>
> We have Abuse reports for AMO add-ons, but we don&#39;t have a good
Re: Draft: Add-on Policies gro...@gmail.com 7/11/12 10:08 AM
This looks excellent. A great move in the right direction.

One simple comment:

> &gt;&gt; * Add-ons should not disrespect the user&#39;s choices by making unexpected
> &gt;&gt; changes or limiting the user&#39;s ability to revert them.
> &gt;
> &gt; Perhaps a little clarity here?
>
> Do you mean examples, or is something else missing?

I'm not sure if Cheng meant this but my read is that we need to remove the grey areas. Policies need to be crystal clear and not open to interpretations.

Some of the points require sharper definitions, with actual numbers or description of what is the bar. A definition from a diferent context: Nudity is disallowed, where nudity means no nipples can be visible. We need something similar for each of this to avoid open interpretations.

Best,
Ibai

On Wednesday, July 11, 2012 9:28:00 AM UTC-7, Jorge Villalobos wrote:
> &gt;&gt; * Add-ons must not be installed without user approval.
> &gt;
> &gt; I like the sentiment but I think a little more clarity here would be good.
>
> Ok.
>
> &gt;&gt; * Add-ons should clearly communicate their intended purpose and active
> &gt;&gt; features.
> &gt;
> &gt; I&#39;d like to add: Add-ons must not interfere with, modify or change any
> &gt; of the add-on manager UI, dialogs, warnings or access points;
>
> I don&#39;t think we should require this. Add-ons are allowed to do this
> currently, and the only add-on I know that messed up the Add-ons Manager
> badly was Personas Plus (irony!).
>
> &gt; hide
> &gt; themselves from the add-ons manager; or otherwise be non-obvious that
> &gt; they&#39;re installed. (Yes, this happens and please fix my wording --
> &gt; perhaps add modify the blocklist as a no-no).
>
> This is covered in the &quot;all add-ons should be possible to uninstall from
> the AOM&quot; policy.
>
> &gt; Also related, a restriction on affecting core Firefox functionality
> &gt; (like removing the location bar and replacing it with theirs) or
> &gt; breaking tabs.
>
> If that&#39;s the add-on&#39;s purpose and it is communicated clearly, I don&#39;t
> think it should be disallowed. Breaking core features to the point
> they&#39;re unusable is certainly missing from this policy. I&#39;ll add it.
>

>
> &gt; I&#39;d also like some policy point on updating add-ons. Developers should
> &gt; either commit to updating or be OK with having their add-ons deprecated
> &gt; if any of the APIs used have changed/deprecated. And it has to be in a
> &gt; reasonable amount of time... not 5 weeks after GA release.
>
> I think all other policies have this covered. If an add-on breaks in the
> latest Firefox, the extent of its breakage should be evaluated based on
> our policies and then we&#39;ll decide what to do about it. We can either
> mark it as incompatible or block it in extreme cases. We already do this
> based mostly on the feedback we get from users through the Add-on
> Compatibility reporter.
>
>
> &gt;&gt; * Add-ons must not expose or unsafely transmit the user&#39;s private data.
> &gt;
> &gt; Perhaps &quot;without consent&quot;? Or some text about having a reasonable
> &gt; privacy policy in instances where they do this? (I know this is above,
> &gt; so perhaps it&#39;s already covered...)
>
> There&#39;s an exceptions section at the bottom that I think I will expand,
> to make it clear that there are cases where it is obvious what the
> add-on is doing and it can be exempt from the rules. I&#39;d like to keep
> the policy concise and not turn it into an exhaustive listing of what
> can or can&#39;t be done.
>
> &gt;&gt; * Add-ons must not create or expose application or system
> &gt;&gt; vulnerabilities.
> &gt;
> &gt; Do plugins count as add-ons in this case?
>
> Yes. This applies to all add-on types.
>
> &gt;&gt; * Add-ons should not slow the application down significantly.
> &gt;
> &gt; Maybe more clarity here? Mention CPU usage or something like that. Also,
> &gt; possibly add a comment about not hogging network resources.
>
> Is hogging the network a common add-on problem? Can you give me some
> examples?
>
> &gt;&gt; If an add-on breaks any of the /must/ guidelines or many of the /should/
> &gt;&gt; guidelines, it qualifies for blocklisting (remote disabling).
> &gt;
> &gt; I think we should be stricter. Add-ons that break any of these
> &gt; guidelines qualify for blocklisting or other corrective actions
> &gt; (including legal action if warranted?). The action taken, if any, will
> &gt; be at the discretion of _______.
>
> I don&#39;t think legal action has ever been considered, and I would find
> that too threatening to be productive. Making it clear who is
> responsible for these enforcement calls is a good idea.
>
> &gt; I think the bar for immediate action shouldn&#39;t be &quot;malicious&quot; which
> &gt; implies negative intent but instead &quot;excessively damaging&quot; or something
> &gt; like that. An accidental code change that crashes Firefox on startup
> &gt; isn&#39;t malicious but it&#39;s immediate blocklist-worthy.
>
> Even in the case of startup crashes we make some effort to contact the
> developers before we blocklist. We&#39;ve only immediately blocklisted
> add-ons that are malicious in nature.
>
> All potential blocklist cases are handled immediately, though, and we
> try to have them resolved as soon as possible. Perhaps that&#39;s what&#39;s
> missing there.
>
> &gt; Overall, my other feedback is that while these are great for the current
> &gt; state of Firefox, I&#39;d actually like to see the policy be more
> &gt; forward-aware. If we&#39;re going to be changing APIs to restrict what
> &gt; add-ons do, we should explicitly put that here: Add-ons should aim to
> &gt; use explicit Firefox APIs and not code around them to bypass
> &gt; user-warnings or other restrictions, something like that. If we&#39;re going
> &gt; to add more levels of blocklisting/warning, we should mention that other
> &gt; corrective action may be taken and the options may change.
>
> Neither of these things are happening in the near future, probably not
> even this year, so I think we should revisit the policies once they
> require updating. I think it would be confusing to mention things that
> *might* happen in the long term.
>
>
> &gt; Also, we probably need to implement a mechanism for users/community
> &gt; members to report violations to us. Bugzilla may do for now but it&#39;s not
> &gt; very user-friendly.
>
> We have Abuse reports for AMO add-ons, but we don&#39;t have a good
Re: Draft: Add-on Policies Michael Verdi 7/11/12 11:06 AM
On Monday, July 2, 2012 10:31:55 AM UTC-5, Jorge Villalobos wrote:
> On 7/2/12 5:31 AM, Justin Lebar wrote:
> &gt; I&#39;d like to understand the structure for making decisions about this policy.
> &gt; Who specifically is involved in the final decision-making process?  I&#39;d like to
> &gt; make sure in particular that the platform group is represented among the
> &gt; deciders here, as there can be no doubt that this policy affects the stability
> &gt; and performance of our platform.
>
> I&#39;m not proposing any alternatives to the way things currently work,
> which is that anyone can bring up policy violations and it is up to the
> Add-ons Team to contact the developers and determine whether to
> blocklist or take other actions. For more problematic cases (crashes,
> widespread malware) the release drivers team would need to be in the
> loop as well. If you want to discuss alternatives to this process, I
> think we should start a different thread for it.
>

>
> &gt; I guess my question is about the amount of time we&#39;re willing to wait for a
> &gt; fix.  To be concrete: We waited two months for McAfee to ship a full leak fix
> &gt; to users.
> &gt;
> &gt; Suppose things had gone as they did: McAfee shipped an improved version three
> &gt; weeks after we notified them, but the add-on still leaked far beyond acceptable
> &gt; levels.  Would we have taken action at that point?
> &gt;
> &gt; In general: In order to evaluate this proposed policy, I&#39;d like to understand
> &gt; how we would have acted differently in this and other similar cases we&#39;ve
> &gt; encountered in the past.
>
> I don&#39;t consider this to be a change in our policy, but more a
> formalization of the unwritten policy that we already have. There are a
> couple of new things in this one for sure, but the enforcement part is
> pretty much the same. We will always reach out to the developers,
> evaluate the severity of the problem, and determine how long should we
> wait for a fix and whether blocklisting should be considered or not.
> These things take time, but we believe it&#39;s the best way to get these
> problems resolved.
>

I'm pretty late to this discussion and at over a hundred messages I'm sure I've missed something. I have a few questions mainly revolving around how this policy would be different from our current policy.
Maybe we can look at some particular cases.


Would it still be ok for add-ons to be bundled with third party software on an opt-out basis?

Would it still be ok for add-ons to include opt-out Firefox preference changes (home page, search engine, etc.) in third party installation dialogs.

Would it still be ok for the Ask toolbar to overlay a graphic on the add-ons manager window?

Would it still be ok for the Babylon toolbar to not be fully disabled when you disable the extensions?

Would it still be ok if you disable extensions like Babylon or Ask for the preference changes like home page and search (all of them) to not be reverted?

More than crashy or memory hogging add-ons, we see more problems caused by add-ons that people don't know they've installed and don't know how to revert the changes they've made to Firefox.

unk...@googlegroups.com 7/11/12 11:06 AM <This message has been deleted.>
unk...@googlegroups.com 7/11/12 11:32 AM <This message has been deleted.>
unk...@googlegroups.com 7/11/12 11:32 AM <This message has been deleted.>
Re: Draft: Add-on Policies Justin Dolske 7/11/12 1:01 PM
On 7/11/12 9:28 AM, Jorge Villalobos wrote:

>>> * Add-ons should clearly communicate their intended purpose and active
>>> features.
>>
>> I'd like to add: Add-ons must not interfere with, modify or change any
>> of the add-on manager UI, dialogs, warnings or access points;
>
> I don't think we should require this. Add-ons are allowed to do this
> currently, and the only add-on I know that messed up the Add-ons Manager
> badly was Personas Plus (irony!).

Did the "no surprises" rule get dropped somewhere along the way?

I was going to say that between "clearly communicate purpose" and "no
surprises", the vast majority of potential abuses/wtfs would already be
covered. Thought I suppose "clearly communicate" is just a narrower
version that isn't as ambiguous.

Actually, a few sentences setting up the general reasoning / context
that lead to overall policy would help in that respect... Not sure of
the wording, but the basic idea is that the specific rules are to help
guide understanding, and are not a complete embodiment of every specific
edge case. E.G., an addon could be rejected for not being "respectful to
users" even if it manages to weasel its way to passing the 4
"respectful" bullet points.

Justin
Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 9:02 AM
On 7/11/12 12:32 PM, Michael Verdi wrote:
> I'm pretty late to this discussion and at over a hundred messages I'm sure I've missed something. I have a few questions mainly revolving around how this policy would be different from our current policy.
> Maybe we can look at some particular cases.
>
>
> Would it still be ok for add-ons to be bundled with third party software on an opt-out basis?

Yes. Our requirement is that users must approve of the add-on install,
and the third-party opt-in screen is considered user approval. Whether
this screen should be improved to make the decision clearer to users is
a separate discussion.

If the software somehow bypassed this screen and didn't give users a way
to approve add-on installation, then that would be violating our policies.

> Would it still be ok for add-ons to include opt-out Firefox preference changes (home page, search engine, etc.) in third party installation dialogs.

As long as they are presented clearly, yes.

> Would it still be ok for the Ask toolbar to overlay a graphic on the add-ons manager window?

This violates a couple of the stated policies, and I am personally
opposed to this and anything like this. However, I know this was the
result of conversations between Ask and Mozilla and I wouldn't want to
step over Kev's authority on this matter. I think we can all agree that
this isn't allowed as a general rule. The Ask case in particular would
need to be discussed with Kev, though.

> Would it still be ok for the Babylon toolbar to not be fully disabled when you disable the extensions?
 >
> Would it still be ok if you disable extensions like Babylon or Ask for the preference changes like home page and search (all of them) to not be reverted?

There's a policy for that. Extensions should revert all changes when
disabled or removed.

> More than crashy or memory hogging add-ons, we see more problems caused by add-ons that people don't know they've installed and don't know how to revert the changes they've made to Firefox.

Yes, that's a big problem, and not one that can be fully solved, I
think. No matter how explicit we make add-on installation, there will
always be people that don't know/remember how they got a particular
extension or plugin. That's not to say there isn't anything we can do
about it. I've promised way too many times on this thread, but there's
more to come ;).

Jorge


Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 9:02 AM
Re: Draft: Add-on Policies Justin Lebar 7/12/12 9:59 AM
>> Would it still be ok if you disable extensions like Babylon or Ask for the
>> preference changes like home page and search (all of them) to not be
>> reverted?
>
> There's a policy for that. Extensions should revert all changes when disabled
> or removed.

Given that the overall proposal here doesn't reflect a change in
policy, am I correct in understanding that Babylon et al. are in
violation of our current policy as well?

Either way, would you mind detailing the plan, under the new/clarified
policy, for ensuring that Babylon et al. comply with our policy?
Specifically:

 * Do we have bugs open where we've informed them that they're in
violation of our policy, and have they responded?

 * What, in your mind, would be an acceptable timeframe for us to
expect Babylon (or whoever) to fix this issue?

 * After the issue is fixed (or after the timeframe elapses), will we
soft-block versions of the add-on which don't comply with our policy?

I'm not interested in arguing about what you should be doing with
respect to these questions; I ask only to better understand current
and planned procedures.
Re: Draft: Add-on Policies Michael Verdi 7/12/12 10:42 AM
On Thursday, July 12, 2012 11:59:57 AM UTC-5, Justin Lebar wrote:

>
> Given that the overall proposal here doesn&#39;t reflect a change in
> policy, am I correct in understanding that Babylon et al. are in
> violation of our current policy as well?
>
> Either way, would you mind detailing the plan, under the new/clarified
> policy, for ensuring that Babylon et al. comply with our policy?

I filed this bug back in January asking to block Babylon https://bugzilla.mozilla.org/show_bug.cgi?id=721264

At the time, Jorge said that it didn't meet the "High Bar" standard. He also said we had not been successful in contacting them.

Re: Draft: Add-on Policies Michael Verdi 7/12/12 10:42 AM
On Thursday, July 12, 2012 11:59:57 AM UTC-5, Justin Lebar wrote:

>
> Given that the overall proposal here doesn&#39;t reflect a change in
> policy, am I correct in understanding that Babylon et al. are in
> violation of our current policy as well?
>
> Either way, would you mind detailing the plan, under the new/clarified
> policy, for ensuring that Babylon et al. comply with our policy?

Re: Draft: Add-on Policies Michael Verdi 7/12/12 10:54 AM
On Thursday, July 12, 2012 11:02:53 AM UTC-5, Jorge Villalobos wrote:
> On 7/11/12 12:32 PM, Michael Verdi wrote:
> &gt; Would it still be ok for add-ons to be bundled with third party software on an opt-out basis?
>
> Yes. Our requirement is that users must approve of the add-on install,
> and the third-party opt-in screen is considered user approval. Whether
> this screen should be improved to make the decision clearer to users is
> a separate discussion.
>
> If the software somehow bypassed this screen and didn&#39;t give users a way
> to approve add-on installation, then that would be violating our policies.
>
> &gt; Would it still be ok for add-ons to include opt-out Firefox preference changes (home page, search engine, etc.) in third party installation dialogs.
>
> As long as they are presented clearly, yes.
>
>
> &gt; More than crashy or memory hogging add-ons, we see more problems caused by add-ons that people don&#39;t know they&#39;ve installed and don&#39;t know how to revert the changes they&#39;ve made to Firefox.
>
> Yes, that&#39;s a big problem, and not one that can be fully solved, I
> think. No matter how explicit we make add-on installation, there will
> always be people that don&#39;t know/remember how they got a particular
> extension or plugin. That&#39;s not to say there isn&#39;t anything we can do
> about it. I&#39;ve promised way too many times on this thread, but there&#39;s
> more to come ;).
>
> Jorge

These two things are huge ways add-on makers use social engineering to trick people into installing software they don't want and change Firefox settings that they don't want changed. I believe we are doing our uses a disservice by not taking a leadership position on this practice. Maybe blocking add-ons that engage in this will help change their behavior. Maybe this is an area we can work with Microsoft and Google on? Surly this is an issue for them also.

Re: Draft: Add-on Policies Michael Verdi 7/12/12 10:54 AM
On Thursday, July 12, 2012 11:02:53 AM UTC-5, Jorge Villalobos wrote:
> On 7/11/12 12:32 PM, Michael Verdi wrote:
> &gt; Would it still be ok for add-ons to be bundled with third party software on an opt-out basis?
>
> Yes. Our requirement is that users must approve of the add-on install,
> and the third-party opt-in screen is considered user approval. Whether
> this screen should be improved to make the decision clearer to users is
> a separate discussion.
>
> If the software somehow bypassed this screen and didn&#39;t give users a way
> to approve add-on installation, then that would be violating our policies.
>
> &gt; Would it still be ok for add-ons to include opt-out Firefox preference changes (home page, search engine, etc.) in third party installation dialogs.
>
> As long as they are presented clearly, yes.
>
>
> &gt; More than crashy or memory hogging add-ons, we see more problems caused by add-ons that people don&#39;t know they&#39;ve installed and don&#39;t know how to revert the changes they&#39;ve made to Firefox.
>
> Yes, that&#39;s a big problem, and not one that can be fully solved, I
> think. No matter how explicit we make add-on installation, there will
> always be people that don&#39;t know/remember how they got a particular
> extension or plugin. That&#39;s not to say there isn&#39;t anything we can do
> about it. I&#39;ve promised way too many times on this thread, but there&#39;s
> more to come ;).
>
> Jorge

Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 10:55 AM
On 7/12/12 10:59 AM, Justin Lebar wrote:
>>> Would it still be ok if you disable extensions like Babylon or Ask for the
>>> preference changes like home page and search (all of them) to not be
>>> reverted?
>>
>> There's a policy for that. Extensions should revert all changes when disabled
>> or removed.
>
> Given that the overall proposal here doesn't reflect a change in
> policy, am I correct in understanding that Babylon et al. are in
> violation of our current policy as well?

If they're changing settings and not changing them back after uninstall,
yes. Though they're probably unaware of this. One of the purposes of
this policy is to have somewhere to point all developers to.

>
> Either way, would you mind detailing the plan, under the new/clarified
> policy, for ensuring that Babylon et al. comply with our policy?
> Specifically:
>
>   * Do we have bugs open where we've informed them that they're in
> violation of our policy, and have they responded?

As Michael pointed out, bug 721264 was filed some time ago as a
blocklist bug, and there were 2 problems with it. First, it doesn't meet
the blocklist standard (it still doesn't). And second, we didn't have a
way to get in touch with Babylon.

We now have direct communication with Babylon and they have been very
responsive. We have been talking to them about other issues, mostly
crashes, and to be honest I had forgotten about bug 721264.

Michael, can you test the latest version and let us know which
preferences are not reset after uninstall? Then file a bug in Tech
Evangelism > Add-ons, or morph bug 721264 into that? I'll get in touch
with Babylon about this.

>   * What, in your mind, would be an acceptable timeframe for us to
> expect Babylon (or whoever) to fix this issue?

For other issues they have taken a week or so, but they were more
critical. If they can get this fixed within a month, I would think
that's ok.

>   * After the issue is fixed (or after the timeframe elapses), will we
> soft-block versions of the add-on which don't comply with our policy?

No, I don't think this is serious enough.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 10:55 AM
On 7/12/12 10:59 AM, Justin Lebar wrote:
>>> Would it still be ok if you disable extensions like Babylon or Ask for the
>>> preference changes like home page and search (all of them) to not be
>>> reverted?
>>
>> There's a policy for that. Extensions should revert all changes when disabled
>> or removed.
>
> Given that the overall proposal here doesn't reflect a change in
> policy, am I correct in understanding that Babylon et al. are in
> violation of our current policy as well?

If they're changing settings and not changing them back after uninstall,
yes. Though they're probably unaware of this. One of the purposes of
this policy is to have somewhere to point all developers to.

>
> Either way, would you mind detailing the plan, under the new/clarified
> policy, for ensuring that Babylon et al. comply with our policy?
> Specifically:
>
>   * Do we have bugs open where we've informed them that they're in
> violation of our policy, and have they responded?

As Michael pointed out, bug 721264 was filed some time ago as a
blocklist bug, and there were 2 problems with it. First, it doesn't meet
the blocklist standard (it still doesn't). And second, we didn't have a
way to get in touch with Babylon.

We now have direct communication with Babylon and they have been very
responsive. We have been talking to them about other issues, mostly
crashes, and to be honest I had forgotten about bug 721264.

Michael, can you test the latest version and let us know which
preferences are not reset after uninstall? Then file a bug in Tech
Evangelism > Add-ons, or morph bug 721264 into that? I'll get in touch
with Babylon about this.

>   * What, in your mind, would be an acceptable timeframe for us to
> expect Babylon (or whoever) to fix this issue?

For other issues they have taken a week or so, but they were more
critical. If they can get this fixed within a month, I would think
that's ok.

>   * After the issue is fixed (or after the timeframe elapses), will we
> soft-block versions of the add-on which don't comply with our policy?

Re: Draft: Add-on Policies Justin Lebar 7/12/12 11:11 AM
>> * After the issue is fixed (or after the timeframe elapses), will we
>> soft-block versions of the add-on which don't comply with our policy?
>
> No, I don't think this is serious enough.

So again, to clarify and not to argue: Suppose we had an add-on that
violated our policy by not resetting users' preferences when it's
disabled.  Further suppose we contacted the vendor and they were
un-responsive (as Babylon was), or they did not fix the issue within
the time frame we'd set out.  We would then do nothing further to
mitigate the issue, under the new/clarified policy, just as we would
take no further action under our current policy.  Is that correct?
Re: Draft: Add-on Policies Benjamin Smedberg 7/12/12 11:21 AM
On 7/12/2012 1:54 PM, Michael Verdi wrote:
> On Thursday, July 12, 2012 11:02:53 AM UTC-5, Jorge Villalobos wrote:
>>
>> Yes, that&#39;s a big problem, and not one that can be fully solved, I
>> think. No matter how explicit we make add-on installation, there will
>> always be people that don&#39;t know/remember how they got a particular
>> extension or plugin. That&#39;s not to say there isn&#39;t anything we can do
>> about it. I&#39;ve promised way too many times on this thread, but there&#39;s
>> more to come ;).
>>
>> Jorge
> These two things are huge ways add-on makers use social engineering to trick people into installing software they don't want and change Firefox settings that they don't want changed. I believe we are doing our uses a disservice by not taking a leadership position on this practice. Maybe blocking add-ons that engage in this will help change their behavior. Maybe this is an area we can work with Microsoft and Google on? Surly this is an issue for them also.
I don't understand what you're trying to say here. We have already
implemented technical solutions so that users have to explicitly choose
to enable new addons, rather than them being enabled automatically. We
can improve this feature even further by having addons make explicit
claims about what they will do and what features they will provide when
they are enabled. Then, if the addon is making false claims or
misleading users, it is a lot easier to use the policy here to approach
the addon author and ask them to fix their addon, and if they refuse, to
potentially blocklist the addon.

--BDS

Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 2:46 PM
On 7/12/12 12:11 PM, Justin Lebar wrote:
>>> * After the issue is fixed (or after the timeframe elapses), will we
>>> soft-block versions of the add-on which don't comply with our policy?
>>
>> No, I don't think this is serious enough.
>
> So again, to clarify and not to argue: Suppose we had an add-on that
> violated our policy by not resetting users' preferences when it's
> disabled.  Further suppose we contacted the vendor and they were
> un-responsive (as Babylon was), or they did not fix the issue within
> the time frame we'd set out.  We would then do nothing further to
> mitigate the issue, under the new/clarified policy, just as we would
> take no further action under our current policy.  Is that correct?

(Babylon wasn't unresponsive. We just didn't know how to get in touch
with them)

Correct. The bar for blocklisting is set for add-ons that break the any
MUST policy or multiple SHOULD policies. If we thought that reverting
settings on disable was serious enough in itself to warrant
blocklisting, it would be a MUST policy. In this case it isn't, so we
wouldn't consider blocklisting.

I'll add something to the effect that any policy violation should be
notified to us, and that we will contact all developers that violate any
of them. That is certainly something we want to do.

Jorge
Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 2:46 PM
On 7/12/12 12:11 PM, Justin Lebar wrote:
>>> * After the issue is fixed (or after the timeframe elapses), will we
>>> soft-block versions of the add-on which don't comply with our policy?
>>
>> No, I don't think this is serious enough.
>
> So again, to clarify and not to argue: Suppose we had an add-on that
> violated our policy by not resetting users' preferences when it's
> disabled.  Further suppose we contacted the vendor and they were
> un-responsive (as Babylon was), or they did not fix the issue within
> the time frame we'd set out.  We would then do nothing further to
> mitigate the issue, under the new/clarified policy, just as we would
> take no further action under our current policy.  Is that correct?

Re: Draft: Add-on Policies Michael Verdi 7/12/12 4:04 PM
On Thursday, July 12, 2012 1:21:31 PM UTC-5, Benjamin Smedberg wrote:

> I don&#39;t understand what you&#39;re trying to say here. We have already
> implemented technical solutions so that users have to explicitly choose
> to enable new addons, rather than them being enabled automatically.

There are ways around that. Here's a demonstration http://youtu.be/3hw2EaXBRBs

The way I understand it, this is currently OK with us and would be OK with us under the proposal in this thread. I believe we have to do something more about this. This is a huge problem for our users. Can you imagine how a Firefox user would recover from this? Most wouldn't get as far as I did in the video. Those that got as far as I did would then be faced with uninstalling software from their computer and making about:config changes in Firefox. In other words it's impossible.  

I believe we need to be leaders here. "Mozilla answers to no one but you." That's our promise on behalf of our users. It doesn't say anything about exceptions made for software that social engineers our users.
Re: Draft: Add-on Policies Michael Verdi 7/12/12 4:04 PM
On Thursday, July 12, 2012 1:21:31 PM UTC-5, Benjamin Smedberg wrote:

> I don&#39;t understand what you&#39;re trying to say here. We have already
> implemented technical solutions so that users have to explicitly choose
> to enable new addons, rather than them being enabled automatically.

Re: Draft: Add-on Policies Benjamin Smedberg 7/12/12 4:53 PM
On 7/12/2012 7:04 PM, Michael Verdi wrote:
> On Thursday, July 12, 2012 1:21:31 PM UTC-5, Benjamin Smedberg wrote:
>
>> I don&#39;t understand what you&#39;re trying to say here. We have already
>> implemented technical solutions so that users have to explicitly choose
>> to enable new addons, rather than them being enabled automatically.
> There are ways around that. Here's a demonstration http://youtu.be/3hw2EaXBRBs
>
> The way I understand it, this is currently OK with us and would be OK with us under the proposal in this thread.
*If* they were intentionally subverting our enable dialog, then no, that
would not be in compliance with the policy. But it's not clear without
investigation whether this is a bug in our implementation of the
addon-found dialog, or an accidental change on their part, or an
intentional change on their part.

We clearly intend for that dialog to be shown for each new software install.

--BDS

Re: Draft: Add-on Policies Asa Dotzler 7/12/12 5:08 PM
Ask doesn't get the benefit of the doubt any more. They're subverting
user choice by exploiting a weakness in our implementation. That's how
they operate and until I hear them say "oops, we're fixing that AND
we're cool with you blocking any installs that were activated that way"
I'm going to assert that this is intentional and we should be taking
action to fix it for our users.

I've asked Jorge to file a bug to mitigate this. If the user does not
interact with the opt in we present before the browser is restarted, the
add-on should not be enabled. If the re-start was user initiated, we
should present them again with the opt in. If the re-start was initiated
by the third party, we should not re-prompt the user, we should treat it
as sabotage and simply deny the add-on activation.

- A

Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 5:38 PM
I filed bug 773514 to look into this.

Jorge

Re: Draft: Add-on Policies Jorge Villalobos 7/12/12 5:38 PM
On 7/12/12 6:08 PM, Asa Dotzler wrote:
Re: Draft: Add-on Policies Robert Kaiser 7/13/12 9:36 AM
Jorge Villalobos schrieb:
> There's a policy for that. Extensions should revert all changes when
> disabled or removed.

IMHO, this is too weak. This rule ought to be a MUST, not a SHOULD, from
where I stand.

That said, I'm also pretty convinced that it was a mistake that we did
not pursue our fight against search hijacking any more. When other
companies try to earn money by using our distribution and without adding
any actual value, then I call that fraud and we need to fight that hard,
IMHO.

Robert Kaiser

Re: Draft: Add-on Policies Alex Vincent 7/13/12 8:44 AM
On 7/12/2012 5:38 PM, Jorge Villalobos wrote:
> On 7/12/12 6:08 PM, Asa Dotzler wrote:
>> Ask doesn't get the benefit of the doubt any more. They're subverting
>> user choice by exploiting a weakness in our implementation. That's how
>> they operate and until I hear them say "oops, we're fixing that AND
>> we're cool with you blocking any installs that were activated that way"
>> I'm going to assert that this is intentional and we should be taking
>> action to fix it for our users.
>>
>> I've asked Jorge to file a bug to mitigate this. If the user does not
>> interact with the opt in we present before the browser is restarted, the
>> add-on should not be enabled. If the re-start was user initiated, we
>> should present them again with the opt in. If the re-start was initiated
>> by the third party, we should not re-prompt the user, we should treat it
>> as sabotage and simply deny the add-on activation.
>>
>> - A
>>
>
> I filed bug 773514 to look into this.
>
> Jorge
>

Hi – this is Alex Vincent from Ask.  I wanted to clear up some
inaccuracies.  In this implementation, it is not Ask that is bypassing
the browser opt-in, but rather AVG that’s doing it. Try it yourself by
removing the AVG Toolbar from the install:  go to Soft32.com, search for
Ask Toolbar and download it – when you’re presented with the AVG offer,
select “custom installation” and unselect both check boxes before
hitting “next.”  The AVG Toolbar won’t be installed, and Firefox's
opt-in dialog is displayed for Ask toolbar.

This practice is not new for AVG; it has been documented before:
https://bugzilla.mozilla.org/show_bug.cgi?id=751850 (see bottom of
thread: “One add-on I just noticed that installs silently is the AVG
Security Toolbar. It is bundled with the Miro Video Converter:”). As for
Soft32.com, they have no authority to offer our products (or to wrap our
toolbar with the AVG Toolbar) and we’re taking all the necessary
measures to make sure they stop.

Alex Vincent (WeirdAl on irc)
Re: Draft: Add-on Policies Blair McBride 7/14/12 8:23 AM
On 13/07/2012 11:13 a.m., Jorge Villalobos wrote:
> I see 2 problems here. One is that it looks like our third party install
> page doesn't persist after a restart.

Yes it does.

> The other is that Ask is exploiting this to avoid showing the page.

No, its something else. Commenting in that bug (773514), to avoid
derailing this thread.

- Blair
More topics »