Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Pros and cons of different add-on install methods

1,011 views
Skip to first unread message

Nicholas Nethercote

unread,
Feb 23, 2012, 7:05:04 PM2/23/12
to dev-platform
Greetings,

"Third-party" add-ons, i.e. those that can be installed into Firefox,
are controversial. (E.g. see
https://bugzilla.mozilla.org/show_bug.cgi?id=728227.)

Third-party add-on installs can certainly be an avenue for
crapware/malware. I was wondering what the legitimate use cases for
them were, so Blair McBride and I set up an etherpad that discusses
the pros and cons of all three add-on installation methods, which I
thought might be of interest. It's here:
https://etherpad.mozilla.org/6vA99EFgNT.

Nick

Jeff Hammel

unread,
Feb 23, 2012, 7:19:44 PM2/23/12
to dev-pl...@lists.mozilla.org
While mentioned in the linked etherpad, currently all of our testing
infrastructure relies on just shoving some.xpi or some/directory into
browser/bundles or the extensions folder, etc. So we'd need a solution
to that before going forward. It has been mentioned having a preference
to toggle allowing 3rd party installation, of course if we can change it
in automation, others will be able to too.

If we're talking about whitelisting the testing addons, that is fine
(though i'm not sure how easy this is to fake too; i'm guessing "not
very" unless we're a little bit careful about it). But by the same
token we can't block testing workflow if this is going to be a long process.

In short, I would love to see a way of blocking 3rd party unvetted addon
installation, but we need to figure out what we're doing with testing first.

Jeff Hammel

Mook

unread,
Feb 24, 2012, 12:20:54 AM2/24/12
to
I believe most of the use cases are for platform integration. The Skype
toolbar, for example, seems to be there to scrape for phone numbers in
web pages to open Skype with. The various anti-virus things seem to do
it to analyze web pages for things similar to the phishing protection in
Firefox.

Firefox doesn't live in an isolated bubble; there's going to be external
developers trying to do things. There's... significantly more of them,
too. I believe that trying to make doing the Right Thing easy for
everybody else is more likely to lead to a better experience for the
user, rather than trying to make the bad things hard.

--
Mook

Justin Lebar

unread,
Feb 24, 2012, 4:54:50 AM2/24/12
to dev-pl...@lists.mozilla.org
> In short, I would love to see a way of blocking 3rd party unvetted addon installation, but we
> need to figure out what we're doing with testing first.

Accommodating testing should be totally doable, no matter what path we choose.

> I believe that trying to make doing the Right Thing easy for everybody else is more likely to
> lead to a better experience for the user, rather than trying to make the bad things hard.

Even add-ons written in good faith can cause problems [1], so I don't
think that making the Right Thing easy is good enough.

An add-on is as powerful as a patch to browser.js. We would never
ship an unreviewed, untested patch to browser.js, even from a trusted
Mozilla contributor. So it seems totally nuts to me that we allow
third parties, malicious and otherwise, to install patches (i.e.,
add-ons) into Firefox with basically no controls and oversight.

Any of the following would be a great improvement, IMO:

(1) disallowing add-ons installed by third parties, as suggested here.
(2) requiring that all add-ons installed by third parties be signed
by the AMO team [2].
(3) testing the most popular add-ons installed by third parties and
aggressively courting fixes from the relevant developers.

Judging by how poorly (2) was received by the add-ons people, I don't
think (1) or (2) is likely to fly. (3) seems worse to me, but it
would still be a huge step forward.

[1] http://blog.mozilla.com/nnethercote/2012/02/17/the-mcafee-site-advisor-add-on-has-an-appalling-memory-leak/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=728227

On Fri, Feb 24, 2012 at 6:20 AM, Mook
<mook.moz+nntp.n...@gmail.com.please-avoid-direct-mail>
wrote:
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Blair McBride

unread,
Feb 24, 2012, 5:57:04 AM2/24/12
to dev-pl...@lists.mozilla.org
On 24/02/2012 1:19 p.m., Jeff Hammel wrote:
> While mentioned in the linked etherpad, currently all of our testing
> infrastructure relies on just shoving some.xpi or some/directory into
> browser/bundles or the extensions folder, etc. So we'd need a solution
> to that before going forward. It has been mentioned having a preference
> to toggle allowing 3rd party installation, of course if we can change it
> in automation, others will be able to too.

I think that's a red herring - whatever we end up deciding to do to
about 3rd party/foreign installs, keeping the testing infrastructure
working will be a comparatively easy problem to solve. In the worst case
scenario, we just have slightly different behaviour when --enable-tests
is used. Even if it somehow ends up being awkward, I'd still rather
solve user experience problems first, and worry about tests later.

- Blair

Robert Kaiser

unread,
Feb 24, 2012, 10:33:03 AM2/24/12
to
Justin Lebar schrieb:
> An add-on is as powerful as a patch to browser.js.

And that's one of the reasons why we could build such a strong add-on
ecosystem in the first place.

> Any of the following would be a great improvement, IMO:
>
> (1) disallowing add-ons installed by third parties, as suggested here.
> (2) requiring that all add-ons installed by third parties be signed
> by the AMO team [2].
> (3) testing the most popular add-ons installed by third parties and
> aggressively courting fixes from the relevant developers.

One of the large problems seems to be to identify what has been
"installed by third parties", as any application installer in the system
with admin privileges can basically do anything to our install, a user
profile or whatever we require to determine something has been
"installed by third parties".

What I still would find a good thing though is to have an Android-like
flag that by default disables all non-AMO installs. That would at least
make it more difficult to inject add-ons into a default install where
users don't deactivate that pref.

Robert Kaiser

Benjamin Smedberg

unread,
Feb 24, 2012, 11:36:07 AM2/24/12
to Nicholas Nethercote, dev-platform
On 2/23/2012 7:05 PM, Nicholas Nethercote wrote:
> Third-party add-on installs can certainly be an avenue for
> crapware/malware. I was wondering what the legitimate use cases for
> them were, so Blair McBride and I set up an etherpad that discusses
> the pros and cons of all three add-on installation methods, which I
> thought might be of interest. It's here:
> https://etherpad.mozilla.org/6vA99EFgNT.
Some backstory:

In prior times we identified that we wanted apps to be able to integrate
into Firefox. For instance, we wanted to allow the Thunderbird install
to integrate more tightly with Firefox by making little UI bits
available, such as "email this page". This is similar to the "ideal"
form of a skype addon, for example, which would make it easy to hook up
a telephone protocol, maybe look up microdata, and do linkification so
that it's easy to make calls from within the browser.

At the time, installers were doing this by dropping files into the
Firefox install (appdir/extensions) or the user profile. This was
problematic because often these extensions needed to be updated with
Skype/Thunderbird, not using normal channels. We wanted to provide a
better way to allow this, especially on Windows, so that the extensions
could be installed and updated as part of the normal app install
process, so we introduced the Windows registry method of discovering
integration addons.

I think it's worthwhile to discuss whether these integration addons are
ultimately helping or hurting our users, in aggregate. But I'm afraid
that if we remove the integration points we have now, it's likely that
some of these third-party apps will simply revert to more invasive
methods of shoving files into the Firefox directory or mucking about in
the profile directory, which would mean that users have less control.

--BDS

Dave Townsend

unread,
Feb 24, 2012, 11:45:43 AM2/24/12
to
I started filling some stuff into this but then got awfully confused. I
couldn't decide if you are asking for Pros and Cons from the users,
developers or our perspective? Then I realised that that might not
matter as that doesn't seem the same as what you said you wanted, use
cases. Rather than overload the etherpad with that, here are a few I can
think of off the top of my head (and I agree, not all are good ones from
ours or our users perspectives):

* Integration with an application installed on the system (think
Evernote, Skype, AV tools, Java, etc.)
* Can keep the extension and the applciation versions identically easily
* Can uninstall the extension at the same time as the application
* Providing a different install experience
* Downloading a running an exe works from any browser and can install
an extension to multiple browsers
* Bundling an extension with another application
* Free money from stealing your searches!
* System administrator installs
* All my users MUST have NoScript!
* Testing
* Almost all our test harnesses use third-party add-ons

Dave Townsend

unread,
Feb 24, 2012, 11:50:04 AM2/24/12
to
On 02/24/12 02:57, Blair McBride wrote:
> On 24/02/2012 1:19 p.m., Jeff Hammel wrote:
>> While mentioned in the linked etherpad, currently all of our testing
>> infrastructure relies on just shoving some.xpi or some/directory into
>> browser/bundles or the extensions folder, etc. So we'd need a solution
>> to that before going forward. It has been mentioned having a preference
>> to toggle allowing 3rd party installation, of course if we can change it
>> in automation, others will be able to too.
>
> I think that's a red herring - whatever we end up deciding to do to
> about 3rd party/foreign installs, keeping the testing infrastructure
> working will be a comparatively easy problem to solve.

I disagree with this actually. If we put hurdles in the way of other
applications on the system then we put hurdles in the way of our testing
infrastructure, it is that simple.

> In the worst case
> scenario, we just have slightly different behaviour when --enable-tests
> is used. Even if it somehow ends up being awkward, I'd still rather
> solve user experience problems first, and worry about tests later.

We run automated tests against release builds of the application.

Dave Townsend

unread,
Feb 24, 2012, 11:50:34 AM2/24/12
to
Forgot one:

* Extension developers for testing purposes

Dave Townsend

unread,
Feb 24, 2012, 12:13:28 PM2/24/12
to
On 02/24/12 08:36, Benjamin Smedberg wrote:
> I think it's worthwhile to discuss whether these integration addons are
> ultimately helping or hurting our users, in aggregate. But I'm afraid
> that if we remove the integration points we have now, it's likely that
> some of these third-party apps will simply revert to more invasive
> methods of shoving files into the Firefox directory or mucking about in
> the profile directory, which would mean that users have less control.

I am largely against making things any more difficult at this point for
a couple of simple reasons. Everytime we've found a bad actor trying to
bypass restrictions we've put in place they've done so in a hacky way
that ended up being even more detrimental to the user's experience
(often force enabling every single add-on they had installed). Likewise
everytime I can think of that we've seen an issue with a third party
add-on we've been able to use our existing policy and technical
capabilities to push the developers to correct their mistake.

I don't deny that the system has problems I just worry a lot too about
what the third-party apps will start to do if we make things harder.
Frankly I've also never really figured out a way to make things harder
that isn't trivial to circumvent, kills our startup performance or
removes useful functionality (though perhaps we don't care about some of
that).

Asa Dotzler

unread,
Feb 24, 2012, 12:34:48 PM2/24/12
to
I know you guys are much smarter than me and have thought about this
much more deeply than I have, but I'm simply not willing to walk away
from this problem because it's "too hard."

We cannot allow our users to be abused like this. I think all of the
interested parties need to get together for a day or 10 and figure
something out. We cannot leave things as they are.

How can we organize a "work week" or similar to work through the
problems and come up with solutions -- (or, possibly, truly convince
ourselves that there really is nothing we can do.)

- A

Clint Talbert

unread,
Feb 24, 2012, 9:46:50 PM2/24/12
to
On 2/24/2012 9:34 AM, Asa Dotzler wrote:
>> I don't deny that the system has problems I just worry a lot too about
>> what the third-party apps will start to do if we make things harder.
>> Frankly I've also never really figured out a way to make things harder
>> that isn't trivial to circumvent, kills our startup performance or
>> removes useful functionality (though perhaps we don't care about some of
>> that).
>
> I know you guys are much smarter than me and have thought about this
> much more deeply than I have, but I'm simply not willing to walk away
> from this problem because it's "too hard."
>
I don't think anyone is shying away from this because it's hard. People
are unwilling to lose these defined integration points because by
removing the integration point, you're just building a higher wall for a
developer to leap over to get their extension into Firefox.

Assume for a moment that the addon developer has spent several
hours/days/weeks on whatever this is (be it useful stuff, crapware,
malware whatever) and wants to get it into Firefox. They will not be
deterred. If getting something into Firefox is that important to them,
then they will. If we really wanted to shut down all external
integration points to Firefox we could. It wouldn't provide a great user
experience, but neither does security by building a higher wall and
hoping that your adversaries don't build a taller ladder.

I think we need to solve this by turning it around from a "how do we
defend Firefox against X" question to a "what do the users want from
these addons, and what do the developers of the legitimate sets of these
addons hope to provide" question. With the users squarely in mind, I
believe we can make much better decisions. If we frame the problem as
"defending Firefox from malicious crap" then the solution we create
isn't going to be as complete as it could otherwise be.

I don't want to hijack the thread, but since it came up, let me say a
word about our test infrastructure. We are moving away from addon-based
testing systems. We are currently working on the Marionette project[1]
which will put a test-ability layer directly into Gecko, allowing us to
test *anything* we build on our platform. Marionette is the primary
driver behind the B2G test infrastructure, and once it proves itself
there and lands in m-c[2] we will begin the long process of migrating
all our test infrastructure to use it in place of addon-based systems.

Marionette is not a near term strategy, but since you gave me such a
great way to introduce it, I had to tell you about it. If you disable
the addon integration points in the short term, please rope us[3] in so
we can help you keep our automation running.

Thanks,
Clint

[1] Marionette:https://developer.mozilla.org/en/Marionette
[2] Land Marionette in m-c Bug 712643:
https://bugzilla.mozilla.org/show_bug.cgi?id=712643
[3] We're the Automation and Tools team (Ted's also on our team, but he
forgot to add himself to this list):
https://wiki.mozilla.org/Auto-tools/The_Ateam

Henri Sivonen

unread,
Feb 25, 2012, 4:58:26 AM2/25/12
to dev-pl...@lists.mozilla.org
On Sat, Feb 25, 2012 at 4:46 AM, Clint Talbert <ctal...@mozilla.com> wrote:
> I think we need to solve this by turning it around from a "how do we defend
> Firefox against X" question to a "what do the users want from these addons,
> and what do the developers of the legitimate sets of these addons hope to
> provide" question.

I think the fundamental disconnect here is the premise that "users
want" vs. observing that 3rd-party installers that are seem to be
about something other than browsing use running their installer .exe
as an excuse to dump all sort of junk into Firefox and IE (and
nowadays into Chrome, too).

What examples are there of addons that
1) Are installed by an .exe (as opposed to downloading an .xpi directly)
AND
2) Are wanted by users
?

If I install a VoIP app, I don't expect it to add functionality to my
browser. I definitely don't expect or want the act of installing VoIP
app to make my browser slow.

If I install an IM app, I don't expect it to add functionality to my
browser. I don't want it to hijack my search defaults and to add a
toolbar.

If I install a PDF reader, I might expect it to offer an NPAPI
plug-in, but I don't expect or want it to stuff toolbars in my
browser.

If I install an anti-virus package, I expect it to scan downloads for
viruses and I might expect it to scan RAM for malware signatures, but
I don't want it to take screen real estate in my browser (toolbars),
to make the browser leak memory like crazy or to take over the
browser's built-in password manager or phishing protection features.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Justin Lebar

unread,
Feb 25, 2012, 6:01:56 AM2/25/12
to Clint Talbert, dev-pl...@lists.mozilla.org
ctalbert wrote:
> I don't think anyone is shying away from this because it's hard. People are unwilling to lose
> these defined integration points because by removing the integration point, you're just
> building a higher wall for a developer to leap over to get their extension into Firefox.

But earlier in this thread, Dave Townsend wrote:

> Everytime we've found a bad actor trying to bypass restrictions we've put in place they've
> done so in a hacky way that ended up being even more detrimental to the user's experience > (often force enabling every single add-on they had installed).

Lots of other people have expressed a similar sentiment in bugs. So I
think Asa's point that he rejects the idea that we can't do anything
about this problem is fair. FWIW, I agree with him -- we don't need a
100% solution, but we are smarter than malware developers, and if we
make it a priority, I bet we can come up with a solution that works
pretty well.

Dave wrote in the same message:

> Likewise everytime I can think of that we've seen an issue with a third party add-on we've
> been able to use our existing policy and technical capabilities to push the developers to
> correct their mistake.

I think this is a key point of difference here.

