Disclosure of Add-on Practices

1 view
Skip to first unread message

Justin Scott

unread,
Aug 20, 2009, 2:52:50 PM8/20/09
to
Hi dev.amo friends,

Below is a proposal/spec for something new that I'm calling Disclosure
of Add-on Practices. We're seeing more and more add-ons doing things
that users may not be okay with, and we want to make sure these are
accurately and uniformly disclosed so that the user can make an educated
decision before installing the add-on.

Spec:
http://docs.google.com/Doc?docid=0Acwo2Bn17-PrZGZudHRobnJfOGhka2RocGdk&hl=en

Design bug: https://bugzilla.mozilla.org/show_bug.cgi?id=511706

A note on "first run experience" - this does not include basic first-run
pages, but does include any other type of first-run dialog, wizard,
sidebar, or other distraction.

Feedback is very welcome.

Justin

Andrew Williamson

unread,
Aug 20, 2009, 5:10:57 PM8/20/09
to

Looks good! What would be an example of a changed 'new tab' experience?


Andrew Williamson

Justin Scott

unread,
Aug 20, 2009, 5:17:44 PM8/20/09
to Andrew Williamson
There is currently a set of add-ons that places a search box for a
particular search engine on the blank screen that normally appears when
you open a new tab, with no way to opt-out of this.

I should also mention that if there is a practice an add-on is employing
that we feel should be disclosed and is not yet in this list of
checkboxes, that's what the "other" field is for -- AMO admins requiring
that an add-on disclose something in that field.

jorgev

unread,
Aug 20, 2009, 8:04:02 PM8/20/09
to
When the 'binary components' checkbox is clicked, I'd add a file field
underneath, giving the author the possibility to add a zipped archive
of their sources, with a note indicating that it's AMO policy to
always review the source for binary components.

Also, how about

'This addon changes preferences that are part of Firefox or other add-
ons'
'This add-on partially or completely overrides or disables features in
other add-ons'
'This add-on depends on external (non-free?) software to function'
'This add-on is partially or completely disabled after a trial period'

Jorge

On Aug 20, 3:17 pm, Justin Scott <flig...@mozilla.com> wrote:
> There is currently a set of add-ons that places a search box for a
> particular search engine on the blank screen that normally appears when
> you open a new tab, with no way to opt-out of this.
>
> I should also mention that if there is a practice an add-on is employing
> that we feel should be disclosed and is not yet in this list of
> checkboxes, that's what the "other" field is for -- AMO admins requiring
> that an add-on disclose something in that field.
>
> Andrew Williamson wrote:
> > On 20/08/2009 19:52, Justin Scott wrote:
> >> Hi dev.amo friends,
>
> >> Below is a proposal/spec for something new that I'm calling Disclosure
> >> of Add-on Practices. We're seeing more and more add-ons doing things
> >> that users may not be okay with, and we want to make sure these are
> >> accurately and uniformly disclosed so that the user can make an educated
> >> decision before installing the add-on.
>
> >> Spec:

> >>http://docs.google.com/Doc?docid=0Acwo2Bn17-PrZGZudHRobnJfOGhka2RocGd...

Mike Kaply

unread,
Aug 21, 2009, 1:05:50 AM8/21/09
to
On Aug 20, 1:52 pm, Justin Scott <flig...@mozilla.com> wrote:
> A note on "first run experience" - this does not include basic first-run
> pages, but does include any other type of first-run dialog, wizard,
> sidebar, or other distraction.

But you're asking people to put in dialogs for opting in for search.
Does that mean we are going to get dinged for doing what you say?

Other comments:

> This add-on changes the homepage

What if the add-on offers to change the homepage but doesn't change it
unless you say so?

> This is an extension or theme and adds a new search provider

This makes no sense. Why do you need to call out the extension/theme
part? Shouldn't it just be "This add-on adds a new search provider?

> This add-on contains binary components

Why is this relevant for an end user to know this? Is this a bad
practice? Some things can only be done in binary components.

> This add-on is supported by advertisements

Why is this important? Advertisements is too general. What if they
aren't intrusive? What if you have a google ad on your first run page?
Isn't that supported by advertisements? Are you finding fault with any
add-on that supports itself with advertisements?

> Other noteworthy practice:

What does that even mean? You expect people to point out when they are
doing something that the AMO team doesn't like?

> Please note practices that your add-on employs?

employs? Come on, that sounds a little sinister, doesn't it? How about
uses?

Where's the policy page that is referenced in the spec?

How is this going to be presented to the AMO user? Is it going to look
like a warning? Are you going to try to scare off users from
installing add-ons that do these things?

Mike Kaply

unread,
Aug 21, 2009, 1:07:06 AM8/21/09
to
On Aug 20, 4:17 pm, Justin Scott <flig...@mozilla.com> wrote:
> There is currently a set of add-ons that places a search box for a
> particular search engine on the blank screen that normally appears when
> you open a new tab, with no way to opt-out of this.

It's not just that. Other extensions do it to.

Ubiquity and Google Toolbar come to mind.

Justin Scott

unread,
Aug 21, 2009, 3:33:11 AM8/21/09
to

Mike Kaply wrote:
> On Aug 20, 1:52 pm, Justin Scott<flig...@mozilla.com> wrote:
>> A note on "first run experience" - this does not include basic first-run
>> pages, but does include any other type of first-run dialog, wizard,
>> sidebar, or other distraction.
>
> But you're asking people to put in dialogs for opting in for search.
> Does that mean we are going to get dinged for doing what you say?
>
We are asking that changing search defaults be opt-in. We would
certainly be okay with other methods of opting in, such as a link
somewhere that the user must click to turn on the change you want.
Obviously, users would be less likely to do this, so a dialog makes the
most sense for add-ons that really want the user to opt in. But we are
certainly not requiring a dialog, as long as the experience remains opt in.

