RFE: There should be a way to Auto-Update Extensions without user interaction

VERIFIED FIXED in mozilla1.9.3a5

Status

()

--
enhancement
VERIFIED FIXED
13 years ago
7 years ago

People

(Reporter: u49640, Unassigned)

Tracking

(Blocks: 1 bug)

1.8 Branch
mozilla1.9.3a5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want?])

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

There should be a way in FF & TB to Auto-Update all Extensions without asking the User to confirm this.

The current situation is highly unusable: if i enable search for Extension Updates, i dont even get some kind of Feedback that an update was found!
The User is expected to goto the Extension manager and find out, that an update is available.

The least FF/TB could do is display some kind of notification or Auto-Update the extension (there should be a pref somewhere to set this)

Reproducible: Always
I don't believe auto updating without any user interaction is a good thing. There is already bug 307358 for feedback/notification which is what most of comment #0 is about. Matthias, are you asking for updating of extensions without any user interaction or is this a dupe of bug 307358?
(Reporter)

Comment 2

13 years ago
i want a Auto-Update pref where i can set:
Install all available Extensions without asking the user as soon as an update is available

This probably shouldnt be enabled by default, it can even be a hidden pref in about:config, but it would be really usefull for me
Summary: RFE: There should be a way to Auto-Update Extensions without asking the User → RFE: There should be a way to Auto-Update Extensions without user interaction
I don't believe this is something we would not want to add to the application and could be added as an extension for the users that want this. I'm leaving this open for now but this is wontfix in my opinion.
(Reporter)

Comment 4

13 years ago
so then why is there an option to check for Plugin updates and no option to install the updates?

we all learned the lesson that people *never* Update anything unless forced to to so. (there could be security Updates to extensions too, so not Auto-Updating them could be just as bad as not Auto-Installing Firefox updates)
(In reply to comment #4)
> so then why is there an option to check for Plugin updates and no option to
> install the updates?
Where is there an option to check for plugin updates and does this option to check for plugin updates have an option to do so silently? Perhaps you are referring to searchplugins? If so, they don't have anywhere near the power as extensions have to compromise or harm a system or the application.

> we all learned the lesson that people *never* Update anything unless forced to
> to so. (there could be security Updates to extensions too, so not Auto-Updating
> them could be just as bad as not Auto-Installing Firefox updates)
Since this would be opt-in or opt-out this is not a viable solution to the security problem. Also, doing so silently can just as easily create a security problem. There are also other bugs for dealing with the security issue (e.g. bug 318338).
(Reporter)

Comment 6

13 years ago
sorry, meant extensions not plugins
This isn't something we want for the application (e.g. inexperienced users, etc. per comment #5) and for the people that do want it it is available in an extension.
https://addons.mozilla.org/extensions/moreinfo.php?id=2098&vid=12600
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit

Comment 8

10 years ago
How are those same inexperienced users supposed to be able to judge
whether a random list of available updates should or should not be installed?

Comment 9

10 years ago
I agree with Frank.  This can't possibly be a useful security measure: users don't have the information they need to determine whether updating their extensions is a security risk.  If anything, it puts users at *increased* risk because more of them are running outdated extensions or updating their extensions manually (bypassing the update-MITM protection from bug 378216).

http://dilbert.com/fast/2008-08-09/
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
The situation now is quite different from when this bug was opened through comment 7. In the past users weren't informed when addons had updates, now we open a big dialog and tell them when they have updates. IIRC the dialog even has "details" links where the addon author can tell the user why they should update.

Addon updates are rarely security fixes from what I've seen. I'd hate to silently slip major changes in on the user without telling them, that creates unpleasant surprises. On the other hand I'd love it if we could flag specific updates as containing security fixes. The author could flag it when it's submitted for review to speed the review process (require an advisory about the problem that we'll link to (or even host) to prevent people claiming fictitious security fixes just to get through the queue, and bump abusers to the end of the queue or back into the sandbox), and we could flag the update itself on the update screen.

But those ideas are quite different than what this bug was asking for.
We would essentially need something like bug 304397 implemented and the bug it depends on before we could even think about doing something like this.
Depends on: 304397

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:want?]
Jesse, for clarity could you please bullet point the sg:wanted aspects of fixing this bug? Thanks

Updated

10 years ago
Duplicate of this bug: 408546

Updated

10 years ago
OS: Windows XP → All
Hardware: x86 → All

Comment 14

10 years ago
I am strongly in favor, from both a security and usability standpoint.  I also think this should be the default, like for Firefox itself.  It should be easier to stay up to date than to fall behind.

Security:

* Users often have out-of-date extensions, which sometimes have security holes. For example, only 87% of Adblock Plus users have the latest version, even though it is 3 months old and works in both Firefox 2 and Firefox 3.

* Asking users whether they want to update is essentially giving them a security warning dialog they cannot possibly have enough information to answer. This decreases the effectiveness of all security warnings.

* The annoyance of the built-in update mechanism tempts extension authors to provide their own update mechanisms, which may be less secure.

* Some users will update manually, which opens them up to phishing and MITM attacks.

Usability:

* Users who have lots of extensions or only run Firefox occasionally get way too many dialogs.

* The inconvenience for users means extension authors are more reluctant to make small improvements to their extensions than they would be otherwise.

Comment 15

10 years ago
The problem I have with Firefox add-on updates is WHEN and HOW they happen.  

I usually don't click an icon to open "Firefox".  I have icons and start-menu entries for each of my (and my wife's) most-used websites, and usually start up by clicking one of those.  