Even if I accept the truth of this statement, it meets a very low bar.
Right now, we don't test third-party add-ons, so we have no
systematic way of finding out about these problems. Even if we did
test every third-party add-on after it was released to users,
convincing the developer to fix a problem and distributing the fix to
users takes time, during which some affected users will become
frustrated and switch to Chrome.

Moreover, I question assertion that we're able to get all issues with
third-party add-ons fixed. I bet there's sampling bias here -- we do
so little testing of third-party add-ons at the moment, and we place
so few limits on what they can do, that the problems we choose to try
to get fixed are precisely the ones which we think we *can* get fixed.
If we really stood up against malware/greyware, I doubt we'd be able
to claim that add-on authors are so accommodating.

If the claim is that we *have* standards for third-party add-ons and
think we should enforce those, nobody has been able to explain to me
why enforcing those standards in a patchwork, post-facto way is better
than enforcing them in a systemic way before the add-ons get into
users' hands, as I suggested in bug 728227.

Indeed, we already have a set of standards that add-ons have to meet:
The AMO guidelines. These are there to protect users and ensure they
stay in control of their browser. Nobody has explained to me why it's
OK for third-party add-ons, which we agree users by and large don't
ask for, to meet less-stringent standards than AMO add-ons. If
third-party add-ons are so important to our ecosystem, shouldn't we
relax the AMO guidelines so we stop limiting the AMO developers with
our petty rules? Nobody has explained to me why users ought to be
protected from AMO add-ons but not from third-party add-ons.

(There's an obvious answer to this: Mozilla puts its stamp of approval
on AMO add-ons, but not on third-party add-ons, therefore AMO should
have standards but third-party add-ons should not. But this is an
is-ought fallacy: Mozilla *ought* to put its stamp of approval on
every add-on that the user did not explicitly go out and install,
because every add-on is a patch to Firefox. It's OK if we break
Firefox, it's OK if a user builds their own Firefox with a broken
patch, but it is not OK if a corporation which happens to have
software installed on a user's computer breaks Firefox.)

ctalbert wrote:
> Assume for a moment that the addon developer has spent several hours/days/weeks on
> whatever this is (be it useful stuff, crapware, malware whatever) and wants to get it into
> Firefox. They will not be deterred. If getting something into Firefox is that important to them,
> then they will. If we really wanted to shut down all external integration points to Firefox we
> could. It wouldn't provide a great user experience, but neither does security by building a
> higher wall and hoping that your adversaries don't build a taller ladder.

To make sure I understand this: You mean to say you think we could
stop even a determined adversary from installing something into
Firefox, but that it would necessarily come at a high UX price?

I don't think this is true (and the argument is merely by analogy) but
even if it is, I'd gladly accept a one-time UX penalty that we control
in exchange for keeping out a permanent UX penalty we don't control,
such as a toolbar or a search-hijacking add-on.

-Justin

Nicholas Nethercote

unread,
Feb 26, 2012, 10:15:55 PM2/26/12
to Justin Lebar, dev-pl...@lists.mozilla.org
On Fri, Feb 24, 2012 at 8:54 PM, Justin Lebar <justin...@gmail.com> wrote:
>
> Any of the following would be a great improvement, IMO:
>
>  (1) disallowing add-ons installed by third parties, as suggested here.
>  (2) requiring that all add-ons installed by third parties be signed
> by the AMO team [2].
>  (3) testing the most popular add-ons installed by third parties and
> aggressively courting fixes from the relevant developers.
>
> Judging by how poorly (2) was received by the add-ons people, I don't
> think (1) or (2) is likely to fly.  (3) seems worse to me, but it
> would still be a huge step forward.

I gathered a list of the ~100 top add-ons and filed
https://bugzilla.mozilla.org/show_bug.cgi?id=730737 for this.

----

This has been an interesting thread. It's also been very abstract.
Let's make things more concrete.

Clint said:

> I think we need to solve this by turning it around from a "how do we defend
> Firefox against X" question to a "what do the users want from these addons,
> and what do the developers of the legitimate sets of these addons hope to
> provide" question. With the users squarely in mind, I believe we can make
> much better decisions.

Here's my answer to what users want from add-ons:

Adblock Plus
Video DownloadHelper
Greasemonkey
Firebug
Download Statusbar
Personas Plus
FlashGot
NoScript
DownThemAll!
WOT - Know Which Websites to Trust
Tab Mix Plus
Flagfox
Easy YouTube Video Downloader
Flashblock
Element Hiding Helper for Adblock Plus
ImTranslator - Online Translator, Dictionary, TTS
FireFTP
Web Developer
IE Tab
IE Tab V2 (FF 3.5, 4, 5, 6, 7+)

That's the top 20 most popular add-ons on AMO. These are excellent
add-ons, you've probably heard of a lot of them, you may have some of
them installed yourself. These are add-ons that users have taken
effort to install. Every add-on on that list makes me happy (well,
except for https://bugzilla.mozilla.org/show_bug.cgi?id=669730). When
people say things like "The only reason I haven't switched to Chrome
is because of Firefox's add-ons", this is what they're talking about.
In many cases even if you've never heard of one of these add-ons, you
can tell just from its name roughly what it does.

In contrast, when I look at the top 20 most popular add-ons (including
AMO and non-AMO add-ons) my heart sinks. The only ones I'm genuinely
happy to see are the AMO ones. A few others make me think "hmm" and
the rest make me think "oh god". Unfortunately this list is
considered sensitive so I can't discuss it directly in a public forum.
But I can point you at
https://bugzilla.mozilla.org/attachment.cgi?id=600823, which has the
top ~100 add-ons, including non-AMO ones, listed in alphabetical
order. I spent some time looking some of these up. I've put some
interesting links and data points in a list at the bottom of this
email. I did some cherry-picking when making that list, certainly,
but I still feel like I've been diving through dumpsters in the bad
part of town. Some notable things I learnt:

- For many of these, even the ones where the name is known, it's hard
to find any kind of official website to deliberately download the
add-on.

- The fact that third-party add-ons cannot be uninstalled from within
Firefox is hugely confusing to users. The number of "how do I disable
the XYZ add-on" hits you see is astounding.

- It's interesting that several add-ons (e.g. Yahoo! Toolbar,
Microsoft .NET Framework Assistant) are hosted on AMO but the vast
majority of the installations are not from AMO. This could mean
there's a prominent alternative location that the add-on can be
installed from, but I suspect third-party installs are mostly
responsible.

- Apart from the anti-virus add-ons, I don't recognize anything in
that list that provided integration between Firefox and other apps. I
could well be missing some, though.

- There are 17 add-ons that have "toolbar" in their name.


> If we frame the problem as "defending Firefox from
> malicious crap" then the solution we create isn't going to be as complete as
> it could otherwise be.

That's true. But the evidence suggests that "defending Firefox from
malicious crap" has to be a sizeable part of the solution.

In my opinion, user control should be the #1 principle when it comes
to add-ons -- users should be able to run exactly the add-ons they
want to, no more and no less. Third-party add-ons are an enormous
loophole in the "no more" part of that. The Firefox 8 opt-in check
made that loophole much smaller (and if we lived in a perfect world
where users always read and understood all warnings it would even
smaller). Do we have any data about how effective that opt-in check
is? E.g. how many third-party installs were disabled and how many
were re-enabled by users? I'd love to see any such data.

Nick


----

Results of my searches. Most of the links were in the top handful of
Google search results. I randomized this list so they're in no
particular order.

- Conduit Engine: 6 of the top 10 Google search results are about how
to remove it.

- Anti-banner (Kaspersky):
http://www.ghacks.net/2010/10/02/remove-kaspersky-anti-banner-and-url-advisor-from-firefox/

- PC Sync 2 Synchronisation Extension (Nokia) - AMO: #4 Google hit:
How to remove PC Sync 2 Synchronisation Extension
(http://www.techyforums.com/index.php?showtopic=307)

- Java Quick Starter: #1 hit on Google is "Removing the Java Quick
Starter Add-on"
(http://forums.mozillazine.org/viewtopic.php?f=38&t=921325&start=15)

- Microsoft .NET Framework Assistant: Remarkably popular for an
add-on that doesn't do much.

- {22C7F6C6-8D67-4534-92B5-529A0EC09405} , a.k.a. Trend Micro NSC
Firefox Extension:
http://community.trendmicro.com/t5/Home-and-Home-Office-Forum/how-to-remove-Trend-Micro-NSC-Firefox-Extension-6-5-0-1234/td-p/38616

- Ask toolbar: http://blog.mozilla.com/sumo/2012/02/21/ask-toolbar-is-changing-the-firefox-add-on-process/

- DataMngr (???): SpyBot Search and Destroy classifies it as malware:
http://forums.spybot.info/showthread.php?t=62634. And it was
nominated for blocklisting last year due to crashes but nothing
happened: https://bugzilla.mozilla.org/show_bug.cgi?id=665775.

- Babylon: #1 hit on Google is
http://www.ghacks.net/2011/08/17/how-to-uninstall-the-babylon-toolbar-completely/.
#3 hit is "Manual Removal Guide for Babylon.Toolbar"
(http://forums.spybot.info/showthread.php?t=64962)

- {4ED1F68A-5463-4931-9384-8FFF5ED91D92}, a.k.a. McAfee SiteAdvisor:
The old version was by far the leakiest add-on I've ever seen:
https://bugzilla.mozilla.org/show_bug.cgi?id=727938. The new version
(3.4.1.195) is better, but still easily the 2nd leakiest add-on I've
ever seen: https://bugzilla.mozilla.org/show_bug.cgi?id=729608

- Java Console: Lots of Firefox installations have multiple old
versions hanging around uselessly. Remarkably popular for an add-on
that doesn't do much.

- Garmin Communicator: has 51,249 AMO users, and *many* more non-AMO
users. https://addons.mozilla.org/en-US/firefox/addon/garmin-communicator/reviews/295748/
is interesting, too.

- ShopperReports: 7 of the top 10 google hits are about how to remove
it. (At least it has a home site, www.shopperreports.com.)

- Search Helper Extension:
http://arstechnica.com/microsoft/news/2010/06/microsoft-slips-ie-firefox-add-on-into-toolbar-update.ars

David Illsley

unread,
Feb 27, 2012, 3:20:09 PM2/27/12
to Nicholas Nethercote, dev-platform

On 27 Feb 2012, at 03:15, Nicholas Nethercote wrote:
> <snip>
> - It's interesting that several add-ons (e.g. Yahoo! Toolbar,
> Microsoft .NET Framework Assistant) are hosted on AMO but the vast
> majority of the installations are not from AMO. This could mean
> there's a prominent alternative location that the add-on can be
> installed from, but I suspect third-party installs are mostly
> responsible.

Is there an existing mechanism for 3rd party installers to request firefox install (with user consent) an addon from a URL/amo? It seems at least possible that doing so would result in fewer out-of-date addon installs.

>
> - Apart from the anti-virus add-ons, I don't recognize anything in
> that list that provided integration between Firefox and other apps. I
> could well be missing some, though.

Skype Toolbar? Or is it truly the most poorly named addon in existence

>
> - There are 17 add-ons that have "toolbar" in their name.
>
>
>> If we frame the problem as "defending Firefox from
>> malicious crap" then the solution we create isn't going to be as complete as
>> it could otherwise be.
>
> That's true. But the evidence suggests that "defending Firefox from
> malicious crap" has to be a sizeable part of the solution.

+1

Apple's recently announced Gatekeeper approach seems like a possibility to be looked at. There are plenty of addons that won't/shouldn't be/can't be hosted on amo, but which come from responsible authors e.g.[1]. Providing a 'registered developer' program which signs addons in exchange for agreement to additional terms, but doesn't provide hosting would allow additional terms, simpler revocation rules, and known contact details to non-amo hosted addons. Firefox could, by default, only install signed/or amo addons. Users could allow unsigned extensions, but that would require *in advance* flipping a setting, and there would be no easy prompted mechanism. That could go with a hard and fast rule that any installer which works around this setting gets blacklisted.

I wouldn't want to go further than this, but for me an approach like the above protects users, but provides for user sovereignty in that they can, if they truly wish, install anything.

David

[1] https://addons.mozilla.org/en-US/developers/docs/policies/submission
Is the add-on useful to an appropriately wide portion of Firefox's users? Your add-on doesn't need to be the next Greasemonkey or Firebug, but if it is only useful to people at your company or who are part of a small web community, we may feel that it's not yet appropriate to put it in front of all of our users.

Robert Kaiser

unread,
Feb 27, 2012, 3:21:59 PM2/27/12
to
Henri Sivonen schrieb:
> If I install a VoIP app, I don't expect it to add functionality to my
> browser.

_YOU_ don't. A number of users will find it convenient though that they
can click on any phone number in any website and call it via Sk..., er,
I mean, that VoIP app.

> If I install an IM app, I don't expect it to add functionality to my
> browser.

_YOU_ don't. OTOH, a user might love to be able to search for their IM
contacts' online profiles from the browser (similar to what we even
advertised with twitter recently) or have a "send message" on those web
profiles automatically send via their IM app, or share a website through
IM instantly from the browser (similar to what have in mind with our
share functionality in Firefox itself).

> If I install an anti-virus package, I expect it to scan downloads for
> viruses and I might expect it to scan RAM for malware signatures, but
> I don't want it to take screen real estate in my browser (toolbars),
> to make the browser leak memory like crazy or to take over the
> browser's built-in password manager or phishing protection features.

Well, I know definitely of users who want to additional "scan for
malware on websites", "defend against website script malware" and
similar functionality that some of those "security suites" ("anti-virus
package" is ancient language) install nowadays. That might even include
a "security rating" or such displayed inside a browser toolbar.

Don't take what _YOU_ think as granted for "the user" out there.

Actually, I've read a ton of messages on webmaster@m.o of people who
"threatened" to leave Firefox for something else just because their
Google Toolbar, Norton/McAfee/etc. in-browser functionality or similar
didn't work after an update (well, often they complain that "Mozilla
disabled my Norton" or such). Those comments are just about as many as
those that complain about search hijacking (why have you changed my home
page to that stupid ASK thing?) and as UI changes ("what is that new
home page where I don't find anything?" - yes, enough people see the
browser UI as "the home page").

You can't take yourself as an example for "the common web user", as
there is no such thing as the latter. There's all kind of different
people out there who want different things. Sure, the vast majority
don't want malware, but some of that third-party add-on stuff is
actually the reason to use Firefox and/or a certain third-party
application for a good number of people.

Robert Kaiser

Benjamin Smedberg

unread,
Feb 27, 2012, 3:38:50 PM2/27/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Clint Talbert
On 2/25/2012 6:01 AM, Justin Lebar wrote:
> ctalbert wrote:
>> I don't think anyone is shying away from this because it's hard. People are unwilling to lose
>> these defined integration points because by removing the integration point, you're just
>> building a higher wall for a developer to leap over to get their extension into Firefox.
> But earlier in this thread, Dave Townsend wrote:
>
>> Everytime we've found a bad actor trying to bypass restrictions we've put in place they've
>> done so in a hacky way that ended up being even more detrimental to the user's experience> (often force enabling every single add-on they had installed).
> Lots of other people have expressed a similar sentiment in bugs. So I
> think Asa's point that he rejects the idea that we can't do anything
> about this problem is fair.
There isn't a clearly defined problem yet, so talking about "this
problem" probably isn't the best language.

There seem to be several possible problems we're talking about:

1) the user doesn't know that Firefox is loading addons making their
software slow
2) The user chose to install a 3rd-party app which came with an
extension, chose to enable the extension, and it's still slow/eats
memory/is "bad"

It is my understanding that we've already solved (or attempted to solve)
#1 by prompting users to opt in to 3rd-party addons we discover on the
system. So, assuming that is correct, are you saying that the problem is
that users chose to keep these addons even though they are actually bad
for the user? Or that our fix for #1 was insufficient in some way?

We technically can require all addons to be signed, or some
non-authenticode equivalent where we ask AMO whether an addon is "ok".
But that's a pretty different discussion than what *install locations*
we support, which is how this thread started. Merely removing the
3rd-party install *install locations* will take us straight back to 2004
where these unwanted addons use hackery to put themself into a different
location.

If we want to actively prevent any unknown code from being run with
Firefox, we need to focus on the policy implications and signing
requirements.

--BDS

Justin Lebar

unread,
Feb 27, 2012, 4:25:25 PM2/27/12
to Benjamin Smedberg, dev-pl...@lists.mozilla.org, Clint Talbert
> There seem to be several possible problems we're talking about:
>
> 1) the user doesn't know that Firefox is loading addons making their
> software slow
> 2) The user chose to install a 3rd-party app which came with an extension,
> chose to enable the extension, and it's still slow/eats memory/is "bad"

