Closed Bug 728227 Opened 12 years ago Closed 11 years ago

Require that third-party add-ons installed by third-party installers (not user action in Firefox) be signed by the AMO team

Categories

(addons.mozilla.org Graveyard :: Policy, defect)

Product:
addons.mozilla.org Graveyard
Component:
Policy
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: justin.lebar+bug, Unassigned)

Details

We subject add-ons installed via AMO to a rigorous screening.  But only 25% of add-on installations come from AMO [1].  For each AMO add-on a user has, she has three non-AMO add-ons.  These are not subject to any review by the AMO team, as far as I know.

For an example of the mayhem a third-party add-on can cause, see bug 727938, which has nearly the worse memory leak imaginable.

In Firefox 8, we prompted users to disable third-party add-ons.  That's great, but it's not enough.  Indeed, users should have to work very hard to install an unreviewed add-on.  That's how it is with first-party add-ons; that's how it should be with third-party add-ons.

I propose:

 * We require third-party add-ons to be reviewed by the AMO team.  Third-party add-ons should have to undergo the same scrutiny and meet the same standards of quality as AMO add-ons.

 * If a third party installs an add-on which is not signed by the AMO team, Firefox will completely ignore the add-on.  Firefox will not prompt the user to enable it on startup, and the add-on will not be listed in about:addons.

 * If a user really wants to run unsigned third-party add-ons, she can flip a pref in about:config.