One of the add-ons I use is NoScript.  If NoScript has an update to apply, here's what usually happens.

1) My wife clicks on the icon for her job's website.
2) Firefox thinks a bit and then tells her that it can't access that website.
3) Eventually (after my wife has hollered for me because the 'stupid computer' is not working right) a message comes up to the effect that NoScript has an update to install.
4) I have to chase my wife away from the computer to give it time to do its thing.
5) I click 'OK' to the update and wait.
6) The update installs itself, and eventually Firefox comes up. (It takes awhile on my old, slow machine.)
7) WHEN it comes up, my wife's website DOES come up.  But in the meantime, I've paid a price that would make many people scrap that add-on.

BOTTOM LINE: I don't think that start-up is the right time to be updating these things.  When I have a job to do, I want to do it NOW.  I don't want to have to wait for the computer to do unexpected maintenance first.  The maintenance should do its best to work AROUND what I'm trying to do, and to NOT get in the way.  

When I start Firefox, I want it to:
1) Go where I told it to go.
2) Tell me that updates are waiting (in a separate window).
3) Tell me why the update is needed.
4) Give me AT LEAST these options: 
     a) Update now
     b) Update when I close Firefox
     c) Ask me again in __ days
     d) Ignore the update (if it's not critical)
     e) Disable the add-on
5) If I say 'Update now', do it and bring me back to my current webpage.
6) If I say 'Update when I close', do the download and all possible prep in the background, and set registry entries and anything else necessary to finish the update when Firefox closes.

In other words, the system should do whatever it can to work WITH me.  It should NEVER appear to be working AGAINST me.

Updated

10 years ago
Duplicate of this bug: 484763

Updated

10 years ago
Blocks: 489138

Comment 17

9 years ago
The problem would be that a major, extension-changing, dangerous update could be slipped to users without their knowledge. I suggest wontfix here.
(Reporter)

Comment 18

9 years ago
(In reply to comment #17)
> The problem would be that a major, extension-changing, dangerous update could
> be slipped to users without their knowledge. I suggest wontfix here.

A dangerous Extenstion should be blacklisted within firefox, preventing users from installing it anyways. (if such a blacklist does not exists, it should be)

Comment 19

9 years ago
(In reply to comment #17)
> The problem would be that a major, extension-changing, dangerous update could
> be slipped to users without their knowledge.

Perhaps, but to echo comment #8, how is a user supposed to know one way or another?

At the very least, that final "continue" button in the case of a successful
pass should be done away with.
(In reply to comment #17)
> The problem would be that a major, extension-changing, dangerous update could
> be slipped to users without their knowledge. I suggest wontfix here.

This is why we need something like bug 304397 and a trusted source to say how major/minor the updates are.

(In reply to comment #19)
> At the very least, that final "continue" button in the case of a successful
> pass should be done away with.

This is a different issue, and already fixed.
Duplicate of this bug: 505005

Comment 22

9 years ago
If silent update is evil, both silent update for firefox and addons should be removed

If silent update is not evil, both should be allowed, ofcourse, some more restriction can be applied such as digital signature verification or allowed only from trusted site.

I think the silent update can be implemented in this way
1) to disable addons update checking
2) to turn on addons checking and prompt user for download and install (May be the default action)
3) to turn on addons checking, download silently and prompt user for install
4) to turn on addons checking, download and install silently (maybe only allowed for
trusted website? or digitally-signed addons?)
Blocks: 511529
Blocks: 511529

Comment 23

9 years ago
In addition to the other concerns raised, there needs to be addressed "globally" installed add-ons (add-ons installed in the program installation folder). If the browser is not able to install an update to an add-on where it is installed--program installation extensions folder vs. individual profile extensions folder--this feature would introduce user headaches that otherwise would not have happened.

Comment 24

8 years ago
dup of (or will be fix by) bug 553503?
This is basically fixed by the extension manager rewrite. bug 553503 will cover improving some of hte UI around it though.
Status: NEW → RESOLVED
Last Resolved: 13 years ago8 years ago
Resolution: --- → FIXED
Correct. Works fine on trunk. Marking as verified fixed by bug 553169.

Dave, how does bug 304397 play into account here? Is the distinction between major and minor updates still valid for that particular bug? I will remove it for now from the dependency list.
Status: RESOLVED → VERIFIED
Depends on: 553169
No longer depends on: 304397
Target Milestone: --- → mozilla1.9.3a5
Flags: in-testsuite?
Flags: in-litmus?
Version: unspecified → 1.8 Branch
(In reply to comment #26)
> Correct. Works fine on trunk. Marking as verified fixed by bug 553169.
> 
> Dave, how does bug 304397 play into account here? Is the distinction between
> major and minor updates still valid for that particular bug? I will remove it
> for now from the dependency list.

There is no concept of update severities. Unless a user opts out all add-ons will be updated automatically.
Flags: in-litmus? → in-litmus?(vlad.maniac)
Dave, any reason we need a manual Litmus test here? Don't we have this covered by any automated test yet?
We certainly have xpcshell tests that verify that updates work in the background, I don't think that includes tests that check the UI in this case yet though.
You need to log in before you can comment on or make changes to this bug.