I'd add

3) The user chose to enable a third-party extension, but did not give
informed consent.

Indeed, I don't think a user *can* give informed consent without

a) Reading the extension's source, or
b) Delegating trust to a third-party (e.g. Mozilla), or
c) Clicking through a Very Scary dialog.

At the moment, none of these criteria are met for third-party add-ons.

> It is my understanding that we've already solved (or attempted to solve) #1
> by prompting users to opt in to 3rd-party addons we discover on the system.

Do you mean #2? Opting in to a third-party add-on does not solve the
problem of users not knowing that an add-on is making Firefox slow.

> So, assuming that is correct, are you saying that the problem is that users
> chose to keep these addons even though they are actually bad for the user?
> Or that our fix for #1 was insufficient in some way?

I don't think our opt-in screen is sufficient to get informed consent
from a user. Additionally, it does not fix #1.

> Merely removing the 3rd-party install *install
> locations* will take us straight back to 2004 where these unwanted addons
> use hackery to put themself into a different location.
>
> If we want to actively prevent any unknown code from being run with Firefox,
> we need to focus on the policy implications and signing requirements.

No disagreement here.

Jorge Villalobos

unread,
Feb 27, 2012, 4:30:33 PM2/27/12
to Robert Kaiser
+100

Gijs Kruitbosch

unread,
Feb 27, 2012, 5:21:33 PM2/27/12
to Justin Lebar, Benjamin Smedberg, Clint Talbert
On 27/02/2012 22:25 PM, Justin Lebar wrote:
> <snip>
> Indeed, I don't think a user *can* give informed consent without
>
> a) Reading the extension's source, or
> b) Delegating trust to a third-party (e.g. Mozilla), or
> c) Clicking through a Very Scary dialog.
>
> At the moment, none of these criteria are met for third-party add-ons.
>
> <snip>
>
> I don't think our opt-in screen is sufficient to get informed consent
> from a user. Additionally, it does not fix #1.
>
> <snip>


Note that in the bug cited in the beginning (
https://bugzilla.mozilla.org/show_bug.cgi?id=721258 ) an add-on chose to modify
the (perception of the) opt-in UI because they already felt that was too scary.
Their argument seems to have been that the users already had a choice when they
installed the software (an opt-out screen in the setup program, AIUI) and
shouldn't have to click-through twice.

I agree that informed consent is good and important. However, I do think that
helping the user in this respect is Hard. What information does the user need,
exactly? How would we obtain that information for a given add-on? How do we
authenticate the add-on as being linked to that information?

Worst of all, I think the bug suggests that if we were to make the dialog/UI
scarier, external parties would go further in order to give users a more
'streamlined' experience when installing such an add-on.

I'm wondering if it would be better to do something more invasive post-facto:
detect performance/crash problems with add-ons and automatically disable them
for the user, and notify them about this in some way (offer them the option to
re-enable and/or completely remove the add-on). This could be a mechanism
similar to the blocklist we currently have, based on central testing. In
essence, this would mean invoking (b), but post-facto rather than doing vetting
beforehand.

The current blocklist system is a pretty harsh measure and affects users who
have intent (if not, perhaps, fully informed). Scary/scarier dialogs will
encourage vendors to bypass them. I wonder if this could be a good middle way.

Thoughts?

Gijs

Geoff Lankow

unread,
Feb 27, 2012, 5:54:50 PM2/27/12
to
On 28/02/12 09:20, David Illsley wrote:
> There are plenty of addons that won't/shouldn't be/can't be hosted on
> amo, but which come from responsible authors e.g. Providing a
> 'registered developer' program which signs addons in exchange for
> agreement to additional terms, but doesn't provide hosting would allow
> additional terms, simpler revocation rules, and known contact details
> to non-amo hosted addons.

This, or something like it.

If we clearly mark addons that haven't been AMO reviewed as such (at
every opportunity - about:addons, about:newaddon, choose-your-addons
dialog, others?), and create a way for third party addon devs to obtain
such a review without hosting on AMO, users will be better informed and
addon quality will improve (also, participating developers would be
agreeing to our terms). From an AMO point of view, I guess it'd require
a new type of addon listing, so while we're at it each addon could have
a page stating what it does (written by the developer or AMO reviewer),
how to remove it, performance etc.. We could also do this for popular
third-party addons we know about that haven't been submitted to be reviewed.

GL

Nicholas Nethercote

unread,
Feb 27, 2012, 9:56:31 PM2/27/12
to Justin Lebar, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Clint Talbert
On Mon, Feb 27, 2012 at 1:25 PM, Justin Lebar <justin...@gmail.com> wrote:
>> There seem to be several possible problems we're talking about:
>>
>> 1) the user doesn't know that Firefox is loading addons making their
>> software slow
>> 2) The user chose to install a 3rd-party app which came with an extension,
>> chose to enable the extension, and it's still slow/eats memory/is "bad"
>
> I'd add
>
> 3) The user chose to enable a third-party extension, but did not give
> informed consent.

Yes! IMO the 3rd-party opt-in warning was a great step forward. In a
perfect world, all users would read and understand the 3rd-party
opt-in warning, and this problem would be much smaller.

The current 3rd-party installation flow is like this:

- An external program "installs" the add-on (by placing it in the
appropriate location); it's disabled within Firefox by default.
- The user starts Firefox.
- Firefox pops up the warning screen.
- The user opts in or out.

What if was instead like this:

- An external program "installs" the add-on (by placing it in the
appropriate location); it's disabled within Firefox by default.
- The user starts Firefox.
- That's it... unless the user genuinely wants to enable the add-on,
whereupon they can visit the add-ons manager and enable it there.

Pros:
- It's a small change, much smaller than some other changes that have
been suggested.
- It's simpler than what we currently have -- no warning screen.
- It should further (greatly?) reduce the number of people who consent
to an add-on install without understanding what it means.

Cons:
- It's a tiny bit more work for a user who wants to accept a 3rd-party
install. (But we already make people do some work.)
- It doesn't solve the "I don't know how to uninstall add-on X" problem.

Nick

Henri Sivonen

unread,
Feb 28, 2012, 2:07:36 AM2/28/12
to dev-pl...@lists.mozilla.org
On Mon, Feb 27, 2012 at 10:21 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Henri Sivonen schrieb:
>
>> If I install a VoIP app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. A number of users will find it convenient though that they can
> click on any phone number in any website and call it via Sk..., er, I mean,
> that VoIP app.

Do users in general *expect* a VoIP app install to modify their
browser or do some of them just find the result convenient on
occasion? Do we have Mac and Linux users complaining that when they
installed Skype, they didn't get modifications dumped into their
Firefox?

>> If I install an IM app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. OTOH, a user might love to be able to search for their IM
> contacts' online profiles from the browser (similar to what we even
> advertised with twitter recently) or have a "send message" on those web
> profiles automatically send via their IM app, or share a website through IM
> instantly from the browser (similar to what have in mind with our share
> functionality in Firefox itself).

I meant Trillian dumping the Ask.com stuff into Firefox. It has very
little to do with IM functionality.

>> If I install an anti-virus package, I expect it to scan downloads for
>> viruses and I might expect it to scan RAM for malware signatures, but
>> I don't want it to take screen real estate in my browser (toolbars),
>> to make the browser leak memory like crazy or to take over the
>> browser's built-in password manager or phishing protection features.
>
> Well, I know definitely of users who want to additional "scan for malware on
> websites", "defend against website script malware" and similar functionality
> that some of those "security suites" ("anti-virus package" is ancient
> language) install nowadays. That might even include a "security rating" or
> such displayed inside a browser toolbar.

Fair enough.

Still, I think we should do something effective to steer our user base
to anti-virus programs that don't make the Firefox UX suck.

Neil

unread,
Feb 28, 2012, 6:13:58 AM2/28/12
to
Nicholas Nethercote wrote:

>What if was instead like this:
>
>- An external program "installs" the add-on (by placing it in the appropriate location); it's disabled within Firefox by default.
>- The user starts Firefox.
>- That's it... unless the user genuinely wants to enable the add-on, whereupon they can visit the add-ons manager and enable it there.
>
>
How would they know that it was there?

--
Warning: May contain traces of nuts.

Robert Kaiser

unread,
Feb 28, 2012, 2:03:52 PM2/28/12
to
Henri Sivonen schrieb:
> On Mon, Feb 27, 2012 at 10:21 PM, Robert Kaiser<ka...@kairo.at> wrote:
>> Henri Sivonen schrieb:
>>
>>> If I install a VoIP app, I don't expect it to add functionality to my
>>> browser.
>>
>> _YOU_ don't. A number of users will find it convenient though that they can
>> click on any phone number in any website and call it via Sk..., er, I mean,
>> that VoIP app.
>
> Do users in general *expect* a VoIP app install to modify their
> browser or do some of them just find the result convenient on
> occasion? Do we have Mac and Linux users complaining that when they
> installed Skype, they didn't get modifications dumped into their
> Firefox?

Not sure. You know, nobody did *expect* an awesomebar before we created
it and people got used to it - now they expect something like it. The
same is true for stuff like this - it's a convenient feature, people
will only complain when they had it and suddenly lose it. Just like the
Google Toolbar, for example.

> I meant Trillian dumping the Ask.com stuff into Firefox. It has very
> little to do with IM functionality.

Search hijacking is something we need to solve, that's clear anyhow.

> Still, I think we should do something effective to steer our user base
> to anti-virus programs that don't make the Firefox UX suck.

Nowadays that mostly means dumping Windows XP and using MSE on Win7.
Almost every other security suite is on record for causing one or the
other problem with us at times.

Robert Kaiser

Nicholas Nethercote

unread,
Feb 28, 2012, 7:01:51 PM2/28/12
to Neil, dev-pl...@lists.mozilla.org
On Tue, Feb 28, 2012 at 3:13 AM, Neil <ne...@parkwaycc.co.uk> wrote:
>>
>> - An external program "installs" the add-on (by placing it in the
>> appropriate location);  it's disabled within Firefox by default.
>> - The user starts Firefox.
>> - That's it... unless the user genuinely wants to enable the add-on,
>> whereupon they can visit the add-ons manager and enable it there.
>
> How would they know that it was there?

If they deliberately installed the add-on, whatever instructions they
are following can tell them.

If they didn't, they won't know. That's the whole point :)

Nick

db_cooper

unread,
Feb 28, 2012, 8:16:46 PM2/28/12
to dev-platform
A telling comment from Ars Technica's article on "the challenges of policing the Firefox ecosystem":

http://arstechnica.com/business/news/2012/02/add-ons-behaving-badly-the-challenges-of-policing-the-firefox-ecosystem.ars?comments=1#comments-bar

"Is there a third-party plugin like Adblock plus, but functions for add-ons? I would LOVE to be able to set up my familys' browsers and install some 'pluginBlock Plus' that will keep them from being afflicted by the ask toolbar, yahoo browserplus, Site Advisor and all the other crapware that can accumulate."

Brian Smith

unread,
Feb 29, 2012, 12:48:37 AM2/29/12
to Asa Dotzler, dev-pl...@lists.mozilla.org
Asa Dotzler wrote:
> I know you guys are much smarter than me and have thought about this
> much more deeply than I have, but I'm simply not willing to walk away
> from this problem because it's "too hard."
>
> We cannot allow our users to be abused like this. I think all of the
> interested parties need to get together for a day or 10 and figure
> something out. We cannot leave things as they are.

Unintentionally bad addons can be dealt with relatively easily, if we are willing to forgo addon compatibility and if we are willing to reduce the functionality available to addons.

But, even if we do that, it will do little to stop intentionally malicious/subversive software. To protect against intentional abuse at the user-mode level (like Firefox normally runs) we can:

* Give users more information about things they are about to download, and explain to users the negative consequences of running an installer before they download and/or run it. This works when the user downloads the installer using a Mozilla product (Firefox and/or Thunderbird).

* Stop fighting against anti-malware vendors, stop treating their software as though IT is malware (which, honestly, is what we normally do, because we think it tends to slow down Firefox too much), and work directly with them to our integration hooks so that their products integrate directly with Firefox in an optimal way that doesn't have huge performance costs, so that their software can help protect users from bad addons before they get installed.

* Investigate the application sandboxing mechanisms in Mac OS X Lion and later, and in Windows 8 and later, and take full advantage of them when they are available.



At the business/partnership level:

* Create partnerships with anti-malware vendors that provide useful tools for stopping bad Firefox addons, that would enable us to give their software (perhaps a version with targeted functionality) to our users for free.

* Do co-marketing with venders of operating systems that offer protections against these problems. E.g. if Windows 8's sandboxing is effective at preventing this kind of abuse, then start a "Firefox Recommends Windows 8" campaign with Microsoft.



At the operating-system level, we can:

* Build our own operating system (e.g. B2G) with security and malware-prevention as a primary focus, and convince users to use it.

* Have our installer (which runs with admin rights) scan for badware and help facilitate its removal each time we do an update.



Notice that all these suggestions are about general anti-malware, and not about addons. That is because, for many purposes, you don't even need to build a Firefox extension to abuse Firefox users. For example, if *I* were going to build software that hijacked the Firefox search box, I would do it this way:

1. Run a process in the background that watches for
Firefox windows.
2. Overlay a transparent window on top of (the title
bar and toolbar of) each Firefox window then they
are opened.
3. Forward most mouse from my transparent window to
the Firefox window underneath, except for
clicks on the search box.
4. Forward most keyboard events to Firefox, except
for ones that would set focus on the search box.
5. Overlay my own search box on top of the Firefox
search box which handles the keyboard input, and
when a search is done (e.g. enter is pressed),
loads the URL in Firefox.
6. If there were ever an imminent update to Firefox
that could somehow protect against my software,
I would immediately disable Firefox's update
checking.

This could also be done by writing a custom mouse driver and/or mouse hook and/or assistive technology plugin, AFAICT. Developing such software wouldn't be that expensive, and it would be nearly impossible to defend against, or even detect. (We don't have ANY idea how much software is already doing this to us.)

- Brian

Brian Smith

unread,
Feb 29, 2012, 1:04:15 AM2/29/12
to Nicholas Nethercote, Justin Lebar, Benjamin Smedberg, dev-pl...@lists.mozilla.org, Clint Talbert
Nicholas Nethercote wrote:
> The current 3rd-party installation flow is like this:
>
> - An external program "installs" the add-on (by placing it in the
> appropriate location); it's disabled within Firefox by default.
> - The user starts Firefox.
> - Firefox pops up the warning screen.
> - The user opts in or out.

I think this does a reasonable job of keeping honest add-on developers honest.

> What if was instead like this:
>
> - An external program "installs" the add-on (by placing it in the
> appropriate location); it's disabled within Firefox by default.
> - The user starts Firefox.
> - That's it... unless the user genuinely wants to enable the add-on,
> whereupon they can visit the add-ons manager and enable it there.

I think even well-intentioned addon developers would try to subvert this, just like Mozilla subverts Microsoft's restrictions against applications pinning themselves to the taskbar in Vista/7.

- Brian

Justin Lebar

unread,
Feb 29, 2012, 2:15:52 AM2/29/12
to Brian Smith, dev-pl...@lists.mozilla.org, Asa Dotzler
I think maybe the reason I'm still hopeful we can do something useful
on the technical side to protect our users is: I have difficulty
believing that many malware authors are as smart as bsmith.

If we were only able to block 50% of the add-ons we tried to block,
and only for one year, wouldn't that still be worth doing?

I think it might be folly not to do anything because we're afraid of
malware authors finding a way around it. Shouldn't we have used this
same logic to argue against the third-party add-on confirmation screen
added in FF8? (Perhaps you did!)

