On 8/17/12 4:38 PM, Michael Verdi wrote:
On Thursday, July 19, 2012 6:27:13 PM UTC-5, Jorge Villalobos wrote:
I
also haven't yet posted the ideas that we have to improve our reaction
to add-on problems. That will have to wait a week or two, but it's coming!
Have these been posted yet? The Support team in particular is interested in
hearing about these. Bad add-on behavior is historically our largest support
issue. Larger than crashes and only recently eclipsed by Flash 11.3 troubles.
Improving the situation is one of our top priorities.
A couple of people asked me to hold off on posting this until I got
their feedback about it. Since they are major stakeholders in this
process I have been waiting patiently. I have been putting some pressure
on them because I also really want this out soon.
Mozilla expects all add-ons, and their updates, hosted on AMO or
elsewhere, to follow these guidelines. These guidelines are not
exhaustive and don't necessarily apply to all add-ons (see Exceptions).
Yes! This is great. I think it's crucial that these also apply to add-ons not
hosted on AMO. I have a few more suggestions below that I think are important
to doing right by our users.
* Add-ons must remove all introduced code, executables, and application
configuration changes once they are uninstalled.
I agree 100%. I also have some questions and concerns about things I've seen. The more I
look into this, the more I see that Firefox preferences seem to be changed by a software
installer that also installs an add-on. So, even if you get to opt-out of the add-on
install, the preference change (home page and/or search) still happens and no method of
reverting these changes is provided. What can we do about this? Does the
"add-ons" term cover the software used to install them?
That's a good question, and I've been thinking about this too. While our
policies are meant for add-ons, I think that most of them apply to other
customizations introduced by external software. It might be worth
mentioning this in the opening statements in the policy.
* Add-ons should not disrespect the user's choices by making unexpected
changes or limiting the user's ability to revert them.
I think this should be a "must not" rather than a "should not." This is the
thing that sends 1.3 million people a month to SUMO looking for a solution. Many more people just
live with the changes, not having the time or skill to seek out help. These are the practices that
add-on makers use to ensnare users. These practices take away user sovereignty and they damage our
brand.
The main practice that causes "unexpected changes" is the opt-out checkbox.
Presenting add-on installs and preference changes as opt-out does not count as a user's
intent. Millions of people have said this to us.
* Exceptions *
* Add-ons can only run clean up code if they are uninstalled while
Firefox is running and they are enabled. This is the only case where it
is a requirement for add-ons to clean up after themselves.
Does this mean that if an add-on is removed by using it's program's associated
uninstaller, it won't have to/can't revert Firefox preferences that it changed?
If so is there anything that could be done to make this easier for users?
Program uninstallers are perfectly capable of making preference changes,
so that's another case that should be added there, yes.
* Enforcement *
If an add-on breaks any of the /must/ guidelines, or one or more the
/should/ guidelines to a significant extent, it qualifies for blocklisting.
Per blocklisting policy [https://wiki.mozilla.org/Blocklisting], Mozilla
will do their best to contact the developer and provide a reasonable
time frame for the problems to be corrected before a block is put in
place. The only exception to this are add-ons that are considered to be
malicious or whose developers have proven to be unreachable or unresponsive.
I agree with others in this thread that intentional violations should blocked right away.
Specifically, I think this includes add-ons that try to circumvent, tamper or alter our
install dialogs. I think we should call that out as a "must not" rule.
That is the first policy on the list.
There is one more thing I'd like to suggest here. I think we should take a leadership position on
behalf of all internet users and say that add-ons "should not" be bundled on an opt-out
basis. That practice is such a problem - not only for us but other browser makers too. To me it
feels like the kind of thing that an organization that promises "We answer to no one buy
you" would do. Of course simply stating that doesn't mean software makers will just change
their behavior but we have a good history of being able to promote ideas that are good for the web
and getting people and companies to get on board.
I don't know about that. In the case of AV vendors, I can see how
browser add-ons are a critical piece in the protection package, given
that the browser is one of the most frequent attack vectors. It can be
considered a core feature, and as such I think it makes sense for it to
be part of the recommended install.
Moreover, if we have our opt-in screen and we're already requiring them
to use it, asking them for a double opt-in seems unreasonable to me.
The previous discussion was so long (and successful!) that I am creating
a separate thread for this new draft, for the benefit of all.
I was expecting a followup in the other thread so I only just discovered this
one today. :(
Ah, sorry for that.
Jorge
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
