This looks excellent. A great move in the right direction.
One simple comment:
> >> * 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'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:
> >> * 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.
>
>
> > 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