Of the many good suggestions here, a few involve relying more on
anti-malware software. But of course anti-malware is also a
cat-and-mouse game. I understand that virus scanners run with higher
privilege than Firefox and invest a degree effort into this
cat-and-mouse game that we probably don't want to. But if you believe
these tools are effective (I honestly have my doubts), then that's
evidence that *someone* is capable of keeping up with malware authors,
at least to some degree.

On Wed, Feb 29, 2012 at 12:48 AM, Brian Smith <bsm...@mozilla.com> wrote:
> Asa Dotzler wrote:
>> I know you guys are much smarter than me and have thought about this
>> much more deeply than I have, but I'm simply not willing to walk away
>> from this problem because it's "too hard."
>>
>> We cannot allow our users to be abused like this. I think all of the
>> interested parties need to get together for a day or 10 and figure
>> something out. We cannot leave things as they are.
>

Jonas Sicking

unread,
Feb 29, 2012, 10:56:43 AM2/29/12
to Robert Kaiser, dev-pl...@lists.mozilla.org
On Mon, Feb 27, 2012 at 9:21 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Henri Sivonen schrieb:
>
>> If I install a VoIP app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. A number of users will find it convenient though that they can
> click on any phone number in any website and call it via Sk..., er, I mean,
> that VoIP app.
>
>> If I install an IM app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. OTOH, a user might love to be able to search for their IM
> contacts' online profiles from the browser (similar to what we even
> advertised with twitter recently) or have a "send message" on those web
> profiles automatically send via their IM app, or share a website through IM
> instantly from the browser (similar to what have in mind with our share
> functionality in Firefox itself).

It's definitely true that we don't know what users want in all situations.

However, looking at the data provided by Nick in this thread, I think
it's safe to say that it's very common for users to end up with addons
that they don't want to have. I don't think that we can with good
conscience look at the data and still throw up our hands and say
"well, the users chose to install the software, they must want it".

Freedom of choice is extremely important. I think none of us want to
become gate-keepers in the same fashion as Apple's App store. However
freedom of choice is only meaningful if we provide users the ability
to make informed decisions. Given the looks of the list of installed
addons people are making, I think we can safely say that many of them
are not making informed decisions.

There seems like there are a couple of things that we could obviously
do to help users in this:

1. Addons should always always be possible to uninstall using
about:addons. Any addon which can't be completely uninstalled this way
should be mercilessly blocked. In this scenario the user has clearly
made a decision not to run a particular addon and so we should enable
that. Ideally simply disabling the addon should work in which case the
user can easily reenable the addon again. There are simply no excuses
for making it hard for the user to disable an addon. If this is due to
technical limitations at our end, all the better since fixing that is
in our hands.

2. When we find significant problems with an addon, such as crashes or
significant performance/memory problems have the capability to inform
users about this. I haven't heard the latest of the by now well known
problem in a McAfee Site Advisor so it's quite possible that the
problem has been fixed since. However in similar situations, it would
be great if we could display a dialog to the user which explains the
problem with the addon, what functionality the addon provides (I think
we have anecdotal evidence that people are worried that disabling the
Skype toolbar makes it impossible to use skype at all) and explain
that if they choose to disable the addon for now, it will be
automatically enabled when a fix for the problem is provided by the
vendor.

Providing users with tools to customize their firefox experience the
way they want to, and providing the information needed to use those
tools should hopefully be an obvious win.

Additionally I think it would be awesome if we could require addons to
provide a honest description of what the addon does. Right now users
have very little information to go on when deciding if they should
enable an addon or not. However given all the trouble we have with
enforcing much less controversial policies like "shouldn't cause big
performance/memory problems", having a policy like "must not lie when
providing description of what addon does" seems dead on arrival.

/ Jonas

db_cooper

unread,
Feb 28, 2012, 8:16:46 PM2/28/12
to mozilla.de...@googlegroups.com, dev-platform

Dave Townsend

unread,
Feb 29, 2012, 1:16:28 PM2/29/12
to
On 02/29/12 07:56, Jonas Sicking wrote:
> There seems like there are a couple of things that we could obviously
> do to help users in this:
>
> 1. Addons should always always be possible to uninstall using
> about:addons. Any addon which can't be completely uninstalled this way
> should be mercilessly blocked. In this scenario the user has clearly
> made a decision not to run a particular addon and so we should enable
> that. Ideally simply disabling the addon should work in which case the
> user can easily reenable the addon again. There are simply no excuses
> for making it hard for the user to disable an addon. If this is due to
> technical limitations at our end, all the better since fixing that is
> in our hands.

This is something we have to fix, not the third-parties. We don't give
them a way to install extensions that can then be uninstalled by users.

Henri Sivonen

unread,
Feb 29, 2012, 1:18:52 PM2/29/12
to dev-pl...@lists.mozilla.org
FWIW, non-support for toolbar junk is now a marketable characteristic of IE10:

"Why don’t toolbars and add-ons work?"
"Internet Explorer 10 provides an “add-on free” experience."

http://windows.microsoft.com/en-US/windows-8/faq

Robert Kaiser

unread,
Feb 29, 2012, 1:33:46 PM2/29/12
to
Jonas Sicking schrieb:
> However, looking at the data provided by Nick in this thread, I think
> it's safe to say that it's very common for users to end up with addons
> that they don't want to have.

Sure, and search hijacking is only one example of that (and you'll see
that I mentioned both that and the more general thing as also being
high-volume factors is misdirected webmaster@m.o email).
I didn't say anything to the contrary. I just stated that Henri's view
or depiction of things is also way too simplistic as there are good
reasons for users to want some of the add-ons installed by third parties.

I think we all agree that users should be in charge of what add-ons they
get or don't get. We need to make sure they can get those they actually
want, though, as much as we need to make sure they don't get those they
don't want.

Robert Kaiser

Robert Kaiser

unread,
Feb 29, 2012, 1:39:28 PM2/29/12
to
Brian Smith schrieb:
> * Stop fighting against anti-malware vendors, stop treating their software as though IT is malware (which, honestly, is what we normally do, because we think it tends to slow down Firefox too much), and work directly with them to our integration hooks so that their products integrate directly with Firefox in an optimal way that doesn't have huge performance costs, so that their software can help protect users from bad addons before they get installed.

If we would provide hooks to security suites to implement their stuff
without crashing if we changed binaries (e.g. after an update) and
across versions (so that people won't damn Firefox because "it disabled
their Norton" on every update), I'd be incredibly happy.

Robert Kaiser

Justin Lebar

unread,
Feb 29, 2012, 2:59:30 PM2/29/12
to Brian Smith, dev-pl...@lists.mozilla.org, Asa Dotzler
Note that at the moment, many malicious/questionable add-ons can still
claim to be following our rules. So if I were an AV vendor, I'd be
hesitant to brand them as a "virus".

On the other hand, if an add-on actively subverts Firefox's
protections, then we could rightly claim that it's unquestionably
malicious and should be blocked.

So if you think we should get AV vendors involved on our side, there's
an argument for escalating things. I'm not convinced it outweighs the
dangers of provoking escalation, but then again, I have very little
faith in AV in general.

-Justin

On Wed, Feb 29, 2012 at 12:48 AM, Brian Smith <bsm...@mozilla.com> wrote:
> Asa Dotzler wrote:
>> I know you guys are much smarter than me and have thought about this
>> much more deeply than I have, but I'm simply not willing to walk away
>> from this problem because it's "too hard."
>>
>> We cannot allow our users to be abused like this. I think all of the
>> interested parties need to get together for a day or 10 and figure
>> something out. We cannot leave things as they are.
>
> Unintentionally bad addons can be dealt with relatively easily, if we are willing to forgo addon compatibility and if we are willing to reduce the functionality available to addons.
>
> But, even if we do that, it will do little to stop intentionally malicious/subversive software. To protect against intentional abuse at the user-mode level (like Firefox normally runs) we can:
>
> * Give users more information about things they are about to download, and explain to users the negative consequences of running an installer before they download and/or run it. This works when the user downloads the installer using a Mozilla product (Firefox and/or Thunderbird).
>
> * Stop fighting against anti-malware vendors, stop treating their software as though IT is malware (which, honestly, is what we normally do, because we think it tends to slow down Firefox too much), and work directly with them to our integration hooks so that their products integrate directly with Firefox in an optimal way that doesn't have huge performance costs, so that their software can help protect users from bad addons before they get installed.
>

Asa Dotzler

unread,
Feb 29, 2012, 6:23:59 PM2/29/12
to
On 2/29/2012 10:33 AM, Robert Kaiser wrote:
>
> I think we all agree that users should be in charge of what add-ons they
> get or don't get. We need to make sure they can get those they actually
> want, though, as much as we need to make sure they don't get those they
> don't want.
>
> Robert Kaiser

It's not as simple as agreeing that both are important. Because one
necessarily trades against the other, we have to decide which is more
important and by how much.

I assert that protecting users from add-ons they do not want is more
important than making it easy to get infected with add-ons they do want.
I think it is important enough by a wide enough margin that I'm support
making it harder for third party software and non-AMO sites to install
add-ons into Firefox so as to protect users from unwanted add-on
infections.

Raising the barrier for the few add-ons that legitimately want to be
hosted outside of AMO is the next step we will have to take in order to
slow the spread of unwanted add-ons.

We should increase the barrier both in product (more features like our
Firefox 8 conformation) and in policy. If add-ons attempt to circumvent
Firefox's security features or violate our policies, we should work with
AV vendors to have them identified as malware and we should use our very
capable public voice to shame them into fixing their behavior or to put
them out of business.

We should also make it much easier to install add-ons from within
Firefox or from AMO, providing a carrot for developers to use our system
where possible. We should also work with the few legitimate add-ons
hosted outside of AMO (like the AV guys) to give them the APIs they need
so they don't break the Firefox experience and potentially providing
them with somewhat lowered barriers to third party software installs if
they agree to live by the spirit of our policies.

This is a problem with no one-size-fits-all solution. There is no
requirement that we treat all add-ons equally.

Firefox is our product and we have the right to protect it and our users
from infection by unwanted crap. We should have policies and technology
that bias towards user control, but knowing that will negatively impact
some legitimate use cases, we should be willing to make exceptions for
specific add-ons where we have confidence in their origin and user impact.

If an add-on author wants to piggy back on the success of Firefox, they
have to play by our rules. If they don't want to play by our rules, let
them build and ship a browser of their own.

- A

Dao

unread,
Feb 29, 2012, 6:52:03 PM2/29/12
to
On 01.03.2012 00:23, Asa Dotzler wrote:
> I think it is important enough by a wide enough margin that I'm support
> making it harder for third party software and non-AMO sites to install
> add-ons into Firefox so as to protect users from unwanted add-on
> infections.

Why are non-AMO sites suddenly part of the discussion again? Where's the
data proving that they are a problem?

Robert Strong

unread,
Feb 29, 2012, 6:58:12 PM2/29/12
to dev-pl...@lists.mozilla.org
If we want an add-on identified as malware by AV vendors our first step
should be to blocklist them and on the blocklist page we should state
that the add-on is categorized as malware especially since this has been
possible for quite some time.

Robert

>
> We should also make it much easier to install add-ons from within
> Firefox or from AMO, providing a carrot for developers to use our
> system where possible. We should also work with the few legitimate
> add-ons hosted outside of AMO (like the AV guys) to give them the APIs
> they need so they don't break the Firefox experience and potentially
> providing them with somewhat lowered barriers to third party software
> installs if they agree to live by the spirit of our policies.
>
> This is a problem with no one-size-fits-all solution. There is no
> requirement that we treat all add-ons equally.
>
> Firefox is our product and we have the right to protect it and our
> users from infection by unwanted crap. We should have policies and
> technology that bias towards user control, but knowing that will
> negatively impact some legitimate use cases, we should be willing to
> make exceptions for specific add-ons where we have confidence in their
> origin and user impact.
>
> If an add-on author wants to piggy back on the success of Firefox,
> they have to play by our rules. If they don't want to play by our
> rules, let them build and ship a browser of their own.
>
> - A

Brian Smith

unread,
Feb 29, 2012, 7:25:01 PM2/29/12
to Robert Strong, dev-pl...@lists.mozilla.org
Robert Strong wrote:
> If we want an add-on identified as malware by AV vendors our first
> step should be to blocklist them and on the blocklist page we should
> state that the add-on is categorized as malware especially since this
> has been possible for quite some time.

Then the malicious addons will disable and/or filter the blocklist. It isn't even hard, because we give them the APIs to do so.

- Brian

Justin Lebar

unread,
Feb 29, 2012, 7:27:46 PM2/29/12
to Brian Smith, Robert Strong, dev-pl...@lists.mozilla.org
At which point we publicly shame them, try to get AV vendors to block them, etc.

By blacklisting, we're no worse off than we were before, right? The
blacklist can be a public sign that we disapprove, even if it's not
effective technically.

-Justin

Brian Smith

unread,
Feb 29, 2012, 8:27:51 PM2/29/12
to Asa Dotzler, dev-pl...@lists.mozilla.org
Asa Dotzler wrote:
> Firefox 8 conformation) and in policy. If add-ons attempt to
> circumvent Firefox's security features or violate our policies,
> we should work with AV vendors to have them identified as
> malware and we should use our very capable public voice to
> shame them into fixing their behavior or to put them out of
> business.

If Microsoft did this, then Firefox would be blocked as malware for pinning itself to the taskbar. Just because company X disagrees with what company Y is doing, doensn't mean that AV vendors should/will flag company Y's software as malware. See also http://en.wikipedia.org/wiki/360_v._Tencent.

> potentially providing them with somewhat lowered barriers to
> third party software installs if they agree to live by the
> spirit of our policies.

AV software venders don't need us to lower our barriers for them, because there is no barrier that we could implement in user-mode Firefox that they could not subvert, without greatly restricting the configurability and exensibility of Firefox (which is something I support, BTW). And, anything that AV software can do, malware/grayware can do.

> If an add-on author wants to piggy back on the success of Firefox,
> they have to play by our rules. If they don't want to play by our
> rules, let them build and ship a browser of their own.

s/add-on/app/ ; s/Firefox/iPhone/ ; s/browser/smartphone/
s/add-on/application/ ; s/Firefox/Windows/ ; s/browser/operating system/

Cheers,
Brian

Nicholas Nethercote

unread,
Feb 29, 2012, 8:45:33 PM2/29/12
to Brian Smith, dev-pl...@lists.mozilla.org, Asa Dotzler
On Wed, Feb 29, 2012 at 5:27 PM, Brian Smith <bsm...@mozilla.com> wrote:
>
> If Microsoft did this, then Firefox would be blocked as malware for pinning itself to the taskbar.

This comes down to your definition of "malware". I'm interested in
fixing the more blatant malware and crapware that really degrade
Firefox, not add-ons that poke their toes over a line.


>> If an add-on author wants to piggy back on the success of Firefox,
>> they have to play by our rules. If they don't want to play by our
>> rules, let them build and ship a browser of their own.
>
> s/add-on/app/ ; s/Firefox/iPhone/ ; s/browser/smartphone/
> s/add-on/application/ ; s/Firefox/Windows/ ; s/browser/operating system/

What's your point? Any platform will have rules and ways to punish
those that violate the rules. (E.g. we have the add-on blocklist.)
That doesn't mean our rules are the same as Apple's.

And no-one's arguing that Firefox add-ons should only be available via
AMO, which is what would be required for us to be equivalent to the
iPhone and the App Store. (Furthermore, IMO, these Apple/iPhone
analogies are as likely to confuse as they are to illuminate.)

Nick

Asa Dotzler

unread,
Feb 29, 2012, 8:52:25 PM2/29/12
to
I'm interested in lowering the barrier for add-on installs at AMO, but
not for non-AMO sites. If, for example, we can work out a single-click
install for AMO, I have no intention of expanding that to random
websites. If we can manage to lower the warning "tone" of the
confirmation dialog for add-on installs that we review at AMO, I have no
intention of making the warning any less scary (and could imagine making
it even scarier) for non-AMO sites.

Non-AMO installs are a problem. One of the reasons people opt to host
outside of AMO is because they are not interested in conforming to our
"no surprises" policy or being reviewed in any other way (including by
our community of users giving ratings and other warnings to users) and
so non-AMO installs should be assumed less trustworthy. Right now we're
treating non-AMO installs (after the "let this site prompt for installs
clickthough) with the same "warning" as AMO installs and that's wrong.

