495687 - users don't have enough control over what add-ons are installed (tracking bug)

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Andrew Hagen]

This is a tracking bug for issues of users not having control over and knowledge of what add-ons are installed.

Comment 1

[Dave Townsend [:mossop]]

This seems a strange mix of faults, potential improvements and restrictions. Can you elaborate on what the point of this tracking bug is?

Comment 2

[Andrew Hagen]

In reply to comment #1 and to bug 400898 comment 12.

The basic concept is that users should have control over what extensions are installed, and they should always have reliable mechanisms in the Add-On Manager to do so. 

While Microsoft is currently getting the blame in this Washington Post article, http://voices.washingtonpost.com/securityfix/2009/05/microsoft_update_quietly_insta.html, it is foreseeable that if the current situation continues indefinitely, people will eventually question why Firefox has no way to uninstall global extensions, for example.

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> The basic concept is that users should have control over what extensions are
> installed, and they should always have reliable mechanisms in the Add-On
> Manager to do so. 

By this rationale you should make almost every bug in the add-ons manager component block this bug. I don't see what the need is for a tracking bug that covers such a wide scope. Please either come up with a well defined scope and reason why we need to look at the issues as a group (and remove the then invalid dependencies) or lets just close this and deal with the individual issues.

Comment 4

[Andrew Hagen]

The scope is limited to the bugs on which this bug is dependent. I'm changing the summary to make it clear that this tracking bug is not seeking perfection. It is seeking certain key improvements in how we inform and empower users regarding add-on installation. I intend to keep this bug open.

Comment 5

[Mike Connor [:mconnor]]

That's not how we use tracking bugs, in the rare cases we still use tracking bugs in Toolkit/Firefox components.  If you're going to be doing the work, or overseeing the work of a team you control, as part of a clear project plan, a tracking bug is fine.  If it's someone's personal set of wants, this is not appropriate use of Bugzilla, and the bug will be closed.

There's lots of ways to track sets of bugs that you're personally interested in, and lots of ways to share those out to other interested parties.  You can intend to keep a bug open, but the component owner and ultimately the Bugzilla admins have the final say.  Dave's the component owner, and I'm an admin, so please play nice.

Thanks.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #4)
> The scope is limited to the bugs on which this bug is dependent.

That isn't a defined scope. That just says that you've built up a collection of bugs you're interested in and want to keep an eye on. As Mike says there are better ways to do this that don't impact our bug stats, generate bugspam and confuse people working on the dependant bugs.

Unless you're going to narrow down the list of bugs to items that are strongly related and so either fixing some will impact whether we can fix others, or looking at all of the bugs as a whole for a fix makes more sense than looking at them individually then I will close this bug.

Comment 7

[Andrew Hagen]

I don't understand why you don't understand how all these bugs are related.  Each dependency represents a weak point in our protection of the user in the area of add-on installation. Another way of phrasing it is "users don't have enough control over what add-ons are installed." Which bug in the list do you think does not fit that? Secondly, could you please state which specific bug, currently not on the list, fits the scope of this tracking bug, and why? 

I have a number of other tracking bugs that I maintain, such as bug 123929. The existence of those bugs has never been challenged in the eight years I have had been on Bugzilla. I thought this tracking bug fit best into Toolkit: Add-ons Manager. Maybe that's not right. Would Core: Tracking be better? Perhaps: Core: Security? 

Clearly, users do not have enough control over what add-ons are installed. You agree with that statement. That is also my belief. This tracking bug brings together the salient issues. 

Let's consider this from a legitimate software company's perspective. They want to give their users a Firefox extension. No problem. Just make sure that users have the right to say "no thanks," make sure that the users are informed about the extension, and make sure that the users have the ability to conveniently uninstall it from within Firefox if they have already installed it. From the legitimate software company's persepective, that will all acceptable and OK. Currently, Firefox does not have the infrastucture to do all that, however, and therefore we have this tracking bug. The legit company today can't make all that happen very easily. We should help them. 

The current situation with Mozilla add-ons, particularly extensions, is unacceptable. Tens of millions of users woke up one day and there was a new extension installed in Firefox from Microsoft, without user knowledge or approval. As Firefox grows in market share from about 25% now to perhaps 40% in a year or two, we are going to become an increasingly tempting target for software authors of ill-intent. If Microsoft can slip an extension into Firefox without user knowledge, anybody can. The need is not to make that technically impossible to achieve. We can't do that anyway. The need is to lower the gates. We have not done enough yet to protect the user from add-on attacks. 