> Other comments:
>
>> This add-on changes the homepage
>
> What if the add-on offers to change the homepage but doesn't change it
> unless you say so?
>

Still trying to figure out requests vs. changing without request. There
are a couple of the practices that seem like they should have 2 options:
"This add-on changes the homepage" and "This add-on requests to change
your homepage."

Homepage Changer 1.0 would be expected to change the homepage, yet it
should still disclose that it changes the homepage. Whereas RSS Reader
1.0 would have to have an opt-in mechanism for changing the homepage,
and should disclose that it requests to change the homepage. I'm not
sure it makes sense for it to disclose that it changes the homepage when
it only requests to do so per our policy, but I still think it should be
disclosed so the user knows to expect it.

I tried a mockup with 2 checkboxes at one point but didn't like it.
Looking for feedback from anyone on requesting vs. changing disclosure.

>> This is an extension or theme and adds a new search provider
>
> This makes no sense. Why do you need to call out the extension/theme
> part? Shouldn't it just be "This add-on adds a new search provider?
>

Search providers are a type of add-on hosted on AMO. We do not expect
add-ons that are search providers to disclose that they add a search
provider. Does immediately dismissing ideas that you don't understand
work well for you in other discussions?

>> This add-on contains binary components
>
> Why is this relevant for an end user to know this? Is this a bad
> practice? Some things can only be done in binary components.
>

It is not necessarily a bad practice, just a noteworthy one. There are
some great add-ons that use binary components. They just require special
review by AMO, and we don't have the same level of confidence in their
review that we do with an open source add-on.

>> This add-on is supported by advertisements
>
> Why is this important? Advertisements is too general. What if they
> aren't intrusive? What if you have a google ad on your first run page?
> Isn't that supported by advertisements? Are you finding fault with any
> add-on that supports itself with advertisements?
>

I think this may change to "This add-on displays advertisements in its
interface" to make it clearer that we're talking about advertisements in
the browser chrome and extension interfaces, not a first-run page or
website. I'm not finding fault with advertisements -- some users just
don't want to see advertisements in their browser.

>> Other noteworthy practice:
>
> What does that even mean? You expect people to point out when they are
> doing something that the AMO team doesn't like?
>

Yes. If we notice something when reviewing an add-on or something is
brought to our attention that we think is noteworthy and we don't have a
standard checkbox for it, add-ons would need to disclose it there before
they can be approved.

>> Please note practices that your add-on employs?
>
> employs? Come on, that sounds a little sinister, doesn't it? How about
> uses?
>

Sure, the copy isn't final. Will take it into consideration.

> Where's the policy page that is referenced in the spec?
>

It will be in the policy section of the new developer site, which will
be live before this is implemented but is not yet. Spoiler:
http://blog.mozilla.com/addons/2009/05/01/no-surprises/

> How is this going to be presented to the AMO user? Is it going to look
> like a warning? Are you going to try to scare off users from
> installing add-ons that do these things?
>

The design bug is linked in the original post here.

Robert Kaiser

unread,
Aug 21, 2009, 7:14:12 AM8/21/09
to
Mike Kaply wrote:
>> This add-on contains binary components
>
> Why is this relevant for an end user to know this? Is this a bad
> practice? Some things can only be done in binary components.

It's not bad practice, but such add-ons require special review and,
importantly for the user, only work correctly on platforms the binary
components were compiled for. They often don't work in e.g. x86_64
builds or, say, Solaris builds.

Robert Kaiser

Mike Kaply

unread,
Aug 21, 2009, 10:26:26 AM8/21/09
to
Sorry I was a little punchy last night. It was late.

What concerns me the most is that these warnings will make users
unnecessarily wary of downloading certain add-ons.

It seems like this is just yet another step toward moving AMO away
from first class support for commercial add-ons.

I would love to see some of this discussion tabled and perhaps had at
Add-on-con in October (assuming Mozilla is participating).

I think you will get a lopsided discussion here mainly from
individuals who are creating add-ons, not from entities.

Perhaps the solution is for someone to create addons.mozilla.com :)

Mike Kaply


Mike Kaply

unread,
Aug 21, 2009, 10:36:07 AM8/21/09
to

That would just be an AMO bug that it's either not reading the
platform in install.rdf and/or that it doesn't allow more platforms to
be specified than Windows/Mac/Linux.

I guess it is going to depend on presentation. If users are scared off
from add-ons that have binary components because of the way the
information is presented, that's a problem.

Unfortunately at this point, the design bug doesn't have any good
information in it.

The problem I see is that all these "practices" are being labeled some
how equal in their "abnormalness" for lack of a better word (the fact
that they have to be pointed out indicated that they are somehow
abnormal), so to a user, they'll just see "this add-on does stuff
other ones don't, I won't install it"

The fact is, people don't read things. So if these add-ons even appear
a tiny bit different than other add-ons on AMO, they simply won't get
installed. They won't read it and go "oh, it only does this". Heck,
most users won't even know what a binary component is!

Mike Kaply

Justin Scott

unread,
Sep 24, 2009, 7:08:11 PM9/24/09
to Mike Kaply
The design bug (https://bugzilla.mozilla.org/show_bug.cgi?id=511706) has
a mockup in it now. To me, it doesn't look scary and seems to only want
to present information to the user, like much of the metadata below it.

I'm going to work on a more detailed spec next week as we get ready to
implement this next release, but I think we will probably change the
wording around a bit of the box and items and likely won't show binary
components info to the user.

Justin

Reply all
Reply to author
Forward
0 new messages