- A

Asa Dotzler

unread,
Feb 29, 2012, 8:57:32 PM2/29/12
to
Malware that is truly malware with dedicated people behind it will
circumvent a lot. But crapware that doesn't want to be labeled as
malware and targeted by AV software and Mozilla in the public sphere
will conform or give up.

- A

Asa Dotzler

unread,
Feb 29, 2012, 9:07:41 PM2/29/12
to
On 2/29/2012 5:27 PM, Brian Smith wrote:
> Asa Dotzler wrote:
>> Firefox 8 conformation) and in policy. If add-ons attempt to
>> circumvent Firefox's security features or violate our policies, we
>> should work with AV vendors to have them identified as malware and
>> we should use our very capable public voice to shame them into
>> fixing their behavior or to put them out of business.
>
> If Microsoft did this, then Firefox would be blocked as malware for
> pinning itself to the taskbar. Just because company X disagrees with
> what company Y is doing, doensn't mean that AV vendors should/will
> flag company Y's software as malware. See also
> http://en.wikipedia.org/wiki/360_v._Tencent.


I disagree. That's not a security feature in any way. That's not even a
"pro-user" feature. It's a blatant anti-competetive move that Microsoft
very carefully crafted to be able to advantage IE against other
browsers, violating the spirit but not the letter of the Consent Decree
they agreed to with the US DOJ more than a decade ago.

We're not arbitrarily blocking software. We will have rules that are
clearly pro-user and which we will can feel good about defending.


>> potentially providing them with somewhat lowered barriers to third
>> party software installs if they agree to live by the spirit of our
>> policies.
>
> AV software venders don't need us to lower our barriers for them,
> because there is no barrier that we could implement in user-mode
> Firefox that they could not subvert, without greatly restricting the
> configurability and exensibility of Firefox (which is something I
> support, BTW). And, anything that AV software can do,
> malware/grayware can do.


AV software vendors do not want to subvert Firefox. They are trying to
work with us. They would appreciate not having their users jump through
dialogs and other hoops when they have achieved actual real informed
user opt in and I'm more than happy to carve out exceptions for those
who behave well.

>> If an add-on author wants to piggy back on the success of Firefox,
>> they have to play by our rules. If they don't want to play by our
>> rules, let them build and ship a browser of their own.
>
> s/add-on/app/ ; s/Firefox/iPhone/ ; s/browser/smartphone/
> s/add-on/application/ ; s/Firefox/Windows/ ; s/browser/operating
> system/

That's just silly. We are not Apple or Windows. We are a public-benefit
organization looking out for our users. That's what our mission demands
of us. Any comparison of our actions in support of our users for the
promotion of our mission to those of profit-driven monopolists trying to
hold on to or increase their control over users is horse shit, IMO.

- A

Dao

unread,
Feb 29, 2012, 9:35:31 PM2/29/12
to
On 01.03.2012 02:52, Asa Dotzler wrote:
> On 2/29/2012 3:52 PM, Dao wrote:
>> On 01.03.2012 00:23, Asa Dotzler wrote:
>>> I think it is important enough by a wide enough margin that I'm support
>>> making it harder for third party software and non-AMO sites to install
>>> add-ons into Firefox so as to protect users from unwanted add-on
>>> infections.
>>
>> Why are non-AMO sites suddenly part of the discussion again? Where's the
>> data proving that they are a problem?
>
> I'm interested in lowering the barrier for add-on installs at AMO, but
> not for non-AMO sites. If, for example, we can work out a single-click
> install for AMO, I have no intention of expanding that to random
> websites.

Ok. That's not what you wrote above.

> Non-AMO installs are a problem. One of the reasons people opt to host
> outside of AMO is because they are not interested in conforming to our
> "no surprises" policy or being reviewed in any other way (including by
> our community of users giving ratings and other warnings to users)

People being uninterested in getting reviewed and hosted by a third
party isn't necessarily a problem. People installing something from a
source /they/ trust isn't necessarily a problem either.

> and so non-AMO installs should be assumed less trustworthy.

Sure, allowing one-click installs on random sites would be insane.

Asa Dotzler

unread,
Feb 29, 2012, 9:44:39 PM2/29/12
to
On 2/29/2012 6:35 PM, Dao wrote:
> On 01.03.2012 02:52, Asa Dotzler wrote:
>> On 2/29/2012 3:52 PM, Dao wrote:
>>> On 01.03.2012 00:23, Asa Dotzler wrote:
>>>> I think it is important enough by a wide enough margin that I'm support
>>>> making it harder for third party software and non-AMO sites to install
>>>> add-ons into Firefox so as to protect users from unwanted add-on
>>>> infections.
>>>
>>> Why are non-AMO sites suddenly part of the discussion again? Where's the
>>> data proving that they are a problem?
>>
>> I'm interested in lowering the barrier for add-on installs at AMO, but
>> not for non-AMO sites. If, for example, we can work out a single-click
>> install for AMO, I have no intention of expanding that to random
>> websites.
>
> Ok. That's not what you wrote above.

Sorry, I got to the final paragraphs where I was talking about both
third party software installs and non-AMO installs and thought I should
just insert it into that earlier paragraph and it would make sense.

>
>> Non-AMO installs are a problem. One of the reasons people opt to host
>> outside of AMO is because they are not interested in conforming to our
>> "no surprises" policy or being reviewed in any other way (including by
>> our community of users giving ratings and other warnings to users)
>
> People being uninterested in getting reviewed and hosted by a third
> party isn't necessarily a problem. People installing something from a
> source /they/ trust isn't necessarily a problem either.

But our installation dialog is our communication to the user and we have
no basis for trust for those add-ons not hosted at AMO (unless we do
have some other relationship with them). That means our add-on
installation dialog should convey that these are not trusted in any way
by Firefox (Mozilla) and could be harmful.

- A

Justin Lebar

unread,
Feb 29, 2012, 10:08:32 PM2/29/12
to Asa Dotzler, dev-pl...@lists.mozilla.org
> But our installation dialog is our communication to the user and we have no
> basis for trust for those add-ons not hosted at AMO (unless we do have some
> other relationship with them). That means our add-on installation dialog
> should convey that these are not trusted in any way by Firefox (Mozilla) and
> could be harmful.

By way of comparison, installing a malicious add-on is way, way more
dangerous than accepting an untrusted SSL cert. The malicious add-on
can snoop on every connection, permanently (and can install arbitrary
software on your computer).

Right now, the untrusted cert warning is way scarier than the non-AMO
warning, and it's roughly as easy to accept a bogus cert as it is to
install a non-AMO add-on. So if you think that the untrusted SSL flow
we currently have is reasonable, then that's an argument in favor of
making the non-AMO add-on dialog way scarier (and way harder to get
around).