Let me describe a related situation. In bug 123929 comment 21, I reflected on how much our protection against profile corruption has improved over the years. It appears that bug is almost ready to be closed once dependency bug 319196 is closed. That is not because users will then be completely safeguarded from profile corruption. It will be because we have made great strides toward that goal. In like manner, this tracking bug is not going to exist forever. It does not seek perfection. It has a limited scope. 

We ought to get ahead of this before it becomes more serious in the future. Perhaps we will find out that Microsoft's extension has a security hole in it, and users will want to immediately uninstall it, but can't figure out how. To solve the problem, users could switch to IE. In this way, we have left ourselves vulnerable to our chief rival's competency and honor in writing software. How do you think Microsoft would react if we slipped a Mozilla add-on into every IE installation during Firefox install? Perhaps malware starts hiding itself in hidden Firefox extensions, or in extensions that cannot be uninstalled. Unfortunately, the negative possibilities are endless. This tracking bug is the best possible way to keep an eye on this. Therefore, this bug remains open.

Comment 8

[Andrew Hagen]

Slashdot has picked up the Krebs article. 

http://yro.slashdot.org/story/09/06/01/1438219/Microsoft-Update-Quietly-Installs-Firefox-Extension 

One comment thread: 

Firefox needs to fix this. (Score:5, Insightful)

http://yro.slashdot.org/comments.pl?sid=1252303&cid=28168297

Comment 9

[Dave Townsend [:mossop]]

(In reply to comment #7)
> I don't understand why you don't understand how all these bugs are related. 
> Each dependency represents a weak point in our protection of the user in the
> area of add-on installation.

Some of them are about bugs with the uninstall process, not related to protection at all. Some of them are about UI not seen during add-on installation.

> Another way of phrasing it is "users don't have
> enough control over what add-ons are installed." Which bug in the list do you
> think does not fit that? Secondly, could you please state which specific bug,
> currently not on the list, fits the scope of this tracking bug, and why? 

The problem is that the scope is much much too broad. All of the bugs you have listed fit into the scope of "controlling what add-ons are installed" in some way or other but then so do many many other bugs. There is no value in a tracking bug that just tracks a lot of vaguely related bugs that might need to be fixed at some point.

> I have a number of other tracking bugs that I maintain, such as bug 123929. The
> existence of those bugs has never been challenged in the eight years I have had
> been on Bugzilla. I thought this tracking bug fit best into Toolkit: Add-ons
> Manager. Maybe that's not right. Would Core: Tracking be better? Perhaps: Core:
> Security? 

I care more about the existence of bogus dependencies on bug reports than the existence if this actual bug.

Based on your follow up discussion about the only sensible scope that I can come up with is that you want to track issues surrounding the integration of other applications installed on the machine with Firefox through the extension manager. This I could understand and it could even potentially be a sensible scope for a tracking bug, but only half of the dependencies are related to that. Give me a well defined scope and reason for the bug's existence and it can stay open.

> We ought to get ahead of this before it becomes more serious in the future.
> Perhaps we will find out that Microsoft's extension has a security hole in it,
> and users will want to immediately uninstall it, but can't figure out how. To
> solve the problem, users could switch to IE.

Or they could disable the add-on. And Mozilla could blocklist it to disable it on everyone's computer in a very short time. That would come about by a vulnerability report causing a request to update the blocklist, nothing to do with this bug.

> Perhaps malware starts
> hiding itself in hidden Firefox extensions, or in extensions that cannot be
> uninstalled.

This has already happened, although the cases I remember did not show up in the extension manager since there are more direct means to inject code into Firefox than using the extension manager. Why would malware insert itself in a way that can be easily disabled by the user?

> Unfortunately, the negative possibilities are endless. This
> tracking bug is the best possible way to keep an eye on this. Therefore, this
> bug remains open.

Nothing about this tracking bug appears to be about controlling malicious add-ons, something which user's are often less capable of dealing with than software means.

Comment 10

[Dave Townsend [:mossop]]

There is still no well defined scope or reason for this bugs existence so I'm closing this. Please don't reopen it or re-create the dependencies unless we've had a discussion about what you want to achieve first. If you just want to track a set of bugs then you can do that for yourself with bugzilla's tagging feature.

Comment 11

[Bartłomiej Brzozowiec (BartZilla)]

(In reply to comment #5)
> (...)
> There's lots of ways to track sets of bugs that you're personally interested
> in, and lots of ways to share those out to other interested parties. (...)

Could you enumerate these many ways, please? Thanks in advance.