Since the number of third-party add-ons is relatively small (AIUI, there are relatively few unique add-ons installed on many machines), this policy change should not create an undue burden on the AMO review system.  (But note that even if it did, I'd much rather have some add-on on AMO that nobody will use go unreviewed than have an add-on with 100 million installations go unreviewed.)

I understand that this will be a big change for the companies that ship third-party add-ons for Firefox.  But what's much more important than keeping those companies happy is ensuring that our users have a great web browsing experience.  That's why we review AMO add-ons, and that's why we should review third-party add-ons.

[1] http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-plans/
Whiteboard: [MemShrink]
Microsoft doesn't review every piece of software that runs on Windows.

Apple doesn't review every piece of software that runs on Mac.

This is the same situation.

You can't require this.
@fligtar: WONTFIX?
(In reply to Michael Kaply (mkaply) from comment #1)
> Microsoft doesn't review every piece of software that runs on Windows.

Yes, and we very much do not want to turn Firefox into Windows.  Lots of people leave Windows because it's "slow" or "crashy", when in fact, that's caused by all the crap that third parties install into Windows.

Same thing is happening to us.  It has to stop.
 
> Apple doesn't review every piece of software that runs on Mac.

Apple reviews every piece of software which runs on an iOS device, no?

> You can't require this.

Sure we can.

Again, this isn't about keeping users from installing software they want.  I'm perfectly happy for a user to install a non-AMO add-on.

On the other hand, I am not happy with someone else -- another company -- installing an un-reviewed add-on which trashes the user's browser.  I am not happy that Java Console, which has 100 million users [1], 7 times more than the most popular AMO add-on, does not have to meet the same quality standards as add-ons which have 7-times fewer users.

This is about giving users control over their browser.  This is about giving users the power to have a workable browser.  This is the very essence of what Mozilla and Firefox stand for.

[1] http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-plans/
And I wouldn't be happy with another company (Mozilla) having control over my product plans, as well as allowing people that are not employees of that company to determine my future.

If Mozilla is fighting for users, then they would want the space to be open (as it is now).

Requiring everything to go through their review closes the process.
Maybe an initial less radical step would be to do AMO-style reviews (or maybe a pared down version) of each version of the top-10 third party addons, so we can at least catch egregious problems early and report them to the company, without having to rely on user reports.  I'm not sure what sort of testing is done at Mozilla about these things already.
(In reply to Andrew McCreight [:mccr8] from comment #5)
> Maybe an initial less radical step would be to do AMO-style reviews (or
> maybe a pared down version) of each version of the top-10 third party
> addons, so we can at least catch egregious problems early and report them to
> the company, without having to rely on user reports.  I'm not sure what sort
> of testing is done at Mozilla about these things already.

You can't require that a company give you (Mozilla) their binary source code or the source to any obfuscated files.
> And I wouldn't be happy with another company (Mozilla) having control over my product plans, as well 
> as allowing people that are not employees of that company to determine my future.

I'm sorry that you wouldn't be happy about this.  But you are not our constituency.  The 400 million people who use Firefox are our constituency.

> If Mozilla is fighting for users, then they would want the space to be open (as it is now).

As bug 727938 demonstrates, the kind of "open" you're asking for leads to Firefox becoming complete shit.  It's easy to blame McAfee, but I blame us for not taking the steps necessary to protect our browser, protect our image, and protect our users.

For what it's worth, I do not think that "open" means "open for third-parties to install software into your web browser which makes it unusable."
(In reply to Michael Kaply (mkaply) from comment #6)
> You can't require that a company give you (Mozilla) their binary source code
> or the source to any obfuscated files.
Of course.  I just meant a basic "install and use the addon and see what happens" kind of check, looking at about:memory and so forth, not the full and detailed source inspection of the current AMO process.  Sorry for not being clear.
(In reply to Michael Kaply (mkaply) from comment #6)
> (In reply to Andrew McCreight [:mccr8] from comment #5)
> > Maybe an initial less radical step would be to do AMO-style reviews (or
> > maybe a pared down version) of each version of the top-10 third party
> > addons, so we can at least catch egregious problems early and report them to
> > the company, without having to rely on user reports.  I'm not sure what sort
> > of testing is done at Mozilla about these things already.
> 
> You can't require that a company give you (Mozilla) their binary source code
> or the source to any obfuscated files.

Sure we can.  If they don't, how can we verify that the add-on is not causing problems?  We require this of companies which want to host add-ons in AMO (e.g. Cooliris).

It is not your right, by virtue of having software installed on a user's computer, to install an add-on to Firefox.  How would you feel if Firefox injected code into your software which made it suck?
In case it is still not clear, the distinction I would like to make is:

 * Users may install whatever they want into their browser, same as now.
 * Companies which happen to have software installed on a user's computer may only install signed add-ons into the user's browser.

This is about giving users more control over what goes into their browser, not less.
(In reply to Justin Lebar [:jlebar] from comment #10)
>  * Companies which happen to have software installed on a user's computer
> may only install signed add-ons into the user's browser.
I think informing is better than controlling so that users are well aware of the culprit but can continue to use any add-ons they want.
There's something planned about that in the second half of 2012:
https://wiki.mozilla.org/Firefox/Features/Expose_Add-on_Performance
(In reply to Scoobidiver from comment #11)

I guess I'd like us to focus first on agreeing on what the problem is, and then we can figure out what's the right way forward.

In my mind, the problem is that third-party add-ons get zero Mozilla QA before they're released.  We carefully review every line of code which goes into Firefox, we review and test every AMO extension, and we do nothing with third-party add-ons.  That doesn't make sense.

But how do we set up a system which forces third-party add-on vendors to let us test their code before they release it?  Requiring that the AMO team sign add-ons is one solution, but maybe it's not the right one.  I'm not at all vested in this particular solution, but I do care about solving the problem.

> >  * Companies which happen to have software installed on a user's computer
> > may only install signed add-ons into the user's browser.
> I think informing is better than controlling so that users are well aware of
> the culprit but can continue to use any add-ons they want.
> There's something planned about that in the second half of 2012:
> https://wiki.mozilla.org/Firefox/Features/Expose_Add-on_Performance

Well, we can't notify users of problems with an add-on if we don't get to test it.  And testing after it's released is pretty lame -- we'd never ship untested Firefox code to 400 million people, so why do we allow untested code in the Java Console to ship to 100 million people?

But sure, maybe we should notify users that "Hey, this add-on sucks," once we're aware of a problem, instead of requiring that add-ons be signed.  This was actually something I suggested a long time ago for AMO add-ons, and the AMO team argued pretty strongly against it.  We ended up instead testing every new add-on in AMO for leaks during the review process.  Some of us still want this badlist (for add-ons which aren't getting re-reviewed) but overall, checking for leaks during review will catch more problems, so I'm happy that's where we ended up.

I see "requiring" code signing (for some meaning of the word "require") as the rough equivalent of what we did for AMO add-ons.  But maybe we should do something else.  So long as we do something!
(In reply to Justin Lebar [:jlebar] from comment #0)
> I propose:
> 
>  * We require third-party add-ons to be reviewed by the AMO team. ...
> 
>  * If a user really wants to run unsigned third-party add-ons, she can flip
> a pref in about:config.

While I agree with the sentiment, this seems too harsh. Instead I suggest:

* The first time an unsigned add-on is installed provide a disclaimer and require the user approve allowing the add-ons.

* Provide a short form on the disclaimer when approving every unsigned add-on install.

* Add a warning below each unsigned add-on in the Add-Ons Manager extension list.

* When a *specific* problem is known with a *specific* add-on version, warn the user on install and in the Add-Ons Manager extension list. (And provide information on how the add-on developer can get help addressing the problem.)

The about:config preference could have four states:

- Block and ignore unsigned add-ons.
- Block, but give the user a chance to unblock during install. (Default.)
- Allow, but warn on install. (After user approves.)
- Don't warn or require approval for each install. (Useful for developers, testers, and risk takers.)
Those of us with technical chops often think that if only we educated users more about the consequences of their actions, they'd behave more reasonably.  But in my experience, most users don't *want* their web browser to educate them.  They just want it to work.

We already warn about third-party add-ons, and I don't think that more warnings and clickthroughs are necessarily the right solution.  But I want to focus on a way to find problems in add-ons before they get into the hands of users.  Once we've agreed on a way to do that, the rest of the mechanism (be it warning or blocking or whatever) may fall into place.
(In reply to Justin Lebar [:jlebar] from comment #10)
> In case it is still not clear, the distinction I would like to make is:
> 
>  * Users may install whatever they want into their browser, same as now.
>  * Companies which happen to have software installed on a user's computer
> may only install signed add-ons into the user's browser.
> 
> This is about giving users more control over what goes into their browser,
> not less.

I think this is a very interesting proposal. We've already taken some steps to at least try to warn a user when a third party tries to slip an add-on into Firefox without asking.
Having AMO sign a third party's addons (in the traditional way of signing) would be an incorrect thing to do.

Signing asserts ownership. AMO doesn't own the addon.

Requiring third parties to sign their addons doesn't really work either, because addon signing really only asserts that you had the money to buy a cert.
Digital signatures have nothing to do with ownership.

If I digitally sign a contract, I don't own it.  If a CA signs my PGP public key, it does not own it.

A signature just means "I chose to sign this particular thing.". Anything else comes from context.
In the context of Mozilla add-ons, it does mean ownership.

When the install dialog comes up, the name next to the add-on (if it is there) indicates whose add-on it is.

You can't have all third party add-ons saying Mozilla Corp. When you install them.
(In reply to Michael Kaply (mkaply) from comment #18)
> In the context of Mozilla add-ons, it does mean ownership.
> 
> When the install dialog comes up, the name next to the add-on (if it is
> there) indicates whose add-on it is.

So we change the design of the install dialog to say "vetted by Mozilla" or similar. This is software, we can make it do what we want it to do. Pretending that we're locked into some ancient and not well designed UI is not the best defense for the point you're trying to make.
I've already made my defense.

The idea is completely unmanageable and puts every company that makes add-ons at the mercy of Mozilla Corp.

I have no interest in contributing to a community like that.

It's bad enough that AMO is so tightly integrated into Firefox that no other add-on marketplace can succeed.

To basically edict that every add-on ever built has to be vetted by Mozilla Corp. is unacceptable.

And notice I'm saying Mozilla Corp. here because if you think this would ever succeed with volunteers, that's even crazier.

Most companies are not going to be willing to hand over all their code just so some  random person can have a look.

You'll probably say "companies already do that with AMO today" but that's only companies that choose to distribute on AMO.

Unfortunately AMO policies can have an adverse effect on companies that are trying to actually earn a profit.

If this went through, I could see a world where AMO policies apply to all add-ons which would kill for profit add-on development.
(In reply to Michael Kaply (mkaply) from comment #20)

> Most companies are not going to be willing to hand over all their code just
> so some  random person can have a look.

I don't think we'd have to require code, just the add-on itself for review to make sure it doesn't hose Firefox users. We can do performance and memory tests without any source code.  

And, we can certainly let third parties continue to do this un-vetted, we'd just need to put up some very scary warnings about how third parties who don't go through Mozilla's vetting process may do very bad things to your Firefox installation.

Perhaps that's the better way. We simply make it unappealing for third parties to go the rout of not getting vetted and count on those who trust their add-ons to not screw over Firefox users to get vetted with AMO.
Well, the dialog currently has the same level of scariness regardless of the distributor. If we truly believe that AMO hosted/vetted add-ons are better, why not simply make that dialog less scary (or even nonexistent) for AMO approved add-ons?
(In reply to Michael Kaply (mkaply) from comment #22)
> Well, the dialog currently has the same level of scariness regardless of the
> distributor. If we truly believe that AMO hosted/vetted add-ons are better,
> why not simply make that dialog less scary (or even nonexistent) for AMO
> approved add-ons?

We're working on that. That's not enough :)
> In the context of Mozilla add-ons, it does mean ownership.

In the context of Mozilla add-ons, we currently only have one type of signing, indicating ownership.  But we could introduce *another* type of signing which indicates "tested".  I think we're all on the same page with this now.

> The idea is completely unmanageable and puts every company that makes add-ons at the 
> mercy of Mozilla Corp.

Right now, every Firefox user (at least, on Windows) is at the mercy of the companies that make add-ons.  That's what we saw with this McAfee hullabaloo.  So even if I accept the question you're begging, that it's wrong to put corporations which install software into Firefox at Mozilla's "mercy" -- and I categorically reject this -- which is worse, putting corporations at Mozilla's mercy, or letting Mozilla's 400 million users be at the mercy of corporations?

But anyway -- this is the categorical rejection part -- my thesis in this whole bug is that controlling what goes into Firefox is better than bad: it's good!  Like I've said before:

****

A corporation does not, by virtue of having software installed on a user's machine, have a right to install code of any kind into Firefox.  Installing code into Firefox is a privilege we can and should control, for the benefit of our users.

****

If a corporation does not like the controls we put on what they can inject into Firefox, they can build their own browser, or even ship re-branded Firefox pre-bundled with whatever add-on they want.

I'd expect that most corporations would welcome the extra layer of QA that we'd be providing for them here.  But speaking for myself here, if taking a stand here were to cause corporations who want to be able to inject arbitrary code into Firefox without Mozilla's supervision to become angry, I would be totally OK with that.  Doing the right thing by users is paramount.

> If this went through, I could see a world where AMO policies apply to all add-ons which 
> would kill for profit add-on development.

Is this because you think the for-profit add-on developers would not be willing to submit their source code, or because there are other AMO policies that for-profit add-ons violate?

If it's the latter, can you give an example of a for-profit add-on which
  (a) does something useful for users, and
  (b) would be rejected from an AMO review, even if its developers were willing to provide source?

Note that Cooliris and Adblock Plus are both for-profit and they seem to be doing just fine for themselves.  In general, my impression of the AMO guidelines is that they're in place to protect users.  If protecting users means killing some for-profit add-on development (clearly it wouldn't kill *all* for-profit add-on development, as evinced by Cooliris and ABP), that doesn't seem like a bad trade-off to me.

But maybe there are some specific points in the AMO guidelines we'd want to relax for third-party add-ons.  I wouldn't object to this in principal.

Like I've said a few times here, I'd like us to focus on the core part of this proposal, which is vetting third-party add-ons before they make it into users hands.  I'm not wed to specifics, such as requiring every third-party vendor to send us source code; I'd want to understand what kinds of mistakes that would preclude us from catching.  However, if the AMO guidelines are basically "do good by Mozilla's users", then requiring that third-party add-ons meet the AMO criteria seems like exactly what we want.
[I see that Justin replied while I was writing this, but I'll submit it anyway in case it helps clarify some things.]


(In reply to Michael Kaply (mkaply) from comment #20)
> 
> The idea is completely unmanageable and puts every company that makes
> add-ons at the mercy of Mozilla Corp.

I'm pretty certain Justin's not suggesting that.  

The suggestion he's making is nuanced enough that I had to talk to him privately to understand it.  Comment 10 is about this, but I'll attempt to explain more verbosely what he's proposing, hopefully I'll get it right:

- "Third-party" add-ons are ones that install themselves without having been requested/installed by the user within Firefox.  (E.g. when you download Java and you get the Java Console add-on dumped into Firefox.)  I think since FF8 the user has had to click on a checkbox for any such add-ons to actually be enabled.  These are the ones that Justin wants to be signed.

- Add-ons that aren't on AMO but are only installed when the user explicitly asks for them ("first-party") would be exempt from this signing requirement.

I don't know the relative frequency of these two cases.

(I'm not condoning or condemning this proposal, BTW, just trying to explain it :)
> Note that Cooliris and Adblock Plus are both for-profit and they seem to be doing just fine for themselves. 

Neither of these are for-profit add-ons. They are add-ons made by companies that make profit in other ways. I was referring to add-ons that exclusively get revenue via just the add-on. This is usually done via search and other mechanisms and in the context of installing from site other than AMO, they can use a click through license instead of AMOs policy of opt-out. You might disagree with that, and that's OK. That's why some add-ons are hosted outside of AMO.

> Add-ons that aren't on AMO but are only installed when the user explicitly asks for them ("first-party") would be exempt from this signing requirement.

That's not what is indicated by the first paragraph of this bug. He is using the term "third-party" to refer to any add-on that is not hosted on AMO. Maybe that's not what he meant, but that's what he said.

I've brought this up before that the term "third-party" is thrown around with too many different meanings.


So if you mean "add-ons that are installed by another application have to be vetted by Mozilla", that's a different conversation.

But you still have a problem.

Imagine if in order to ship Firefox, Mozilla had to have a third party company approve the release and that approval was done by volunteers on their own timetable. Would you be ok with that?

You're still asking companies to base their business plans on Mozilla's ability to review their add-ons. I understand the review queues are clear now, but that hasn't been the case in the past.
(In reply to Michael Kaply (mkaply) from comment #26)
> 
> > Add-ons that aren't on AMO but are only installed when the user explicitly asks for them ("first-party") would be exempt from this signing requirement.
> 
> That's not what is indicated by the first paragraph of this bug. He is using
> the term "third-party" to refer to any add-on that is not hosted on AMO.
> Maybe that's not what he meant, but that's what he said.

Justin told me he had assumed that the vast majority of the 75% of non-AMO installations were "third-party", i.e. installed by other software.  That may be the source of the confusion -- Justin was assuming "non-AMO" and "third-party" were almost equivalent.  This whole discussion has been confusing! :)

(I agree that "third-party" is a confusing term;  I've personally interpreted it as meaning "non-AMO add-ons" more than once.)


> So if you mean "add-ons that are installed by another application have to be
> vetted by Mozilla", that's a different conversation.

I'm pretty sure that's what Justin meant.  And it's what Asa meant in comment 15.  Can we have that conversation now? :)


> But you still have a problem.
> 
> Imagine if in order to ship Firefox, Mozilla had to have a third party
> company approve the release and that approval was done by volunteers on
> their own timetable. Would you be ok with that?
> 
> You're still asking companies to base their business plans on Mozilla's
> ability to review their add-ons. I understand the review queues are clear
> now, but that hasn't been the case in the past.

Mike, what would you think if "third-party" add-ons were simply banned?  I.e. if add-ons could only be installed when the user explicitly requests it within Firefox?  That would be a stronger proposal and it side-steps the question of whether requiring reviews is practical or not, and instead focuses on the question of how add-ons should be allowed to be installed.
(In reply to Nicholas Nethercote [:njn] from comment #27)
> Mike, what would you think if "third-party" add-ons were simply banned? 
> I.e. if add-ons could only be installed when the user explicitly requests it
> within Firefox?  That would be a stronger proposal and it side-steps the
> question of whether requiring reviews is practical or not, and instead
> focuses on the question of how add-ons should be allowed to be installed.

Then someone would find a way to sidestep the problem and fake a first party install. It wouldn't solve anything.

I prefer the method that we're taking right now. Have open communication with the third parties to help them solve their problems. That's a big part of Kev Needham's job is interacting with those companies. We should have a list of all the major third-party add-ons and contacts for their dev teams so they can be contacted if need be.


I would think that you of all people are starting to quickly realize that writing add-ons is a black art :)

The problem here isn't third-parties doing malicious things. The problem is that third-parties not knowing how to do things, so coming up with their own way of doing things and copying other people's way of doing things (which is usually wrong).

The problem is solved by helping third parties write better add-ons. Not by vilifying third-party add-ons (which Mozilla started in Firefox 8).

Third-party add-ons are not the problem. Poorly written add-ons are the problem and they can come from anywhere.
> I would think that you of all people are starting to quickly realize that
> writing add-ons is a black art :)

Yes, badly written add-ons are a huge problem.

But, 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.
All this discussion about sign-in (is it still a bug?) is finally about bad extensions/themes. We all agree we don't want bad things in Firefox, but bad has different meanings:
* Wrongly coded:
There's already planned add-on performance indicators (see https://wiki.mozilla.org/Firefox/Features/Expose_Add-on_Performance). The only missing thing in this new feature is a warning on startup as IE 9 does because not all people know AOM or will check it because of slow performance.
* Awesome bar search hijacking:
There's a planned protection against that (see https://wiki.mozilla.org/Program_Management/Projects/SearchHijacking).
* Start page/search engine hijacking:
There's nothing planned. Nevertheless, there's a SUMO article compilation about that in the start page (top topic in the support forum): https://support.mozilla.org/en-US/kb/fix-problems-your-home-page-or-search
* Unwanted toolbars, ad popups:
Nothing is planned. It's close to anti-malware protection and I don't know if Mozilla can do something.
To the first point: I don't think that allowing "wrongly-coded" add-ons to be installed and then warning the user post facto that something is wrong is appropriate.

Our goal should be to prevent such add-ons from ever being installed.  That's the point of this bug.
(In reply to Nicholas Nethercote [:njn] from comment #29)
> > I would think that you of all people are starting to quickly realize that
> > writing add-ons is a black art :)
> 
> Yes, badly written add-ons are a huge problem.
> 
> But, 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.

Just curious, are you sure they don't agree to it?

Has anyone ever installed the McAffee or Norton products and checked if they mention the browser add-ons during the install?

I find the anti-virus add-ons as annoying as the next guy, but I'm not sure there's a better way to solve that problem. The add-ons need to be present in Firefox for the stuff to work (at least I think - I don't know what they do).

If you don't install them, a user is getting less protection from their AV.
(In reply to Michael Kaply (mkaply) from comment #28)
> (In reply to Nicholas Nethercote [:njn] from comment #27)
> > Mike, what would you think if "third-party" add-ons were simply banned? 
> > I.e. if add-ons could only be installed when the user explicitly requests it
> > within Firefox?  That would be a stronger proposal and it side-steps the
> > question of whether requiring reviews is practical or not, and instead
> > focuses on the question of how add-ons should be allowed to be installed.
> 
> Then someone would find a way to sidestep the problem and fake a first party
> install. It wouldn't solve anything.


And that would be blocklisted as malware.
(In reply to Asa Dotzler [:asa] from comment #33)
> (In reply to Nicholas Nethercote [:njn] from comment #27)
> > Then someone would find a way to sidestep the problem and fake a first party
> > install. It wouldn't solve anything.
> And that would be blocklisted as malware.
The third party add-on startup prompt has been altered and nothing has been done against that (see bug 721258).
That will be the cat and mouse game.
(In reply to Scoobidiver from comment #34)
> The third party add-on startup prompt has been altered and nothing has been
> done against that (see bug 721258).
> That will be the cat and mouse game.

I'd like to see more proof of that bug. And add-on that hasn't been installed can't modify that. So there had to be an installed add-on to make that happen (not Ask Toolbar)
> That will be the cat and mouse game.

This may be.  But fear of this game shouldn't keep us from taking action.  We're a smart cat; smarter, I hope, than many of the mice.  We don't have to catch all the mice in order to reduce the number of vermin infesting users' machines.
A few thoughts.

* With the exception of add-ons bundled with a browser at first download (e.g. Firefox with Twitter), a user should consent to any add-on installed in their browser.

* Signing add-ons, or otherwise securely verifying them, doesn't have to mean ownership and has many potential benefits for which we've been considering it outside of this discussion anyway. Other add-on platforms already do this.

* If an add-on is both 1) obtained from a trusted source and 2) vetted by a trusted party, there should be minimal UI needed to install that add-on. If one of the conditions is not met, it should be more difficult to install the add-on. If both conditions are not met, it should be substantially harder to install the add-on.

* It is beneficial to indicate to users that an add-on has been vetted by a trusted party, and to indicate when an add-on has not been vetted by any trusted party.

* Mozilla is, by default, a trusted source for installation (we don't trick anyone into installing an add-on) and a trusted party for add-on review. We are not necessarily the only party a user trusts with such responsibilities.

* Users should be able to trust other parties for add-on installation or review if they wish. We currently allow users to extend trust for add-on installation (removing the yellow bar in its current incarnation) but don't allow them to extend trust for add-on review (because Firefox doesn't currently make any distinction between a vetted add-on and an unvetted one in installation).

If we can agree with those principles, I think we can come up with a solution that embodies them. In my view, not all of the principles have equal importance.
> With the exception of add-ons bundled with a browser at first download (e.g. Firefox with Twitter), a user should consent to any add-on installed in their browser.

The problem with the way it works today is that it assumes that for all third-party add-ons, the user did not give consent. When you choose to download and install the Ask toolbar and run their EXE, for instance, you are giving consent. It doesn't make sense that Firefox then says "are you sure you want to give consent"

There really should be a better way to say to Firefox "the user said this was OK"

We assume all third-party add-ons were maliciously installed.
> Mozilla is, by default, a trusted source for installation (we don't trick
anyone into installing an add-on) and a trusted party for add-on review. We are
not necessarily the only party a user trusts with such responsibilities.

To be more correct, Mozilla is the only trusted source for installation (as far as I know). Please correct me if I am wrong.
(In reply to Michael Kaply (mkaply) from comment #38)
> > With the exception of add-ons bundled with a browser at first download (e.g. Firefox with Twitter), a user should consent to any add-on installed in their browser.
> 
> The problem with the way it works today is that it assumes that for all
> third-party add-ons, the user did not give consent. When you choose to
> download and install the Ask toolbar and run their EXE, for instance, you
> are giving consent. It doesn't make sense that Firefox then says "are you
> sure you want to give consent"
> 
> There really should be a better way to say to Firefox "the user said this
> was OK"
> 
> We assume all third-party add-ons were maliciously installed.

I reject the idea that running a third party EXE automatically gives consent to install an addon into Firefox.  Stuff people don't want routinely comes bundled with other software in sketchy out-opt installs (one well known tech company distributes a popular internet browser this way ...).

Even if the sole purpose of the third party EXE is to install the addon, and it's not deceptive in any way, I still think it is entirely reasonable to require users to confirm the installation.  There are a lot of addons out there that decrease the quality of the Firefox experience, and IMHO protecting the quality of our product is more important than making it trivial for third parties to install software.
(In reply to Michael Kaply (mkaply) from comment #39)
> To be more correct, Mozilla is the only trusted source for installation (as
> far as I know). Please correct me if I am wrong.

Out of the box, yes.  Other trusted sources can be added.
(In reply to Asa Dotzler [:asa] from comment #19)
> (In reply to Michael Kaply (mkaply) from comment #18)
> > In the context of Mozilla add-ons, it does mean ownership.
> > 
> > When the install dialog comes up, the name next to the add-on (if it is
> > there) indicates whose add-on it is.
> 
> So we change the design of the install dialog to say "vetted by Mozilla" or
> similar. This is software, we can make it do what we want it to do.
> Pretending that we're locked into some ancient and not well designed UI is
> not the best defense for the point you're trying to make.

I've been wanting to do this for normal AMO-reviewed addons anyway, and that certainly wouldn't imply ownership of the addon.
(In reply to Nicholas Nethercote [:njn] from comment #27)
> (I agree that "third-party" is a confusing term;  I've personally
> interpreted it as meaning "non-AMO add-ons" more than once.)

I've been using the term "foreign install" to describe addons installed by 3rd party software.
Summary: Require that third-party add-ons be signed by the AMO team → Require that third-party (i.e., foreign-installed) add-ons be signed by the AMO team
TL;DR: I think this bug should be closed, I disagree with some of the principles offered by fligtar, and the discussion about signatures should be moved to a more public discussion area.

> * With the exception of add-ons bundled with a browser at first download
> (e.g. Firefox with Twitter), a user should consent to any add-on installed
> in their browser.

Agree. To answer Mike's question, the McAfee add-on does the right thing and users need to approve the add-on installation in Firefox (8 and above).

> * Signing add-ons, or otherwise securely verifying them, doesn't have to
> mean ownership and has many potential benefits for which we've been
> considering it outside of this discussion anyway.

I'd like to hear about these additional benefits. As far as I know, we wanted to sign AMO add-ons just to go around the "Unverified author" warning that almost every add-on in existence displays and users have learned to ignore. I also know that we wanted to remove that warning, which would be the most practical way to go in my mind.

> Other add-on platforms already do this.

I don't think that's a compelling reason to do anything.

> * If an add-on is both 1) obtained from a trusted source and 2) vetted by a
> trusted party, there should be minimal UI needed to install that add-on. If
> one of the conditions is not met, it should be more difficult to install the
> add-on. If both conditions are not met, it should be substantially harder to
> install the add-on.

I disagree with this. All add-ons (even from AMO) should at least show a warning about installing software in the user's machine. I think that's the absolute minimum that we should do to make them aware they're installing something that is potentially problematic.

I don't see how we can come up with a trust system that isn't centralized on Mozilla, and if this system gives developers benefits other than a "vetted by X" message in the install dialog (like easier installation), I think we're creating a barrier for openness and free participation.

Any person in the world should be able to read a tutorial, build an add-on and publish it on their site without Firefox making it "substantially harder" to install. Doing otherwise goes against the most fundamental principles Mozilla is built on, in my opinion.

> * It is beneficial to indicate to users that an add-on has been vetted by a
> trusted party, and to indicate when an add-on has not been vetted by any
> trusted party.

That sounds good, but we go back to the question of what is trusted and how is trust given. I think this is a slippery slope toward centralized control, and it should be handled very carefully.

> * Mozilla is, by default, a trusted source for installation (we don't trick
> anyone into installing an add-on) and a trusted party for add-on review. We
> are not necessarily the only party a user trusts with such responsibilities.

Agreed.

> * Users should be able to trust other parties for add-on installation or
> review if they wish. We currently allow users to extend trust for add-on
> installation (removing the yellow bar in its current incarnation) but don't
> allow them to extend trust for add-on review (because Firefox doesn't
> currently make any distinction between a vetted add-on and an unvetted one
> in installation).

Agreed.

I think this discussion has grown way past a bug report, and if we want to continue having this discussion, we should choose a more public location, like newsgroups, the blog or the forum. This is a major decision (if one is to be made), and we should include the add-on developer community in the conversation.

Going back to what this bug is about, I'm completely against forcing externally-installed add-on developers to subject themselves to any form of review or signing process. They should be free to distribute their software on their own terms and their own schedule. I'm totally in favor of dedicating some time to reviewing their add-ons and reporting defects, but that shouldn't block their release.

For important situations, we already have Kev, who handled the McAfee problem quickly and there are already good results coming out it. For critical situations, we have the blocklist, and it has served us well. I feel that the premise of this bug - that something is horribly wrong - is flawed, and that the current system covers most if not all cases where we want to deal with problematic dark matter add-ons.

Increasing our testing of these add-ons is something we can do to improve this system, and it's something that doesn't require specialize reviewers like the ones on the AMO Editors team. While we may be doing exceptionally well at the moment, I expect our burden to increase again in the coming months, so I wouldn't expect us to have to resources to deal with this.
So it sounds to me that the process you would like is:

 * Add-on vendor releases busted add-on.
 * Mozilla QA notices the problem, communicates with add-on developer.
 * Add-on developer releases fix.

Just to get the parameters of this clear, we agree that the busted add-on can affect millions of users, right?  McAfee is in about 4% of our crashes, so that's roughly 16 million installs.

We also agree that a two-week turnaround for a fix is about the best we can hope for from a vendor, right?  We've been praising McAfee for its fast turn-around in this case, and it's going to be at least that long before the fix gets into users' hands.
(In reply to Justin Lebar [:jlebar] from comment #45)
> So it sounds to me that the process you would like is:
> 
>  * Add-on vendor releases busted add-on.
>  * Mozilla QA notices the problem, communicates with add-on developer.
>  * Add-on developer releases fix.

Yes.

> Just to get the parameters of this clear, we agree that the busted add-on
> can affect millions of users, right?  McAfee is in about 4% of our crashes,
> so that's roughly 16 million installs.

Yes.
 
> We also agree that a two-week turnaround for a fix is about the best we can
> hope for from a vendor, right?  We've been praising McAfee for its fast
> turn-around in this case, and it's going to be at least that long before the
> fix gets into users' hands.

Kev contacted them on the 16th, and fix is at the moment planned to be released tomorrow IIRC. That's less than one week, not two. But yes, we can't expect next-day releases from them, given that they often have more involved QA, build and release processes.
> Kev contacted them on the 16th, and fix is at the moment planned to be released tomorrow 
> IIRC. That's less than one week, not two.

That's great, but they did say that we should wait a few days before blocklisting the old add-on because it would take a few days for their change to propagate to all their users.  Anyway, we can count this as one week.

Jorge, if we

 * Find the resources to test the top N add-ons (we can do either top N foreign-installed or top N overall) for some reasonable N,
 * Ask third-party developers to submit their pre-release add-ons to us for testing (if they send source, all the better, but we're not requiring anything),
 * Keep track of, for each version of each "important" non-AMO add-on:
    ** If and when we received a pre-release copy
    ** When the version was released
    ** When we started and finished testing the version
    ** Whether the version leaks
    ** How long it took for the fix to be released (this is the same as the first ** here, I guess)
 * Aggressively soft-block known-busted versions of non-AMO add-ons after a fix is released,

then I think we'll be in a position to fix the vast majority of problems with foreign-installed add-ons.  We'll also start collecting the data necessary to determine whether this is an effective means of addressing problems in foreign-installed add-ons, or whether more aggressive preemption of bugs is necessary.

This seems to me like the same sort of agreement we came to wrt existing AMO add-ons, where we agreed that the AMO team would be responsible ensuring that add-on authors don't forget about their leak bugs, tracking what fraction of leaks in existing add-ons are fixed by authors, and tracking how long it typically takes for a leak to be fixed.

Anyway, if we agree on the conditions above, I'm happy to wontfix this bug.  We can come back to it later (or file a new bug) once we have data on how well the approach is working.

(We can copy the list above into a new bug, if you'd like to track that work with a bug.  But I wanted to post it here to give this bug some sense of being resolved.)
(In reply to Jorge Villalobos [:jorgev] from comment #44)
> > * Signing add-ons, or otherwise securely verifying them, doesn't have to
> > mean ownership and has many potential benefits for which we've been
> > considering it outside of this discussion anyway.
> 
> I'd like to hear about these additional benefits. As far as I know, we
> wanted to sign AMO add-ons just to go around the "Unverified author" warning
> that almost every add-on in existence displays and users have learned to
> ignore. I also know that we wanted to remove that warning, which would be
> the most practical way to go in my mind.

Indeed, if that warning were that important to not show, we'd just remove it from the dialog. I want AMO to start signing to differentiate between "reviewed to be safe" and "not reviewed" addons, in a way that can't be hijacked.

As an interesting side-effect, it could also make it easier for a trusted non-AMO marketplace to have a good install experience.

FWIW, I'm working on implementing a new install experience (bug 643020) that will handle signed/unsigned addons better than the current dialog.


> > * If an add-on is both 1) obtained from a trusted source and 2) vetted by a
> > trusted party, there should be minimal UI needed to install that add-on. If
> > one of the conditions is not met, it should be more difficult to install the
> > add-on. If both conditions are not met, it should be substantially harder to
> > install the add-on.
> 
> I disagree with this. All add-ons (even from AMO) should at least show a
> warning about installing software in the user's machine. I think that's the
> absolute minimum that we should do to make them aware they're installing
> something that is potentially problematic.

The plan for bug 643020 is for a middle-ground for this, where "trusted" addons have a smoother install experience that's less scary, but still informative (ie, not one-click). Addons installed from AMO get better AMO integration. And "non-trusted" addons get additional warnings.


(In reply to Jorge Villalobos [:jorgev] from comment #46)
> given that they often have more involved QA

Evidentially not, if they missed that bug... </snark>
>> given that they often have more involved QA
>
> Evidentially not, if they missed that bug... </snark>

In their defense, we started looking for this class of bug in Firefox only a few months ago.  And when we did start, we found a *ton* of bugs.

But note that the "fix" nominally coming out today doesn't solve all the zombie compartments in McAfee's add-on -- at least, the last binary we looked at still had leaks.  Indeed, we'd reject this update for its leaks.
* reject the update from AMO, if the add-on were hosted there.
(In reply to Justin Lebar [:jlebar] from comment #49)
> But note that the "fix" nominally coming out today doesn't solve all the
> zombie compartments in McAfee's add-on -- at least, the last binary we
> looked at still had leaks. 
Please comment in bug 727938.
Which comment?

There was a private e-mail thread where we got early access to the update, tested it, and determined that it was a large improvement, but not a complete fix.  But maybe there was another thread where we got an update.
(In reply to Justin Lebar [:jlebar] from comment #50)
> * reject the update from AMO, if the add-on were hosted there.

We (AMO) preliminary approve addons with memory leaks. Unless it was system-crashing level severe.
We (AMO) would not auto-update users from an approved version to a preliminarily-reviewed version, correct?
(In reply to Justin Lebar [:jlebar] from comment #54)
> We (AMO) would not auto-update users from an approved version to a
> preliminarily-reviewed version, correct?

Correct.  And the update is hidden away on the 'other versions' page also.
(In reply to Blair McBride (:Unfocused) from comment #48)
> FWIW, I'm working on implementing a new install experience (bug 643020) that
> will handle signed/unsigned addons better than the current dialog.

That reminds me, I logged bug 717779 about differentiating preliminary and fully reviewed addons in the about:addons search results - we currently include preliminary addons (that may have memory leaks) and fully reviewed addons (that shouldn't) in the same list.
(In reply to Blair McBride (:Unfocused) from comment #48)
> (In reply to Jorge Villalobos [:jorgev] from comment #46)
> > given that they often have more involved QA
> 
> Evidentially not, if they missed that bug... </snark>

Yeah, like Justin said, this is something for which we didn't have the tools or process to test until very recently. I suspect a large percentage of add-ons out there leak, so there's plenty of work to do.

(In reply to Scoobidiver from comment #51)
> (In reply to Justin Lebar [:jlebar] from comment #49)
> > But note that the "fix" nominally coming out today doesn't solve all the
> > zombie compartments in McAfee's add-on -- at least, the last binary we
> > looked at still had leaks. 
> Please comment in bug 727938.

We're allowing the partial fix to be distributed because it is a significant improvement over the current version. We are still working with them on resolving the remaining leaks, which should be fixed shortly thereafter.
> Please comment in bug 727938.

Sorry, I read a "see" which wasn't there.  I've commented in the bug.

> We're allowing the partial fix to be distributed because it is a significant improvement 
> over the current version.

Heh, we're not *allowing* anything.  That's kind of the point of this bug.
> Heh, we're not *allowing* anything.  That's kind of the point of this bug.

Yeah you are.

Because you can blocklist them.

In the end, Mozilla does have total control over every add-on installed in Firefox.
This discussion is nuanced - but if the title subtly changed to "Require that foreign-installed add-ons be subject to scrutiny" IMO it would be almost impossible to refute.  The tricky bit then is exactly *what* scrutiny.  If we can make the conditions purely objective (and therefore open to automation, as implied by Asa), it certainly gets my vote.
(In reply to Mark Hammond (:markh) from comment #60)
> This discussion is nuanced - but if the title subtly changed to "Require
> that foreign-installed add-ons be subject to scrutiny" IMO it would be
> almost impossible to refute.

Agreed.  I was going for something more here -- in particular, I'd s/scrutiny/review, meaning that the add-on is available only after it's explicitly approved.  But mere scrutiny would be a great improvement over the current situation, I think everyone agrees.

> The tricky bit then is exactly *what*
> scrutiny.  If we can make the conditions purely objective (and therefore
> open to automation, as implied by Asa), it certainly gets my vote.

We can't automate the most important tests, because we can't automate using the add-on.  But I don't think manual testing implies Apple-level capriciousness; at least, we've managed to avoid that on AMO.
I don't want Mozilla to turn into Apple, because we don't like the barrier Apple puts to Firefox presence on iOS when users ask for Firefox to be there.

Therefore, I think it should always be possible to initiate a non-AMO add-on install from the add-on manager so that the user initiates the installation from inside Firefox and picks an .xpi (e.g. via the Open dialog).

But I don't see why it should be OK for an .exe to dump an add-on into Firefox, vetted by Mozilla or not. Allowing it under some Mozilla-vetted circumstances seems like a complication.

Why don't we require *all* add-on installs to be initiated from within Firefox, block installs initiated from other .exes and play the cat&mouse game against companies that try to circumvent the blocking mechanism? (Obviously, there should be no pref to disable the blocking mechanism, since it's trivial for third parties to flip prefs from outside Firefox.)
(In reply to Henri Sivonen (:hsivonen) from comment #62)
> 
> But I don't see why it should be OK for an .exe to dump an add-on into
> Firefox, vetted by Mozilla or not. Allowing it under some Mozilla-vetted
> circumstances seems like a complication.
> 
> Why don't we require *all* add-on installs to be initiated from within
> Firefox

I was wondering the same thing, so I started this thread: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/UY1XnWBKiCU.
(In reply to Henri Sivonen (:hsivonen) from comment #62)
> Why don't we require *all* add-on installs to be initiated from within
> Firefox, block installs initiated from other .exes and play the cat&mouse
> game against companies that try to circumvent the blocking mechanism?
> (Obviously, there should be no pref to disable the blocking mechanism, since
> it's trivial for third parties to flip prefs from outside Firefox.)

Doesn't Firefox already block third party installs by default*?  Are you suggesting that the pref be removed so it can't be disabled?  

*(With the exception of install time bundles)
(In reply to Andrew Williamson [:eviljeff] from comment #64)
> (In reply to Henri Sivonen (:hsivonen) from comment #62)
> > Why don't we require *all* add-on installs to be initiated from within
> > Firefox, block installs initiated from other .exes and play the cat&mouse
> > game against companies that try to circumvent the blocking mechanism?
> > (Obviously, there should be no pref to disable the blocking mechanism, since
> > it's trivial for third parties to flip prefs from outside Firefox.)
> 
> Doesn't Firefox already block third party installs by default*?

There's a two-click confirmation.

> Are you
> suggesting that the pref be removed so it can't be disabled?  

I'm suggesting removing the pref and removing the confirmation so that if an .exe wants to put an add-on into Firefox, the steps would be:
 1) .exe dumps an .xpi on the disk.
 2) The user goes into the add-on manager
 3) The user invokes an "Install add-on from disk" command
 4) The user chooses the .xpi from a file picker dialog.
 5) Firefox issues one final warning that proceeding can make the user experience terrible.
 6) User proceeds.

I expect with a flow like this, it would be much harder to deceive the user about what's happening. See also bug 721258.

Or, alternatively, the add-on author doesn't distribute the add-on bundled in an .exe installer for another thing but makes the add-on available via means that make sense for add-on installation rather than "dump random code onto a Windows machine" installation.
I suspect if we successfully locked things down to the level in comment 65, add-on authors would simply redirect users to a site off AMO to download the add-on.  That would be a lot simpler for most users.

IOW, it seems to me we'd effectively be killing install-from-third-party-binary.  Not that I'd object...
The reason EXE install is useful is because you can maintain your add-on as part of a larger distribution.

It's silly to require s company to setup a completely different update infrastructure (no matter how simple) for one app.

In addition, would you want to be the user that installs their antivirus and then manually has to install additional add-ons?

The user experience would be horrible.

Mozilla invented the third party add-on code to solve a problem. It continues to solve that problem today (albeit it with a worse user experience than it used to).

The barrier has already been placed. Don't make it worse.
There's one other use case that noone has thought of that is referenced in the original bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=293548

> This will enable people to install extensions even when firefox is
not present on the system.

That brings up a really good question. If I have my antivirus installed and then I get Firefox, how will the add-on get added to Firefox if you make the user manually install it?
Yeah, I think dropping a file on disk and making the user manually install it is a non-starter. The opt-in dialog seems like a good compromise to me, and the recent Ask.com discussions are more about this dialog being "prettyfied" by them so users will opt-in more readily.
tl;dr: We want to promote freedom. Read Mozilla manifesto, principles 2, 5, 6. We can't close down all those tons of small addons that people create.

"5. Individuals must have the ability to shape their own experiences on the Internet.
 6. The effectiveness of the Internet as a public resource depends upon ...
    innovation and decentralized participation worldwide."

> Again, this isn't about keeping users from installing software they want.
> I'm perfectly happy for a user to install a non-AMO add-on.

How do you differentiate these user-wanted installs from other companies installing into Firefox? If you can differentiate, I'm all for it, but I fear it's theoretically (read: strictly) impossible.

As Mike said before, you can't enforce that all addons are approved by Mozilla Corporation. There's a huge space of custom addons for a special purpose and a very small amount of users. You can't introduce the AMO review bottleneck, which is significant and takes weeks, as a mandatory part before anyone can use the products I create. You'd be significantly hindering my job.

There's tons and tons of small addons. You can't just close all that down.

And FWIW, industry giants like Apple and MS acts in their own interest. As a developer, I turned away from Apple appalled and *disgusted*, after reading the requirements they put on me just for creating applications. And Apple *does* use this to keep competitors out, see Firefox on iOS. We don't want to be in the same basket with such companies, rather we need to be a stance for freedom.

There are other ways to keep the crap out. Some legal, some technical, some UI.
Please, think about the direction you take the world in. There wouldn't be Open-Source, if computers had been as closed down as iPhones are. This idea of locked bootloaders and appstores with only approved applications is directly contrary to the whole idea of free software, and destorys all the achievements we made. Don't go there, not even close. Totally wrong direction.

As I said, I understand the motivation, and it's good. But there are other means to keep crap out.
> How do you differentiate these user-wanted installs from other companies installing into Firefox? If 
> you can differentiate, I'm all for it, but I fear it's theoretically (read: strictly) impossible.

Since Firefox 8, we differentiate as:

 * If the add-on installation was triggered by an action within Firefox, it's a user-installed add-on
 * Otherwise it is not a user-installed add-on.

I agree it's impossible to tell whether an add-on installation triggered outside Firefox was somehow "triggered" with the user's informed consent.  But given the choice between allowing any crapware present on the user's machine to install a Firefox patch and allowing software to install only vetted patches, I chose the latter.

> As Mike said before, you can't enforce that all addons are approved by Mozilla Corporation. 
> There's a huge space of custom addons for a special purpose and a very small amount of users. You 
> can't introduce the AMO review bottleneck, which is significant and takes weeks, as a mandatory 
> part before anyone can use the products I create. You'd be significantly hindering my job.

Why can't custom add-ons with a special purpose with a small number of users go through a slightly more complex installation procedure, such as

 * Directing the user to a webpage
 * Instructing the user on that page how to click through Mozilla's warning screens and install the add-on.

?

It seems to me that this would be a small price to be paid by a small number of users in order to preserve the well-being of the vast majority of users.

This is all about trade-offs.  We may make it more difficult for a "very small amount of users" to install their custom add-ons.  It won't be impossible.  But if you were to start from the premise that any increase in install difficulty for any number of users is unacceptable, we're going to have a hard time reaching an agreement.

If this really doesn't work for you, can you please provide some details about the project you work on and why it's in Mozilla's users' best interests to allow your software to be installed without any oversight?
(In reply to Ben Bucksch (:BenB) from comment #71)
> Please, think about the direction you take the world in. There wouldn't be
> Open-Source, if computers had been as closed down as iPhones are.

What this bug is proposing is nothing like iPhones.  See comment 29.
(In reply to Ben Bucksch (:BenB) from comment #70)
> You can't introduce the AMO review bottleneck, which is significant and takes 
> weeks, 

Can I point out that the AMO review process now takes days, not weeks (and was down to a few hours at one point last week).  This doesn't affect the validity of your other comments.
>  * If the add-on installation was triggered by an action within Firefox,
> it's a user-installed add-on

My point was that if you have an installer.exe running on the local machine, that installer can do whatever it wants, including faking user actions inside Firefox and modifying the profile files so that it appears to be a user-installer addon. It's technically impossible to prevent locally running installers from doing anything.

I agree that the method used by Firefox 8 is good.

> * Instructing the user on that page how to click through Mozilla's warning screens

So you only want to discontinue the "drop extension in Firefox install folder" method, but not the "user installs from webpage" method? That wasn't clear to me, because the latter are "third-party addons" for me. Seems like we use different terminology.

I don't have a major problem with discontinuing the former, apart from the following fact: If you disallow that, then some rogue installers *will* work around it by other methods. That's why I think the approach chosen by Firefox 8 is not a bad idea: Allow other installers to easily install extensions, but then let Firefox automatically request additional user confirmation.

> small price to be paid by a small number of users

How do you know that it's a small amount? From what I see, there is a very "long tail" of small, legit extensions.
(In reply to Ben Bucksch (:BenB) from comment #75)
> So you only want to discontinue the "drop extension in Firefox install
> folder" method, but not the "user installs from webpage" method? That wasn't
> clear to me, because the latter are "third-party addons" for me. Seems like
> we use different terminology.

Difference between installed FROM a third party and installed BY a third party.
> My point was that if you have an installer.exe running on the local machine, that installer can do 
> whatever it wants, including faking user actions inside Firefox and modifying the profile files so 
> that it appears to be a user-installer addon. It's technically impossible to prevent locally running 
> installers from doing anything.

Inasmuch as the installer could replace the whole Firefox binary, yes, it's impossible to stop the installer from doing things to us.

But there are still lots of things we could do to protect ourselves, such as watching for modifications to the Firefox profile directory and warning users when that happens.

I don't pretend that any of this is easy, but as someone said to me, arguing that we should do nothing because code can overwrite the Firefox binary is like saying that, because a burglar can kick in the back door, we should leave the front door open and invite him in.

> So you only want to discontinue the "drop extension in Firefox install
> folder" method, but not the "user installs from webpage" method?

Yes, see e.g. comment 10.

> I don't have a major problem with discontinuing the former

Great to hear!

> If you disallow that, then some rogue installers *will* work around it by other methods.

Sure.  But I don't think we need a perfect solution; if we prevent 90% of crapware, that's an improvement.
Justin, I think you overestimate the ability to stop installers. I doubt you can stop 90% of installations, esp. because 80% of installers are from the same 5-10 offenders. There is lots of money behind it, and Product Managers that *demand* from the developers to get it done. Redirecting DLL functions, sending keyboard events to other apps and similar hacks are commonplace in Windows. There's no need to replace the Firefox binary, you just send Ctrl-L, URL, enter, mouse move to dialog, wait, mouse click, and it appears to be a user-installed addon. Crapware will have no problem to do that, enterprise admins won't. You hurt the latter.
Summary: Require that third-party (i.e., foreign-installed) add-ons be signed by the AMO team → Require that third-party add-ons installed by third-party installers (not user action) be signed by the AMO team
Summary: Require that third-party add-ons installed by third-party installers (not user action) be signed by the AMO team → Require that third-party add-ons installed by third-party installers (not user action in Firefox) be signed by the AMO team
(In reply to Justin Lebar [:jlebar] from comment #77)
> I don't pretend that any of this is easy, but as someone said to me, arguing
> that we should do nothing because code can overwrite the Firefox binary is
> like saying that, because a burglar can kick in the back door, we should
> leave the front door open and invite him in.
> 
> > If you disallow that, then some rogue installers *will* work around it by other methods.
> 
> Sure.  But I don't think we need a perfect solution; if we prevent 90% of
> crapware, that's an improvement.

I agree with BenB. This seems like a lot of effort that is not even going to keep all honest people honest. Any usable mechanism we implement will be trivial for extension installers to work around. We might initially see an improvement, until somebody releases an open-source library for subverting this mechanism. Then we'll be back (approximately) to where we are now.

Windows does not provide an official API to pin an application to the taskbar, because Microsoft wants the user to be in control of pinning. However, Firefox is able to do so because it uses an undocumented mechanism to subvert this protection, because we think it is misguided.

Why wouldn't we expect addon developers to have the same mindset as us? Most of these addons, especially addons like McAfee, are *intended* to help and protect the user. They think they are the good guys and we are misguided in trying to protect the user from them, so they'd feel no guilt in subverting any protection we implement.

There are going to be some classes of software--especially security software--that legitimately need to work differently than your average addon (e.g. they should only be possible to be enabled/disabled by administrators).

I don't see any way that a major software vendor (especially security software venders) would feel comfortable opting into a scheme that requires them to wait for our review team to review and sign their addon, because this would negatively impact their response time for security fixes. If I were an addon developer, I would feel fully justified in subverting this mechanism for this reason alone.

IMO, we are better off working with the addon community on guidelines and example code for creating installers for their addons that are congruent with our idea that the user should be in control and that there shouldn't be any surprises. And, we could change Firefox to (a) better control addons, and (b) better report on misbehaving addons, so that the user can take action to disable them. (Similar to what IE does.)

Ultimately, the operating system is responsible for controlling software installation. In Windows 8 and Mac OS X Lion and later, we may be able to use the operating system's sandboxing mechanisms to implement *effective* controls here.
Brian, please take a look at our unordered list of the top 100 add-ons [1] (or ping me privately for the ordered list, which we unfortunately can't make public) when you have a chance.

How many of these are well-meaning, do you think?  How many of them do you think would care about guidelines we released?

> And, we could change Firefox to (a) better control addons, and (b) better report on misbehaving 
> addons, so that the user can take action to disable them. (Similar to what IE does.)

Couldn't any add-on subvert these protections, too?  An add-on could force-enable itself, or it could fake its performance report.  Honest question: If we believe that we're helpless in the face of add-ons, why take any technical action at all?
> Brian, please take a look at our unordered list of the top 100 add-ons [1] (or ping me privately for the ordered list, which we unfortunately can't make public) when you have a chance.

Excuse me?

Open source. Open company. Non-profit?
Usage numbers for externally-hosted add-ons is considered private data and isn't shared outside of the company.
bsmith wrote:
> IMO, we are better off working with the addon community on guidelines and
> example code for creating installers for their addons that are congruent
> with our idea that the user should be in control and that there shouldn't
> be any surprises.

Agreed! As said, commercial developers (esp the installer author, which is not necessarily the same as the Firefox extension author) have not much knowledge about Firefox and will use the approach that they find first on a trivial Google search, and which meets their needs.

If we give publish a simple way to add an extension, document it clearly and widely, and then give the user control over them via a simple UI, this is the best we can do, from what I can see.

> And, we could change Firefox to (a) better control addons, and (b) better report on
> misbehaving addons, so that the user can take action to disable them.

Agreed.

> How many of these are well-meaning, do you think?

I would think that many of the top addons are commerical, e.g. HP notebook/printer suite or Skype or Norton or whatever installing a toolbar with some occasionally useful, but mostly unnecessary functionality and changing the search engine, for profit. And I agree with your goal to stop that. I am just not sure there's much we can do.
Whiteboard: [MemShrink]
Just to echo that this is a real problem, most of these addons installed by non-amo addons are commercial ones that are intended to lock-in, degrade and otherwise interfere with user enjoyment. 

jlebar, maybe you could get with #ux (cbeasley for example) and see if there is some consensus about good work flows for dealing with these flows.  I would be happy to help facilitate if useful.  

These things are terrible, and particularly bad on Windows, where the lions share of our users are.
> this is a real problem

Gregg, nobody really doubts that. But this bug won't *solve* it. Not even mostly. Please see comment 78 and 79.

I think this is a better solution:
> > If we give publish a simple way to add an extension, document it clearly and widely,
> > and then give the user control over them via a simple UI, this is the best we can do,
> > from what I can see.

As "User Research", you may have some idea how to give people more and easier control over their addons. (Obviously, Help|Addons is not sufficient)
> jlebar, maybe you could get with #ux (cbeasley for example) and see if there is some 
> consensus about good work flows for dealing with these flows. 

To be honest: We've gotten zero buy-in from the add-ons team for this.  Asa has made noise and put this general issue on the FF roadmap for 2012, but afact no concrete progress has been made yet (Asa, please correct me if I'm wrong!).

This isn't a matter of just drawing up UX flows; I think someone with power to tell people what to do needs to take on this cause, if it's going to to happen.  My powers of persuasion, such as they are, have been exhausted here.
Hey folks, thanks for the bug.  Mozilla is pursuing an add-on registration system which will help address this concern.  I'm going to close this bug as we're 87 comments in and any work for the add-on registration system is going to happen in other bugs anyway.  Read about the system at:

https://wiki.mozilla.org/User:Jorge.villalobos/WorkWeek2012Q2/FileRegistration
https://wiki.mozilla.org/Add-ons/FileRegistration/Mockups
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Wil Clouser, Jorge Villalobos, what is 1) the bug 2) the appropriate discussion forum for this?
(In reply to Ben Bucksch (:BenB) from comment #90)
> Wil Clouser, Jorge Villalobos, what is 1) the bug 2) the appropriate
> discussion forum for this?

There's no single bug tracking this. Also, I just edited the document to link to the discussion thread (thanks for the reminder, I've been meaning to do that).
Jorge, we need to have a broad discussion about this. The implications are huge, for many parties and situations.

In your document, you're pointing to:
newsgroup mozilla.addons.user-experience, thread "Add-on File Registration System - PRD", opened by you (Jorge) on 2013-10-16.
(FTR, there have been only 2 posts so far, yours and Mike Kaply's.)
I know. We're gradually making it more public, and we will move this to dev.planning and announce it on the blog eventually (within a week or two, probably).
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.