(Now, maybe you'll say that we shouldn't assume that all non-AMO
add-ons are malicious. But should we similarly assume that untrusted
certs are not malicious? Many of them are perfectly benign, but
that's not the point. The point is, we can't trust them, just like we
can't trust non-AMO add-ons.)

Brian Smith

unread,
Feb 29, 2012, 11:28:34 PM2/29/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Asa Dotzler
Justin Lebar wrote:
> By way of comparison, installing a malicious add-on is way, way more
> dangerous than accepting an untrusted SSL cert. The malicious add-on
> can snoop on every connection, permanently (and can install arbitrary
> software on your computer).

Right. That's a very serious deficiency in the design of our addon system. An addon should not be able to do those things without explicit user approval of those specific actions, and there are some thing (e.g. disable the blocklist) that addons shouldn't be able to do at all.

> we currently have is reasonable, then that's an argument in favor of
> making the non-AMO add-on dialog way scarier (and way harder to get
> around).

I do think it would be a good idea to make the dialog much more informative instead of more scary: e.g. "This software is likely to *hijack your search engine*, *install toolbars* into your web browsers, and *slow down Firefox*. Mozilla recommends that you *do NOT install it* without verifying elsewhere that it is safe. Here are some alternative addons with similar functionality: [...] [Cancel] [Install it anyway]." This is much better than a dialog that says something vague about the addon being untrusted. Users are used to clicking through those kind of vague warnings all day every day to get stuff they want.

I really like the already-done work that was done to prompt the user to enable an addon. Like I said before, it is a good trade-off for keeping honest people honest. The main thing I am arguing against in this thread is the idea that user-mode Firefox can protect itself against admin-rights malware/grayware installers in any way that can be controlled by end-users. I think it is a waste of energy to implement any additional protections against third-party installers that can be subverted by doing anything other than replacing existing Mozilla-signed EXE and DLL files in C:\Program Files\Firefox (these actions should automatically get the software classified as malware by AV software, which we should help users enable). So, for example, it doesn't make sense to require only non-AMO software to be signed, or to allow the user to disable those checks; instead, to be effective, all addons (including addons from AMO) would have to be signed, and there must not be a pref to disable the signature checks. In other words, we would be implementing a signature system very similar (technically) to Apple's iOS system; obviously, there would be significant fallout from that.

The secondary thing I am arguing against is the idea that we could force venders of security software to wait days or weeks for us to review their addon updates to sign them, just because we are worried that they might cause a memory leak or some other problem. It sucks when there are bad bugs in these addons, but I don't think the risk of such bugs outweighs the venders' needs to ship updates as fast as possible. Those venders generally need to be able to ship updates to their addons as fast as possible, for the same reasons we must be able to turn around chemspill releases as fast as possible.

Cheers,
Brian

Dao

unread,
Mar 1, 2012, 6:14:58 AM3/1/12
to
On 01.03.2012 04:08, Justin Lebar wrote:
> By way of comparison, installing a malicious add-on is way, way more
> dangerous than accepting an untrusted SSL cert. The malicious add-on
> can snoop on every connection, permanently (and can install arbitrary
> software on your computer).

You already made the relevant distinction. Here the user actively
installs software, there the user is told that the connection may be
insecure when the user likely expects it to be secure.

Do you also think we should make it harder to download software based on
the fact that Mozilla doesn't trust sites it doesn't control? I hope
not, but it seems like you have to by your logic.

Again, please show the data suggesting that the current warning isn't
sufficient. Otherwise you're trying to fix what isn't broken.

Benjamin Smedberg

unread,
Mar 1, 2012, 7:55:49 AM3/1/12
to Brian Smith, dev-pl...@lists.mozilla.org, Justin Lebar, Asa Dotzler
On 2/29/2012 11:28 PM, Brian Smith wrote:
> Right. That's a very serious deficiency in the design of our addon
> system. An addon should not be able to do those things without
> explicit user approval of those specific actions, and there are some
> thing (e.g. disable the blocklist) that addons shouldn't be able to do
> at all.
That's a true long-term statement, and is something that we've actively
been addressing with the jetpack design (if not the current SDK
packaging implementation). But it doesn't really help us figure out what
to do right now in terms of policy and UI.

> I do think it would be a good idea to make the dialog much more informative instead of more scary: e.g. "This software is likely to *hijack your search engine*, *install toolbars* into your web browsers, and *slow down Firefox*. Mozilla recommends that you *do NOT install it* without verifying elsewhere that it is safe. Here are some alternative addons with similar functionality: [...] [Cancel] [Install it anyway]."
How would we possibly know what functionality an addon has in the
install dialog (unless it came from AMO)? I think it's good to be more
specific about the warning, but "is likely to" seems like a pretty far
overreach...

--BDS

Justin Lebar

unread,
Mar 1, 2012, 9:05:07 AM3/1/12
to Dao, dev-pl...@lists.mozilla.org
> Do you also think we should make it harder to download software based on the
> fact that Mozilla doesn't trust sites it doesn't control? I hope not, but it
> seems like you have to by your logic.

I'd be OK making a scarier warning when people try to run software
they downloaded from the Internet; that only makes sense. You should
be able to turn the nagging off...

> Again, please show the data suggesting that the current warning isn't
> sufficient. Otherwise you're trying to fix what isn't broken.

The data is our list of the top 100 add-ons.

https://etherpad.mozilla.org/hSOVNzKZen

There's a ton of greyware and malware in there. In fact, suspicious
software far outnumbers useful software. Nick posted about this
earlier in the thread.

Assuming that the add-on opt-in in FF8 is not being routinely
circumvented, every non-AMO add-on listed there was explicitly enabled
by the user. So the fact that there's so much crap listed indicates
to me that we're not doing a good enough job protecting our users from
crap.

-Justin

Dao

unread,
Mar 1, 2012, 9:14:51 AM3/1/12
to
On 01.03.2012 15:05, Justin Lebar wrote:
>> Do you also think we should make it harder to download software based on the
>> fact that Mozilla doesn't trust sites it doesn't control? I hope not, but it
>> seems like you have to by your logic.
>
> I'd be OK making a scarier warning when people try to run software
> they downloaded from the Internet; that only makes sense. You should
> be able to turn the nagging off...

Most of our users get reasonably scary OS-level warnings that we don't
control, fwiw.

You also wrote "way scarier (and way harder to get around)". So, again,
we should make downloading harder (not just scarier), shouldn't we?

>> Again, please show the data suggesting that the current warning isn't
>> sufficient. Otherwise you're trying to fix what isn't broken.
>
> The data is our list of the top 100 add-ons.
>
> https://etherpad.mozilla.org/hSOVNzKZen
>
> There's a ton of greyware and malware in there. In fact, suspicious
> software far outnumbers useful software. Nick posted about this
> earlier in the thread.

Many of these are drive-by installations, not in-browser installations
from non-AMO sites. We had successfully made this distinction some time
ago in this thread.

Jorge Villalobos

unread,
Mar 1, 2012, 9:37:23 AM3/1/12
to Justin Lebar, Dao, dev-pl...@lists.mozilla.org
You're assuming that data comes only from Firefox 8+ users, which is
wrong. You're also assuming that all of those add-on installations are
enabled, which is also not true. In fact, the opt-in screen you get
after upgrading to Firefox 8 doesn't give you the option to uninstall,
only disable IIRC, so that data provides no insight into how effective
that feature was.

- Jorge

Jorge Villalobos

unread,
Mar 1, 2012, 9:37:23 AM3/1/12
to Justin Lebar, Dao, dev-pl...@lists.mozilla.org
On 3/1/12 8:05 AM, Justin Lebar wrote:

Jorge Villalobos

unread,
Mar 1, 2012, 9:41:30 AM3/1/12
to Nicholas Nethercote, Brian Smith, dev-pl...@lists.mozilla.org
Requiring all add-ons to go through a review or certification process
conducted by us before they are installable, or "easily" installable is
not that far from the level of control that Apple exerts over iOS
developers. The only real difference would be that we would allow them
to distribute their add-ons elsewhere, as long as we approve of them.

At least that's what some people are proposing, so I don't think that
comparison is that far-fetched or unproductive.

- Jorge

Jorge Villalobos

unread,
Mar 1, 2012, 9:41:30 AM3/1/12
to Nicholas Nethercote, Brian Smith, dev-pl...@lists.mozilla.org
On 2/29/12 7:45 PM, Nicholas Nethercote wrote:

Asa Dotzler

unread,
Mar 1, 2012, 12:06:41 PM3/1/12
to
On 3/1/2012 6:41 AM, Jorge Villalobos wrote:

> Requiring all add-ons to go through a review or certification process
> conducted by us before they are installable, or "easily" installable is
> not that far from the level of control that Apple exerts over iOS
> developers. The only real difference would be that we would allow them
> to distribute their add-ons elsewhere, as long as we approve of them.

No it's not the same or even close. We'd be reviewing to put users in
control not to police content or defend our apps from competition. I
wish those of you comparing us to bad actors would stop. It's not
helpful -- further, it's insulting to well-meaning people on the other
side of the argument from you.

- A

Robert Kaiser

unread,
Mar 1, 2012, 1:35:07 PM3/1/12
to
Asa Dotzler schrieb:
> I assert that protecting users from add-ons they do not want is more
> important than making it easy to get infected with add-ons they do want.

Nobody disputes that, but this is something entirely different to what
you talked about in the paragraph above where it was protecting them
from what they don't want vs. giving them those they want. I say we do
need to care that both those things work.


I have said it repeatedly before, and I will reiterate that I think we
need to go Android-style and disable installation of non-AMO add-ons by
default, with a setting that needs to be flipped to even enable those at
all, and then some distinct warnings (better than what we have now) even
when that setting is enabled.
I like Justin's parallel to the cert warnings a lot, as I think we have
a pretty good UX there for making it hard to do the wrong thing but
still allowing exceptions for people who know what they are doing.
Perhaps we should deploy a very similar experience here.

Robert Kaiser

David Illsley

unread,
Mar 1, 2012, 2:11:02 PM3/1/12
to Asa Dotzler, dev-pl...@lists.mozilla.org
I'm pretty sure Apple would assert they're not doing it to prevent
competition, or to police content beyond that required to protect users
from undesirable content. Whether you choose to believe that or not, and
regardless of whether you find it insulting, the public positions of MoCo
and Apple would definitely be comparable.

I suspect a lot of the public good will towards companies saying 'trust us,
we're not evil' is used up, regardless of the details (and I do trust
Mozilla). I'd find selling the openness message, particularly around
mobile, more difficult if the discussion isn't around principles, but
around the intentions of the gatekeepers.

David

Asa Dotzler

unread,
Mar 1, 2012, 3:17:34 PM3/1/12
to
On 3/1/2012 11:11 AM, David Illsley wrote:
> On Thu, Mar 1, 2012 at 5:06 PM, Asa Dotzler<a...@mozilla.org> wrote:
>
>> On 3/1/2012 6:41 AM, Jorge Villalobos wrote:
>>
>> Requiring all add-ons to go through a review or certification process
>>> conducted by us before they are installable, or "easily" installable is
>>> not that far from the level of control that Apple exerts over iOS
>>> developers. The only real difference would be that we would allow them
>>> to distribute their add-ons elsewhere, as long as we approve of them.
>>>
>>
>> No it's not the same or even close. We'd be reviewing to put users in
>> control not to police content or defend our apps from competition. I wish
>> those of you comparing us to bad actors would stop. It's not helpful --
>> further, it's insulting to well-meaning people on the other side of the
>> argument from you.
>>
>> - A
>
>
> I'm pretty sure Apple would assert they're not doing it to prevent
> competition, or to police content beyond that required to protect users
> from undesirable content.

Well, you'd be wrong. Apple has said publicly that they will not allow
for apps that compete with built in iOS functionality and have
disallowed apps which did that from their store. They have also censored
content that they found objectionable even though the "code" of the app
would have passed a detailed technical review.

> Whether you choose to believe that or not, and regardless of whether you
> find it insulting, the public positions of MoCo and Apple would definitely
> be comparable.

They are not comparable. That's like saying that France and China public
policies are comparable because both countries have governments.

We already have a system that allows us to block bad acting add-ons.
There is already a regime. The issues at hand is the scope of the
policies and the enforcement mechanisms.

- A

Asa Dotzler

unread,
Mar 1, 2012, 3:21:11 PM3/1/12
to
On 3/1/2012 10:35 AM, Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> I assert that protecting users from add-ons they do not want is more
>> important than making it easy to get infected with add-ons they do want.
>
> Nobody disputes that, but this is something entirely different to what
> you talked about in the paragraph above where it was protecting them
> from what they don't want vs. giving them those they want. I say we do
> need to care that both those things work.

And I'll repeat: those two things are in conflict. We cannot optimize
for both of those things. They trade against each other. If we want to
protect users from add-ons they do not want, we will necessarily have to
make it a bit more difficult to get some of the non-AMO add-ons they do
want. If we want to make it super easy to get some non-AMO add-ons they
do want, we're going to see them get more add-ons they didn't want.

I think you think we can have both. We cannot. We have to decide which
is more important and optimize for that case -- even at the expense of
the other side.

- A

Nicholas Nethercote

unread,
Mar 1, 2012, 6:24:36 PM3/1/12
to Jorge Villalobos, Brian Smith, dev-pl...@lists.mozilla.org
On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
>
> Requiring all add-ons to go through a review or certification process
> conducted by us before they are installable, or "easily" installable is not
> that far from the level of control that Apple exerts over iOS developers.
> The only real difference would be that we would allow them to distribute
> their add-ons elsewhere, as long as we approve of them.
>
> At least that's what some people are proposing, so I don't think that
> comparison is that far-fetched or unproductive.

Which "some people"? I think you're conflating third-party installs
with first-party installs. "Some people" have been suggesting we
restrict third-party installs, e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=728227.

But if anyone has suggested restricting first-party installs, I've
missed it, and I disagree with it. I'll repeat what I said in
https://bugzilla.mozilla.org/show_bug.cgi?id=728227#c29:

"IMO, the single most important thing when it comes to add-ons is user
control: a user should be able to run exactly the add-ons they want,
no more and no less. Third-party installs completely violate that
principle. So I think the FF8 check was a great improvement, but that
it's still too easy for a user to agree to a third-party installation
request without understanding it what they're agreeing to and thus end
up enabling an add-on they didn't ask for."

Principles 4 and 5 from the Mozilla Manifesto are relevant here:

4. Individuals' security on the Internet is fundamental and cannot be
treated as optional.
5. Individuals must have the ability to shape their own experiences on
the Internet.

(And third-party installs are why iPhone analogies are misleading.
AFAIK the iPhone has nothing like a third-party install -- if you
install app A it can't change the behaviour of app B.)


> You're assuming that data comes only from Firefox 8+ users, which is wrong.
> You're also assuming that all of those add-on installations are enabled,
> which is also not true. In fact, the opt-in screen you get after upgrading
> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
> that data provides no insight into how effective that feature was.

Ah, that's useful to know. Indeed, the FF8 opt-in check is central to
this whole discussion, because it sets precedent -- it's clear that
agreement was reached that the third-party installation situation was
unacceptable, and something was done about it (I think
https://bugzilla.mozilla.org/show_bug.cgi?id=476430 and
https://bugzilla.mozilla.org/show_bug.cgi?id=596343 were the relevant
bugs).

So the question is now: was the FF8 opt-in check enough? I asked
earlier in the thread if we had any data on its effect. Do we? If we
do and it says, for example, that 90% of third-party add-ons got
disabled, then we don't have much of a problem. (Well, there's still
the "how do I uninstall add-on X?" problem.)

But without that data we're just going to end up arguing in circles.

Nick

Jorge Villalobos

unread,
Mar 1, 2012, 6:45:29 PM3/1/12
to Nicholas Nethercote, Brian Smith, dev-pl...@lists.mozilla.org
On 3/1/12 5:24 PM, Nicholas Nethercote wrote:
> On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos<jo...@mozilla.com> wrote:
>>
>> Requiring all add-ons to go through a review or certification process
>> conducted by us before they are installable, or "easily" installable is not
>> that far from the level of control that Apple exerts over iOS developers.
>> The only real difference would be that we would allow them to distribute
>> their add-ons elsewhere, as long as we approve of them.
>>
>> At least that's what some people are proposing, so I don't think that
>> comparison is that far-fetched or unproductive.
>
> Which "some people"? I think you're conflating third-party installs
> with first-party installs. "Some people" have been suggesting we
> restrict third-party installs, e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227.

I might be misinterpreting some of the comments in that bug and in this
discussion, but it can be hard to track who's talking about what, and
who meant "third party" in which context.

You should be aware, though, that the technical solutions that are being
proposed, like requiring all add-ons to be signed or reviewed by us,
would be very difficult to implement in such a limited context, and can
be easily manipulated by those installing software in your computer. For
example, they could just launch Firefox with the installation page for
their add-on, instead of externally installing it. Since we are trying
to protect users who just click through anything without reading, I
don't see how that wouldn't work for them, and I don't see why we would
block an add-on installed that way. Users *are* giving consent by
choosing to install the add-on.

> But if anyone has suggested restricting first-party installs, I've
> missed it, and I disagree with it. I'll repeat what I said in
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227#c29:
>
> "IMO, the single most important thing when it comes to add-ons is user
> control: a user should be able to run exactly the add-ons they want,
> no more and no less. Third-party installs completely violate that
> principle. So I think the FF8 check was a great improvement, but that
> it's still too easy for a user to agree to a third-party installation
> request without understanding it what they're agreeing to and thus end
> up enabling an add-on they didn't ask for."
>
> Principles 4 and 5 from the Mozilla Manifesto are relevant here:
>
> 4. Individuals' security on the Internet is fundamental and cannot be
> treated as optional.

We have the blocklist for this, and it has protected users well in the
past. I don't think the Zynga Toolbar or the McAfee add-on cases that
triggered these discussions fall into this category. Do you?

> 5. Individuals must have the ability to shape their own experiences on
> the Internet.

By placing limitations on the way add-on developers distribute their
add-ons online, we are limiting that ability, for the sake of user
experience.

Asa has already described very well what the tradeoff is in this
discussion: how much do we want to limit what all users can install
externally, so that some users are protected from installing things they
didn't intend to install?

Our current policy is to maximize the ability of capable users to shape
their experiences at the expense of less capable users who install
things unknowingly, even when presented with the choice not to. We have
the blocklist as a mitigation mechanism, but we use it only in clear
cases of malicious intent or severe instability.

The proposal is to shift the balance of this policy to give better
protection for those users who end up with unexpected add-ons, at the
expense of those who might want to create, distribute or install add-ons
outside of our control.

If there's an adequate solution that doesn't change this balance, I
haven't heard it yet. My opinion is that the current policy does a
better job of fostering an active and diverse community than the
alternative, and moving to a more controlled approach will lead to a
decline in add-on development.


> (And third-party installs are why iPhone analogies are misleading.
> AFAIK the iPhone has nothing like a third-party install -- if you
> install app A it can't change the behaviour of app B.)
>
>
>> You're assuming that data comes only from Firefox 8+ users, which is wrong.
>> You're also assuming that all of those add-on installations are enabled,
>> which is also not true. In fact, the opt-in screen you get after upgrading
>> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
>> that data provides no insight into how effective that feature was.
>
> Ah, that's useful to know. Indeed, the FF8 opt-in check is central to
> this whole discussion, because it sets precedent -- it's clear that
> agreement was reached that the third-party installation situation was
> unacceptable, and something was done about it (I think
> https://bugzilla.mozilla.org/show_bug.cgi?id=476430 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=596343 were the relevant
> bugs).
>
> So the question is now: was the FF8 opt-in check enough? I asked
> earlier in the thread if we had any data on its effect. Do we? If we
> do and it says, for example, that 90% of third-party add-ons got
> disabled, then we don't have much of a problem. (Well, there's still
> the "how do I uninstall add-on X?" problem.)
>
> But without that data we're just going to end up arguing in circles.

Agreed. I don't have that data, and I don't know if anyone has been
tracking this.

- Jorge

Jorge Villalobos

unread,
Mar 1, 2012, 6:45:29 PM3/1/12
to Nicholas Nethercote, Brian Smith, dev-pl...@lists.mozilla.org
On 3/1/12 5:24 PM, Nicholas Nethercote wrote:
> On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos<jo...@mozilla.com> wrote:
>>
>> Requiring all add-ons to go through a review or certification process
>> conducted by us before they are installable, or "easily" installable is not
>> that far from the level of control that Apple exerts over iOS developers.
>> The only real difference would be that we would allow them to distribute
>> their add-ons elsewhere, as long as we approve of them.
>>
>> At least that's what some people are proposing, so I don't think that
>> comparison is that far-fetched or unproductive.
>
> Which "some people"? I think you're conflating third-party installs
> with first-party installs. "Some people" have been suggesting we
> restrict third-party installs, e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227.

I might be misinterpreting some of the comments in that bug and in this
discussion, but it can be hard to track who's talking about what, and
who meant "third party" in which context.

You should be aware, though, that the technical solutions that are being
proposed, like requiring all add-ons to be signed or reviewed by us,
would be very difficult to implement in such a limited context, and can
be easily manipulated by those installing software in your computer. For
example, they could just launch Firefox with the installation page for
their add-on, instead of externally installing it. Since we are trying
to protect users who just click through anything without reading, I
don't see how that wouldn't work for them, and I don't see why we would
block an add-on installed that way. Users *are* giving consent by
choosing to install the add-on.

> But if anyone has suggested restricting first-party installs, I've
> missed it, and I disagree with it. I'll repeat what I said in
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227#c29:
>
> "IMO, the single most important thing when it comes to add-ons is user
> control: a user should be able to run exactly the add-ons they want,
> no more and no less. Third-party installs completely violate that
> principle. So I think the FF8 check was a great improvement, but that
> it's still too easy for a user to agree to a third-party installation
> request without understanding it what they're agreeing to and thus end
> up enabling an add-on they didn't ask for."
>
> Principles 4 and 5 from the Mozilla Manifesto are relevant here:
>
> 4. Individuals' security on the Internet is fundamental and cannot be
> treated as optional.

We have the blocklist for this, and it has protected users well in the
past. I don't think the Zynga Toolbar or the McAfee add-on cases that
triggered these discussions fall into this category. Do you?

> 5. Individuals must have the ability to shape their own experiences on
> the Internet.

By placing limitations on the way add-on developers distribute their
add-ons online, we are limiting that ability, for the sake of user
experience.

Asa has already described very well what the tradeoff is in this
discussion: how much do we want to limit what all users can install
externally, so that some users are protected from installing things they
didn't intend to install?

Our current policy is to maximize the ability of capable users to shape
their experiences at the expense of less capable users who install
things unknowingly, even when presented with the choice not to. We have
the blocklist as a mitigation mechanism, but we use it only in clear
cases of malicious intent or severe instability.

The proposal is to shift the balance of this policy to give better
protection for those users who end up with unexpected add-ons, at the
expense of those who might want to create, distribute or install add-ons
outside of our control.

If there's an adequate solution that doesn't change this balance, I
haven't heard it yet. My opinion is that the current policy does a
better job of fostering an active and diverse community than the
alternative, and moving to a more controlled approach will lead to a
decline in add-on development.


> (And third-party installs are why iPhone analogies are misleading.
> AFAIK the iPhone has nothing like a third-party install -- if you
> install app A it can't change the behaviour of app B.)
>
>
>> You're assuming that data comes only from Firefox 8+ users, which is wrong.
>> You're also assuming that all of those add-on installations are enabled,
>> which is also not true. In fact, the opt-in screen you get after upgrading
>> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
>> that data provides no insight into how effective that feature was.
>
> Ah, that's useful to know. Indeed, the FF8 opt-in check is central to
> this whole discussion, because it sets precedent -- it's clear that
> agreement was reached that the third-party installation situation was
> unacceptable, and something was done about it (I think
> https://bugzilla.mozilla.org/show_bug.cgi?id=476430 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=596343 were the relevant
> bugs).
>
> So the question is now: was the FF8 opt-in check enough? I asked
> earlier in the thread if we had any data on its effect. Do we? If we
> do and it says, for example, that 90% of third-party add-ons got
> disabled, then we don't have much of a problem. (Well, there's still
> the "how do I uninstall add-on X?" problem.)
>
> But without that data we're just going to end up arguing in circles.

Asa Dotzler

unread,
Mar 1, 2012, 11:37:17 PM3/1/12
to
On 3/1/2012 3:45 PM, Jorge Villalobos wrote:
> Asa has already described very well what the tradeoff is in this
> discussion: how much do we want to limit what all users can install
> externally, so that some users are protected from installing things they
> didn't intend to install?
>
> Our current policy is to maximize the ability of capable users to shape
> their experiences at the expense of less capable users who install
> things unknowingly

I think this is the wrong balance. I would prefer that we put an
additional burden on "capable" users -- those most able to deal with the
burden, to protect those less capable who end up with add-ons they
didn't knowingly install.

> The proposal is to shift the balance of this policy to give better
> protection for those users who end up with unexpected add-ons, at the
> expense of those who might want to create, distribute or install add-ons
> outside of our control.

Yes. Precisely.

> My opinion is that the current policy does a
> better job of fostering an active and diverse community than the
> alternative, and moving to a more controlled approach will lead to a
> decline in add-on development.

This is another point that we're not discussing enough. You clearly want
to optimize for add-on developers while I and others on this thread want
to optimize for our users.

If we have to slow the growth or even shrink the size of our add-on
developer community (losing those few developers who are unwilling to
work with us to better help our users) in order to protect our users
from unwanted add-ons, I think that's completely appropriate.

I realize that this is not what you and other add-on development
evangelists and add-on authors want to hear, but our mission clearly
puts the user first.

- A

Jorge Villalobos

unread,
Mar 2, 2012, 11:42:48 AM3/2/12
to Asa Dotzler
On 3/1/12 10:37 PM, Asa Dotzler wrote:
> On 3/1/2012 3:45 PM, Jorge Villalobos wrote:
>> My opinion is that the current policy does a
>> better job of fostering an active and diverse community than the
>> alternative, and moving to a more controlled approach will lead to a
>> decline in add-on development.
>
> This is another point that we're not discussing enough. You clearly want
> to optimize for add-on developers while I and others on this thread want
> to optimize for our users.

Not only optimizing for developers, but also giving more choice for the
users who install these developers' add-ons. It's worth reiterating that
there are users on both sides of this scale.

> If we have to slow the growth or even shrink the size of our add-on
> developer community (losing those few developers who are unwilling to
> work with us to better help our users) in order to protect our users
> from unwanted add-ons, I think that's completely appropriate.

The might be unwilling to work with us for many other reasons than "not
caring about our users". I deal with the frustration many developers
have to go through in order to list their add-ons on AMO on a daily
basis. While for the most part they appreciate our input and our free
publishing and distribution platform, many have to deal with constant
delays and seemingly arbitrary policies. I defend our right to do that
on our site, but I also defend the right of others to deal with their
self-hosted add-ons in their own terms.

I also question the effectiveness of us protecting users who are clearly
incapable of understanding visual cues. If you look at the
Trillian/Ask.com video, the user is presented with 2 different
opportunities not to install this toolbar. Those who installed it and
later complained about it clearly don't understand what they did, and I
don't see how we can create any technical limitations to protect these
users short of closing Firefox for everything except AMO. Half-measures
are easily to work around, and continuing with the cat and mouse game
will do little to protect our mainstream users, while harming the more
knowledgeable ones and our developer community.

- Jorge

Justin Lebar

unread,
Mar 2, 2012, 12:13:31 PM3/2/12
to Jorge Villalobos, dev-pl...@lists.mozilla.org
> Users *are* giving consent by choosing to install the add-on.

I disagree. This is misconception is key to understanding those of us
who want tighter restrictions on drive-by add-ons.

Let's put aside what "consent" means and agree that strict "clicked
OK" is not the bar we want to set for users' "consent". What we want
is *informed* consent.

Like I said earlier, I think a user can give informed consent to
install an add-on by either:

a) Reading the add-ons source code, or
b) Understanding the risk of installing the add-on and
b.1) explicitly delegating trust for the add-on's evaluation to a
third-party (e.g. Mozilla), or
b.2) explicitly choosing to trust the add-on itself.

Users are not giving informed consent under the current scheme.

Again, consider the bogus-SSL cert page. A dialog saying "This cert
is bad. Continue? [Yes] [No]" would explicitly *not* be sufficient to
get informed consent from a user. That's why we have this complex
click-through page -- we have to inform before we get consent.

Justin Lebar

unread,
Mar 2, 2012, 12:24:01 PM3/2/12
to Jorge Villalobos, Asa Dotzler, Nicholas Nethercote, dev-pl...@lists.mozilla.org
I'd like to move this thread towards a conclusion, if I can. We've
reached the point of almost exclusively rehashing old arguments, and
that's a waste of everyone's time.

The goal is not to get everyone in the debate to agree. The pros and
cons of the various options at our disposal have been well laid out;
now module owners need to make a decision.

It seems to me that those on the Firefox / Gecko side are in favor of
tighter controls of drive-by add-ons; in particular, Asa is the
ranking owner on the Firefox side, and he's in favor of this. I'd
love to have the add-ons team on-board with whatever we do in Firefox,
because we'll be able to design a better experience for users if we
could, for example, use the add-ons team's expertise to help us
distinguish between "good" and "bad" drive-by add-ons. But this is
not a requirement for us to take action in Firefox.

Asa, can we file a bug and start thinking technically about how we
want to implement the changes you think we should implement?

-Justin

Robert Kaiser

unread,
Mar 2, 2012, 12:35:49 PM3/2/12
to
Asa Dotzler schrieb:
> If we want to
> protect users from add-ons they do not want, we will necessarily have to
> make it a bit more difficult to get some of the non-AMO add-ons they do
> want.

If you read carefully those statements where I proposed anything we
could do, that's exactly what I was proposing (disabling non-AMO-hosted
add-on installation by default, possibly displaying a
cert-warning/exception-style UI if that default is being changed and an
installation is being made).

I also think that we should improve the installation experience of
AMO-hosted add-ons, but that's yet another discussion.

Robert Kaiser

Asa Dotzler

unread,
Mar 2, 2012, 1:01:36 PM3/2/12
to
On 3/2/2012 8:42 AM, Jorge Villalobos wrote:
> I also question the effectiveness of us protecting users who are clearly
> incapable of understanding visual cues. If you look at the
> Trillian/Ask.com video, the user is presented with 2 different
> opportunities not to install this toolbar. Those who installed it and
> later complained about it clearly don't understand what they did, and I
> don't see how we can create any technical limitations to protect these
> users short of closing Firefox for everything except AMO. Half-measures
> are easily to work around, and continuing with the cat and mouse game
> will do little to protect our mainstream users, while harming the more
> knowledgeable ones and our developer community.

I think we should make AMO more attractive and make not-AMO a lot less
attractive. There is no perfect solution here but we can and should do
more to help users who are getting add-ons they don't want -- even if
that makes things somewhat more difficult for add-on authors who don't
wan to jump through our AMO hoops.

- A

Asa Dotzler

unread,
Mar 2, 2012, 1:03:43 PM3/2/12
to
Great! We're on the same page then. I do have plans (working through
them with Unfocused and Mcoates) to make the AMO experience much better.

- A

Dave Townsend

unread,
Mar 2, 2012, 1:09:02 PM3/2/12
to
On 03/02/12 09:24, Justin Lebar wrote:
> I'd like to move this thread towards a conclusion, if I can. We've
> reached the point of almost exclusively rehashing old arguments, and
> that's a waste of everyone's time.
>
> The goal is not to get everyone in the debate to agree. The pros and
> cons of the various options at our disposal have been well laid out;
> now module owners need to make a decision.

Could you summarise those options for us please, I'm having trouble
finding actual concrete options in this giant thread.

> It seems to me that those on the Firefox / Gecko side are in favor of
> tighter controls of drive-by add-ons; in particular, Asa is the
> ranking owner on the Firefox side, and he's in favor of this.

I am not the module owner of the extension manager any longer, but I am
still the toolkit owner, and I'm against tighter controls right now. I
haven't heard the current module owner of the extension manager give any
input yet.

> I'd
> love to have the add-ons team on-board with whatever we do in Firefox,
> because we'll be able to design a better experience for users if we
> could, for example, use the add-ons team's expertise to help us
> distinguish between "good" and "bad" drive-by add-ons. But this is
> not a requirement for us to take action in Firefox.

I disagree here. We can't give users any more information to make
decisions about what add-ons they should use without this. The only way
this isn't a requirement is if you just want to block third-party
add-ons entirely.

> Asa, can we file a bug and start thinking technically about how we
> want to implement the changes you think we should implement?

I think what has come out of this thread is that we don't actually know
if we need to take action yet. There has been a lot of pointing at the
list of the top 100 add-ons that users have installed but we've shown
that we don't actually know what percentage of those are actually
enabled. I think we need to get that data before we start talking about
making any changes.

Justin Lebar

unread,
Mar 2, 2012, 1:39:14 PM3/2/12
to Dave Townsend, dev-pl...@lists.mozilla.org
>> I'd
>> love to have the add-ons team on-board with whatever we do in Firefox,
>> because we'll be able to design a better experience for users if we
>> could, for example, use the add-ons team's expertise to help us
>> distinguish between "good" and "bad" drive-by add-ons.  But this is
>> not a requirement for us to take action in Firefox.
>
> I disagree here. We can't give users any more information to make decisions
> about what add-ons they should use without this. The only way this isn't a
> requirement is if you just want to block third-party add-ons entirely.

I think the proposal is to change the flow that happens when a
drive-by add-on is installed, so that users have to give informed
consent in order to install the add-on.

At least, that's what I propose based on the discussion here. It
doesn't require any changes from the add-ons team, because the flow
would be the same for all add-ons. At a later date, if AMO wanted to
help us identify "trusted" drive-by add-ons, maybe we'd do something
with that data to make those add-ons easier to install.


I'm working on getting the data on active add-ons. We're not
collecting it through telemetry, it seems, but we should be able to
change that. It'll take some weeks before we have reliable data,
though. I don't think that should block us on starting to make this
change, though: It strikes me as unlikely that once we restrict to
active add-ons, *all* of the greyware/malware will disappear from our
list.

Dave Townsend

unread,
Mar 2, 2012, 1:47:57 PM3/2/12
to
On 03/02/12 10:39, Justin Lebar wrote:
>>> I'd
>>> love to have the add-ons team on-board with whatever we do in Firefox,
>>> because we'll be able to design a better experience for users if we
>>> could, for example, use the add-ons team's expertise to help us
>>> distinguish between "good" and "bad" drive-by add-ons. But this is
>>> not a requirement for us to take action in Firefox.
>>
>> I disagree here. We can't give users any more information to make decisions
>> about what add-ons they should use without this. The only way this isn't a
>> requirement is if you just want to block third-party add-ons entirely.
>
> I think the proposal is to change the flow that happens when a
> drive-by add-on is installed, so that users have to give informed
> consent in order to install the add-on.
>
> At least, that's what I propose based on the discussion here. It
> doesn't require any changes from the add-ons team, because the flow
> would be the same for all add-ons. At a later date, if AMO wanted to
> help us identify "trusted" drive-by add-ons, maybe we'd do something
> with that data to make those add-ons easier to install.

Users already have to give consent to these add-ons. What more
information do you expect to be able to give them?

> I'm working on getting the data on active add-ons. We're not
> collecting it through telemetry, it seems, but we should be able to
> change that. It'll take some weeks before we have reliable data,
> though. I don't think that should block us on starting to make this
> change, though: It strikes me as unlikely that once we restrict to
> active add-ons, *all* of the greyware/malware will disappear from our
> list.

Unlikely yes, but we should be taking a measured response based on an
understanding of the scale of the problem we are facing rather than
rushing to cause problems for those that play by the rules already.

David Mason

unread,
Mar 2, 2012, 2:12:34 PM3/2/12
to
On 03/02/2012 01:47 PM, Dave Townsend wrote:

> Unlikely yes, but we should be taking a measured response based on an
> understanding of the scale of the problem we are facing rather than
> rushing to cause problems for those that play by the rules already.

I have to agree with what Dave said. We have 3rd parties who act in good
faith and provide functionality that many users want and appreciate. We
should understand the issues and scale *completely* before trying to
push something as fast as we can.


Dave Mason

Justin Lebar

unread,
Mar 2, 2012, 2:58:17 PM3/2/12
to Dave Townsend, dev-platform
On the question of,

> Users already have to give consent to these add-ons. What more information do you expect to be able to give them?

I wrote to Dave privately and pointed him to my previous posts about
the criteria I'd say need to be met in order for a user to consent to
installing an add-on. Dave told me these weren't sufficient, so here
we are:

> You've said below that the only way users can give informed
> consent is if we either show them the add-ons source (I would disagree with
> this, users can't read source code)

Agreed, users can't read source code. I'm just saying that a user
*could* give informed consent after having read the source. But this
isn't the only way to give informed consent, naturally.

> delegate trust to Mozilla (but you've
> said we don't need the add-ons team to be involved with these changes) or

Right, we can't do this without the add-ons team.

> "explicitly choosing to trust the add-on itself". I really have no idea how
> you expect to solicit the latter.

Thus this is the only option I have left. And like I've said, I'd
want to make this expression of trust explicit by making the dialog
"scarier". I'm sure we'd spend a lot of timing considering exactly
what threats the dialog would call out, but for the purposes of
illustration, we could say something like:

"If you enable this add on, it could

* Track everything you do within Firefox, including your passwords,
even when you're on a secure site like your bank
* Redirect your Google searches to another search engine
* Cause Firefox to run slowly or crash
* Mess up Firefox, so it doesn't work properly even after you disable the add-on

Mozilla has verified that [name of add-on] is safe. If you are not
100% sure you trust [name of add-on provider], we recommends you not
enable it.

[Get me outta here!] [Okay, I'm sure]"

But again, let's not get hung up on exactly these words.

Dave Townsend

unread,
Mar 2, 2012, 3:02:48 PM3/2/12
to
On 03/02/12 11:58, Justin Lebar wrote:
>> "explicitly choosing to trust the add-on itself". I really have no idea how
>> you expect to solicit the latter.
>
> Thus this is the only option I have left. And like I've said, I'd
> want to make this expression of trust explicit by making the dialog
> "scarier". I'm sure we'd spend a lot of timing considering exactly
> what threats the dialog would call out, but for the purposes of
> illustration, we could say something like:
>
> "If you enable this add on, it could
>
> * Track everything you do within Firefox, including your passwords,
> even when you're on a secure site like your bank
> * Redirect your Google searches to another search engine
> * Cause Firefox to run slowly or crash
> * Mess up Firefox, so it doesn't work properly even after you disable the add-on
>
> Mozilla has verified that [name of add-on] is safe. If you are not
> 100% sure you trust [name of add-on provider], we recommends you not
> enable it.
>
> [Get me outta here!] [Okay, I'm sure]"
>
> But again, let's not get hung up on exactly these words.

It's exactly the use of words like this that will alienate some of the
third-parties that we work extremely closely with, which is why I
wouldn't like to see us make such changes blindly.

Dave Townsend

unread,
Mar 2, 2012, 3:05:23 PM3/2/12
to
On 03/02/12 10:39, Justin Lebar wrote:
> I'm working on getting the data on active add-ons. We're not
> collecting it through telemetry, it seems, but we should be able to
> change that. It'll take some weeks before we have reliable data,
> though. I don't think that should block us on starting to make this
> change, though: It strikes me as unlikely that once we restrict to
> active add-ons, *all* of the greyware/malware will disappear from our
> list.

Waiting a few weeks seems totally fine to me btw. We should be taking at
least that long to think carefully about what changes we make here. It
would also be quite important to get the install date of the enabled
add-ons here. Data about those installed after the user got the opt-in
controls in Firefox 8 will be most useful in helping us understand the
problems with the current messaging.

Justin Lebar

unread,
Mar 2, 2012, 3:17:26 PM3/2/12
to Dave Townsend, dev-pl...@lists.mozilla.org
> Mozilla has verified that [name of add-on] is safe.

Er, "Mozilla has **not** verified that [name of add-on] is safe".

> It's exactly the use of words like this that will alienate some of the
> third-parties that we work extremely closely with, which is why I wouldn't
> like to see us make such changes blindly.

I'll work on getting us this data. But it is not, IMO, essential to
this debate. We know that there are going to be a bunch of
questionable add-ons in the top 100 list. We know there's going to be
malware. The question is only whether it's going to be "some" or "a
lot". But even if the problem were just "some", we'd still want to do
something about it. Every user is worth protecting.

So perhaps we can consider this: If we work closely with some parties,
then couldn't we ask for them to give us access to pre-release
binaries and/or source? Then we *could* verify that the add-on is
safe. Then we *could*, in good faith, display a less scary message to
users.

As is, we do no testing on non-AMO add-ons. We know that they can, at
the very least, cause performance issues. The message I floated
earlier is, at the moment, the best we can honestly say about any
add-on, even those from our close partners.

Could we agree on making the message scarier for un-vetted add-ons
while adding a less-scary message for add-ons we've vetted?

Dave Townsend

unread,
Mar 2, 2012, 3:46:48 PM3/2/12
to
On 03/02/12 12:17, Justin Lebar wrote:
>> Mozilla has verified that [name of add-on] is safe.
>
> Er, "Mozilla has **not** verified that [name of add-on] is safe".
>
>> It's exactly the use of words like this that will alienate some of the
>> third-parties that we work extremely closely with, which is why I wouldn't
>> like to see us make such changes blindly.
>
> I'll work on getting us this data. But it is not, IMO, essential to
> this debate. We know that there are going to be a bunch of
> questionable add-ons in the top 100 list. We know there's going to be
> malware. The question is only whether it's going to be "some" or "a
> lot". But even if the problem were just "some", we'd still want to do
> something about it. Every user is worth protecting.

Yes every user is worth protecting, assuming that we can do so in a way
that doesn't harm more users. I believe it is in the best interests of
our users for us to maintain a close working relationship with as many
of the third-parties as we can. Making their release process harder,
making it harder for their users to use their add-ons hampers that. If
it comes down to a choice between being able to work with, say, McAfee
to help them solve a memory leak in their add-on and letting a few bad
add-on installs through (that we can blocklist) then I fall on the side
of the number of affected users, and we don't have that information.
True it isn't black and white like this, but we don't even know the
levels of grey at this point.

> So perhaps we can consider this: If we work closely with some parties,
> then couldn't we ask for them to give us access to pre-release
> binaries and/or source? Then we *could* verify that the add-on is
> safe. Then we *could*, in good faith, display a less scary message to
> users.

We should reach out and see if they would be willing to do this (this of
course requires the add-ons team's involvement) and we should evaluate
the costs of us doing it.

> As is, we do no testing on non-AMO add-ons. We know that they can, at
> the very least, cause performance issues. The message I floated
> earlier is, at the moment, the best we can honestly say about any
> add-on, even those from our close partners.
>
> Could we agree on making the message scarier for un-vetted add-ons
> while adding a less-scary message for add-ons we've vetted?

We can talk honestly all we like, but I think the message that users
would take away from a message such as you propose is that Mozilla has
determined that this particular add-on includes the functionality you're
describing. Yes, you just made that up on the spot so sure it needs
changing but I'm not sure how we can make specific warnings like that
without users misunderstanding them. A challenge for the UX team to be sure.

Jorge Villalobos

unread,
Mar 2, 2012, 3:58:03 PM3/2/12
to Justin Lebar, Dave Townsend, dev-pl...@lists.mozilla.org
On 3/2/12 2:17 PM, Justin Lebar wrote:
> I'll work on getting us this data. But it is not, IMO, essential to
> this debate. We know that there are going to be a bunch of
> questionable add-ons in the top 100 list. We know there's going to be
> malware. The question is only whether it's going to be "some" or "a
> lot". But even if the problem were just "some", we'd still want to do
> something about it. Every user is worth protecting.

Malware (as in, /real/ malware) is handled through the blocklist, and we
shouldn't expect such software to abide by our rules and present itself
through the third-party install dialog.

As far as I understand this discussion is about externally-installed
add-ons that users may not want to install but end up installing anyway.
Coming up with a language we can all agree with about what we're trying
to address and what we're not would help narrow down and understand the
problem, I think.

Here's a suggestion:

* Malware add-ons - installed with malicious intent and aimed to disrupt
a user's system or steal their data.

* Greyware add-ons - push users into getting themselves installed and/or
change user defaults and/or violate other privacy or choice policies we
enforce on AMO.

* Non-AMO add-ons - all add-ons distributed outside of AMO.

* Externally-installed add-ons - installed from an EXE, MSI or other
installer file. Normally handled by Firefox with an opt-in screen.

- Jorge

Jorge Villalobos

unread,
Mar 2, 2012, 3:58:03 PM3/2/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Dave Townsend
On 3/2/12 2:17 PM, Justin Lebar wrote:
> I'll work on getting us this data. But it is not, IMO, essential to
> this debate. We know that there are going to be a bunch of
> questionable add-ons in the top 100 list. We know there's going to be
> malware. The question is only whether it's going to be "some" or "a
> lot". But even if the problem were just "some", we'd still want to do
> something about it. Every user is worth protecting.

Justin Lebar

unread,
Mar 2, 2012, 4:07:39 PM3/2/12
to Dave Townsend, dev-pl...@lists.mozilla.org
>> So perhaps we can consider this: If we work closely with some parties,
>> then couldn't we ask for them to give us access to pre-release
>> binaries and/or source?  Then we *could* verify that the add-on is
>> safe.  Then we *could*, in good faith, display a less scary message to
>> users.
>
> We should reach out and see if they would be willing to do this (this of
> course requires the add-ons team's involvement) and we should evaluate the
> costs of us doing it.

Jorge, do you agree with this in principal? Are you willing to reach
out to our partners and ask if this would be acceptable to them?

Jorge Villalobos

unread,
Mar 2, 2012, 5:13:28 PM3/2/12
to Justin Lebar, Dave Townsend, dev-pl...@lists.mozilla.org
Reaching out to them would be Kev's responsibility, since he's the one
with most of the contacts.

As I have stated before, I'm all for offering non-AMO developers a way
for them to get their add-on reviewed by us, as long as it is not an
obligation and it doesn't change the install experience of their add-on
(if we were to eventually sign reviewed add-ons, I'd be OK if we signed
them and the install dialog said "Reviewed by Mozilla" or something like
that). Having a schedule where they send us a pre-release version and we
can review their add-on with enough time for them to make changes would
be ideal. I also believe the extra workload for reviewers would be
fairly small.

That's something I can discuss with fligtar next week when he's back
from MWC, on top of many other things that have been brought up in this
discussion.

- Jorge

Jorge Villalobos

unread,
Mar 2, 2012, 5:13:28 PM3/2/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Dave Townsend

Justin Lebar

unread,
Mar 2, 2012, 5:55:06 PM3/2/12
to Jorge Villalobos, dev-pl...@lists.mozilla.org, Dave Townsend
> As I have stated before, I'm all for offering non-AMO developers a way for
> them to get their add-on reviewed by us, as long as it is not an obligation
> and it doesn't change the install experience of their add-on (if we were to
> eventually sign reviewed add-ons, I'd be OK if we signed them and the
> install dialog said "Reviewed by Mozilla" or something like that).

Specifically, I'm proposing that

* If the add-on is un-reviewed, we display a scary dialog
* If the add-on is reviewed, we display a less-scary dialog

Would this count as "changing the install experience of the add-on"?

> Having a
> schedule where they send us a pre-release version and we can review their
> add-on with enough time for them to make changes would be ideal

Agreed.

> I also
> believe the extra workload for reviewers would be fairly small.

Awesome!

> That's something I can discuss with fligtar next week when he's back from
> MWC, on top of many other things that have been brought up in this
> discussion.

We eagerly await. :)

Jorge Villalobos

unread,
Mar 2, 2012, 6:27:24 PM3/2/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Dave Townsend
On 3/2/12 4:55 PM, Justin Lebar wrote:
>> As I have stated before, I'm all for offering non-AMO developers a way for
>> them to get their add-on reviewed by us, as long as it is not an obligation
>> and it doesn't change the install experience of their add-on (if we were to
>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>> install dialog said "Reviewed by Mozilla" or something like that).
>
> Specifically, I'm proposing that
>
> * If the add-on is un-reviewed, we display a scary dialog
> * If the add-on is reviewed, we display a less-scary dialog
>
> Would this count as "changing the install experience of the add-on"?

Yes, that is exactly what I mean.

In my opinion, *all* add-on installs need at least one warning that says
you're installing software in your computer and that carries some risk.
This includes add-ons that we review.

Just because we have reviewed them doesn't imply that nothing wrong can
happen. Mistakes can happen during review. Things can be overlooked. We
can't guarantee that everything will be fine, and therefore users should
always get a fair warning.

For externally-installed add-ons, we need a second warning (which we
already have). Do we need more? I don't think so. However, we first need
to study the Firefox 8+ data to be sure. Like I said in my previous
comment, I'd be OK with adding a note that indicates the add-on was
reviewed by us in order to give users some extra assurance to opt-in.
I'm not OK making the opt-in scarier just because we didn't look at the
file.

- Jorge

Jorge Villalobos

unread,
Mar 2, 2012, 6:27:24 PM3/2/12
to Justin Lebar, dev-pl...@lists.mozilla.org, Dave Townsend
On 3/2/12 4:55 PM, Justin Lebar wrote:
>> As I have stated before, I'm all for offering non-AMO developers a way for
>> them to get their add-on reviewed by us, as long as it is not an obligation
>> and it doesn't change the install experience of their add-on (if we were to
>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>> install dialog said "Reviewed by Mozilla" or something like that).
>
> Specifically, I'm proposing that
>
> * If the add-on is un-reviewed, we display a scary dialog
> * If the add-on is reviewed, we display a less-scary dialog
>
> Would this count as "changing the install experience of the add-on"?

Asa Dotzler

unread,
Mar 2, 2012, 8:17:39 PM3/2/12
to
We've been saying that for 3 years now and every year it's getting worse
and worse.

- A

Asa Dotzler

unread,
Mar 2, 2012, 8:21:38 PM3/2/12
to
On 3/2/2012 12:17 PM, Justin Lebar wrote:
>> Mozilla has verified that [name of add-on] is safe.
>
> Er, "Mozilla has **not** verified that [name of add-on] is safe".
>
>> It's exactly the use of words like this that will alienate some of the
>> third-parties that we work extremely closely with, which is why I wouldn't
>> like to see us make such changes blindly.
>
> I'll work on getting us this data. But it is not, IMO, essential to
> this debate. We know that there are going to be a bunch of
> questionable add-ons in the top 100 list. We know there's going to be
> malware. The question is only whether it's going to be "some" or "a
> lot". But even if the problem were just "some", we'd still want to do
> something about it. Every user is worth protecting.
>
> So perhaps we can consider this: If we work closely with some parties,
> then couldn't we ask for them to give us access to pre-release
> binaries and/or source? Then we *could* verify that the add-on is
> safe. Then we *could*, in good faith, display a less scary message to
> users.
>
> As is, we do no testing on non-AMO add-ons. We know that they can, at
> the very least, cause performance issues. The message I floated
> earlier is, at the moment, the best we can honestly say about any
> add-on, even those from our close partners.
>
> Could we agree on making the message scarier for un-vetted add-ons
> while adding a less-scary message for add-ons we've vetted?

I fully support this approach.

- A

Asa Dotzler

unread,
Mar 2, 2012, 8:28:32 PM3/2/12
to
This seems completely wrong to me. It sounds like something from one of
those other companies. We should not put the success of commercial
entities like McAfee ahead of our users. If McAfee stops working with us
because we put the well-being of our users over their bottom line, then
let them walk. On the other hand, if they want badly enough to
piggy-back on our market penetration they'll come into the fold and work
with us, and we can get them into a low-friction installation path.

>> So perhaps we can consider this: If we work closely with some parties,
>> then couldn't we ask for them to give us access to pre-release
>> binaries and/or source? Then we *could* verify that the add-on is
>> safe. Then we *could*, in good faith, display a less scary message to
>> users.
>
> We should reach out and see if they would be willing to do this (this of
> course requires the add-ons team's involvement) and we should evaluate
> the costs of us doing it.

The cost is "do we care enough about that particular add-on to do the
review work to ensure it's safe for our users" just like any other
add-on that goes through AMO. We're blowing add-on review hours at AMO
on add-ons with no users and no future. Surely that time could be doled
out to higher profile add-ons from cooperating vendors. I'd make that
trade just about any day of the week.

- A

Asa Dotzler

unread,
Mar 2, 2012, 8:44:08 PM3/2/12
to
On 3/2/2012 3:27 PM, Jorge Villalobos wrote:
> On 3/2/12 4:55 PM, Justin Lebar wrote:
>>> As I have stated before, I'm all for offering non-AMO developers a
>>> way for
>>> them to get their add-on reviewed by us, as long as it is not an
>>> obligation
>>> and it doesn't change the install experience of their add-on (if we
>>> were to
>>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>>> install dialog said "Reviewed by Mozilla" or something like that).
>>
>> Specifically, I'm proposing that
>>
>> * If the add-on is un-reviewed, we display a scary dialog
>> * If the add-on is reviewed, we display a less-scary dialog
>>
>> Would this count as "changing the install experience of the add-on"?
>
> Yes, that is exactly what I mean.
>
> In my opinion, *all* add-on installs need at least one warning that says
> you're installing software in your computer and that carries some risk.
> This includes add-ons that we review.

Justin's saying "add-ons we haven't reviewed need a stronger warning
than add-ons we have reviewed" and your answer is that is not OK?

If there's any value at all in reviews, which is what I'm sure you
believe, then it should hold that the messages could be at least
somewhat different between reviewed and un-reviewed add-ons, no?

So, what this comes down to for me is the precise value our review
system offers compared to no review.

I think un-review add-ons should be scary as hell -- virtually
impossible to install for all but the most intrepid users. The warning
should list all the possible evil things the add-on could do.

I think reviewed add-ons that are closed source and can only be
evaluated based on use analysis (including perf testing, feature
testing, etc.) should have a moderate warning -- something like what we
have today.

I think add-ons that have inspect-able source and have had thorough
reviews (like what Firefox gets, for example) should be one-click
installs with no warnings.

What would your ideal warning regime be for those three cases?


> Just because we have reviewed them doesn't imply that nothing wrong can
> happen. Mistakes can happen during review. Things can be overlooked. We
> can't guarantee that everything will be fine, and therefore users should
> always get a fair warning.

Mistakes happen even in Firefox reviews. Things are sometimes
overlooked. We can never guarantee everything will be fine. But that
does not mean reviews are useless or that reviewed features are no safer
than un-reviewed features.


> For externally-installed add-ons, we need a second warning (which we
> already have). Do we need more? I don't think so. However, we first need
> to study the Firefox 8+ data to be sure. Like I said in my previous
> comment, I'd be OK with adding a note that indicates the add-on was
> reviewed by us in order to give users some extra assurance to opt-in.
> I'm not OK making the opt-in scarier just because we didn't look at the
> file.

The problem with our current opt in dialog is that it's scary but with
no information about why. That makes users abandon installs for no good
reason or agree to installs with no understanding of what they're doing.
It's not just about making it scarier. It's about making it actionable.
It needs to get helping users make good decisions.

- A

Justin Lebar

unread,
Mar 2, 2012, 9:30:35 PM3/2/12
to Jorge Villalobos, dev-pl...@lists.mozilla.org, Dave Townsend
> I'd be OK with adding a note that indicates the add-on was reviewed by us in order to give users some extra assurance to opt-in.
> I'm not OK making the opt-in scarier just because we didn't look at the file.

So basically, you're OK making it easier to install a reviewed add-on,
but not making it harder to install an un-reviewed add-on?

That's not really what I'm hoping for here.

Are there any circumstances under which you would be OK making it in
any way scarier or harder to install an add-on which we have not
explicitly found to be malicious?

I'd pose the same question to the relevant module owners in Firefox.

Dave Townsend

unread,
Mar 3, 2012, 11:02:14 AM3/3/12
to
I can't say I've recognized such a trend, perhaps you have numbers to
back that up?

Either way that doesn't in my eyes constitute a reason to jump the gun.
We have introduced a change in Firefox 8 which we think will have
improved the situation. We have a bug on file that will help us gather
data on what kind of a problem that leaves us with. We should wait for
that data before making any further changes.

Dave Townsend

unread,
Mar 3, 2012, 11:09:55 AM3/3/12
to
On 03/02/12 18:30, Justin Lebar wrote:
>> I'd be OK with adding a note that indicates the add-on was reviewed by us in order to give users some extra assurance to opt-in.
>> I'm not OK making the opt-in scarier just because we didn't look at the file.
>
> So basically, you're OK making it easier to install a reviewed add-on,
> but not making it harder to install an un-reviewed add-on?
>
> That's not really what I'm hoping for here.
>
> Are there any circumstances under which you would be OK making it in
> any way scarier or harder to install an add-on which we have not
> explicitly found to be malicious?
>
> I'd pose the same question to the relevant module owners in Firefox.

"not explicitly found to be malicious" covers all add-ons, even reviewed
ones. Assuming you just mean un-reviewed add-ons then I'd be ok with
making the dialog scarier (not way scary) but it must be done in a way
that users understand and in consultation with the third parties that we
work with
It is loading more messages.
0 new messages