489138 - [meta] Make the minor update install process entirely transparent to the user

Status: NEW

(Firefox :: Security, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug is a subset of the problem that on any given day only 80% of Firefox users have installed the latest minor updates, putting them potentially at risk for security vulnerabilities.

In addition to the security concerns, I believe that Firefox's current notification-based interface for security updates is disrespectful to the user.  The general types of comments I've heard regularly from mainstream users include:

--why can't you just get it right the first time, why do you have to keep tweaking little things, I can't even see what you are changing.
(user does not realize there is a security implication and assumes the changes are trivial enhancements)

--I'm trying to load Firefox to get some information quickly and it gets in my way

--While using Firefox I keep hitting not now

Firefox 3.5 will now only prompt after the current version has been out of date for more than 24 hours, I think we should do everything we possibly can to make the process transparent, including:

-automatically restarting when the user isn't around if we know we can restore the session perfectly (or in the case of text entered with an ssl connection, perhaps make an exception with storing and restoring the information)

-retain the ability to automatically restart on issues that we believe are significant risks, so if having the user wait 4 or 5 days to turn their computer off for the weekend isn't a big deal, we don't do anything.  Alternatively if a super critical vulnerability is hitting taking down extremely large user populations, we also have the ability to do a force restart once the update is available.

-carry out as much of the installation ahead of time and in the background as possible, so the user doesn't have to see a progress bar, and the update is nearly instantaneous

Comment 1

[Dão Gottwald [:dao]]

> -automatically restarting when the user isn't around if we know we can restore
> the session perfectly (or in the case of text entered with an ssl connection,
> perhaps make an exception with storing and restoring the information)

You'd have to be quite conservative with that, as we know that we can't restore some things, like the states of plugins and (I think) non-trivial JS apps.

And what if the internet connection is flaky?

It seems that we currently can't implement this as transparent as you imagine it. Effectively, silently waiting for the user to quit and restart the browser is probably more transparent.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Alex, further we should also reduce the amount of dialogs which popup after an update was installed. That's another behavior which people don't like. I have heard this a couple of times lately.

Comment 3

[Jesse Ruderman]

Which dialogs are those?  Notification of the update, extension compatibility checks?

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>extension compatibility checks?

I'm particularly concerned about this one.  What if Microsoft falls behind with updating the .NET Framework Assistant (that they automatically install), and users get interrupted with a wizard interface full of fail every single time we update, which is sometimes as often as twice a week.

Comment 5

[Robert Strong (they/them - no direct email)]

As far as the update ui as of 3.5 we only show incompatible extensions that are enabled and weren't also incompatible with the app version that was in use previously so once it is incompatible it will only be shown once.

The extension manager compatibility wizard which is displayed on first run after an app update will display all incompatible extension.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Jesse, these are all dialogs of this sort, yes. But as Rob said, there has been made a change for 3.5. I haven't followed this part in detail.

Take an example when users only want to verify the transportation schedule next to their house a couple of minutes before they have to leave. It's still time critical and now during startup a probably downloaded update is installed, extension checks are performed and upgrades for incompatible extensions are downloaded and installed too. This will take half a minute or more.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #0)
> -automatically restarting when the user isn't around if we know we can restore
> the session perfectly (or in the case of text entered with an ssl connection,
> perhaps make an exception with storing and restoring the information)

Automatically restarting is a non-starter (ha!) IMO, as I don't think it's possible to get the "if the user isn't around" bit right, especially in an age where people watch multi-hour long videos in their browser. Perhaps some sort of confirmation based UI? Equally-but-not-as-drastically annoying?

Further, as Dao mentions, sites that use JS to manipulate the DOM are hard to restore perfectly, so I wouldn't make that a criterion. Instead, I'd go for "almost perfectly" or figure out the 95% case and find a solution for that.

I do think we should feel free to run the updater on shutdown instead of startup, or find some way to apply it like a "restart", though.

(I'd prefer that we be able to apply an update without a restart, as Chrome does, though that likely requires some degree of process separation)

> -retain the ability to automatically restart on issues that we believe are
> significant risks, so if having the user wait 4 or 5 days to turn their
> computer off for the weekend isn't a big deal, we don't do anything. 
> Alternatively if a super critical vulnerability is hitting taking down
> extremely large user populations, we also have the ability to do a force
> restart once the update is available.

I really, really don't like the idea of forcing a restart, period. I do like the idea of reflecting the update severity in the MAR file, though, and reacting differently to it. So a severe update could actually get UI notification, while a non-critical update could just wait until the next restart.

> -carry out as much of the installation ahead of time and in the background as
> possible, so the user doesn't have to see a progress bar, and the update is
> nearly instantaneous

Totally agreed.

I also think we should:

 - not load a "whatsnew" page in a new tab, but instead use some other form of notification (perhaps like about:rights) to tell users that they've been updated and if they want to find out more, they can Learn More...

 - hide the add-on update dialog entirely; just do that in the background and tell me if there was a problem, which is only 0.0001% of the time

Comment 8

[Sylvain Pasche]

(In reply to comment #7)
> (I'd prefer that we be able to apply an update without a restart, as Chrome
> does, though that likely requires some degree of process separation)

Chrome still requires a restart for applying an update. However the update is applied in the background by a Windows service, so next time the browser is (re)started there is no wait. And if the browser is not running, the update service will also update it in the background. I'm not sure if there is a "you should restart your browser" notification when an update has been applied in the background and the user should restart the browser.

Comment 9

[Robert Strong (they/them - no direct email)]

One idea I have been considering for Windows is having a service verify that there are no instances of the installation running and applying the update in that instance which would remove the restart as well as the UAC prompt (Vista and above) requirement for the silent case.

Another consideration - a major one IMO - is whether we want to go with MSI since updating the install / uninstall info for an MSI from our app update would be at least a major PITA and might not be realistically possible. MSI also has an update mechanism that allows non admin users to update as long as the cert used to sign is the same.

There are a lot of issues with implementing MSI for us (e.g. build env, localization, repackaging, binary versioning, trunk nightly / branch nightly / official / beta / etc. MSI app ids, and the list will just get longer) and implementing MSI will affect app update in a big way. I personally think that immediate investigation of these issues needs to happen asap for Firefox.next so that people don't end up having to perform a significant amount of time reworking app update due to changes needed for implementing MSI or we need to make the decision not to implement MSI for Firefox.next and possibly the release after Firefox.next.

Comment 10

[Robert Strong (they/them - no direct email)]

btw: I am willing to take on MSI for Firefox.next which would entail figuring out how app update would work with MSI as well as making the process transparent to users for MSI installations but I'd like confirmation that is the direction we want to take since it will take a considerable amount of time to complete.

Comment 11

[Sorin Sbarnea]

I think that this bug is a duplicate of #446342. The only difference I see that this one does specify this only for minor updates and the other one for all kind of updates.

Comment 12

[u88484]

That user wants the entire process to be silent (minor and major and no notification).  That is a big no no to me.  Minor updates should definitely be silent...no l10n changes, no theme changes, no api changes, most of the time no extension issues.  Major updates do all of the above and that is why users tend to wait to update Firefox when a major update comes up.

Note: Minor is like 3.5.2 -> 3.5.3.  Major is like 3.5.9 -> 3.6.0

Major updates come around every year while there is usually a minor every 4-6 weeks (I believe that is the window).

Comment 13

[Leen Besselink]

What parts of Firefox usually get updated ? Would it be possible to have 2 directies ? I'm now looking at my firefox directory and I see a lot of files, but most of the executables/shared-libraries are in the top-directory and some in the components directory. Are those the ones that get updated the most ?

Hmm, looking at it 3.5.0, 3.5.1 and 3.5.2 (linux, because it's not an executable, but an archive-file) and it's, kinda true. One thing that I immediately noticed is, all the jar files in the chrome-directory seem changed, but when you compare the files inside, you'll see a lot of jar-files haven't changed. It's just they've been packaged again or the file timestamps changed or something like that.

When you diff the jar-files, you'll see small changes at the PK-header-things only. My guess is these are the directory-entries ?

Just a few files in the jar-file have changes, especially between versions.

Too bad, libxul.so has so many changes, it's by far the largest file of all. So in it's current form, doing a simple binary patch or something wouldn't add as much as I would hope.

Because updates faster and in the background, possible having 2 versions in different directories so you could easily choose  an other on startup. It should possible be the software that can choose, maybe a small notification could be shown that needs no action from the user. Would have been useful.

Comment 15

[Joel Siegel]

I have a concern about this proposal that may have already been considered or addressed, but just in case, here it is:  At least in certain systems, the user may not be privileged to modify application files or directories, which can cause problems with the updates up to and including software breakage.

Personal example: I run as a standard (non-admin) user 98% of the time on my Mac OS X box.  Standard users cannot modify /Applications/ without authentication as an adminstrative user.  When I was using Camino, it would auto-update in the background but the update process would not complete due to the privilege restriction I described.  I never found the UI to either defeat this "feature" or to have it prompt me for authentication so it could complete successfully.  IME what would happen was that a currently-running instance of Camino would begin to act wonky, and after a quit (or force quit) I would find a "generic app" icon where Camino used to be, with a size of around 4K.  Once I launched a different browser, downloaded the new version and installed it manually, everything worked fine.

Comment 16

[WulfTheSaxon [:Wulf]]

(In reply to comment #15)
> I have a concern about this proposal that may have already been considered or
> addressed, but just in case, here it is:  At least in certain systems, the user
> may not be privileged to modify application files or directories, which can
> cause problems with the updates up to and including software breakage.
> 
> Personal example: I run as a standard (non-admin) user 98% of the time on my
> Mac OS X box.  Standard users cannot modify /Applications/ without
> authentication as an adminstrative user.  When I was using Camino, it would
> auto-update in the background but the update process would not complete due to
> the privilege restriction I described.  I never found the UI to either defeat
> this "feature" or to have it prompt me for authentication so it could complete
> successfully.  IME what would happen was that a currently-running instance of
> Camino would begin to act wonky, and after a quit (or force quit) I would find
> a "generic app" icon where Camino used to be, with a size of around 4K.  Once I
> launched a different browser, downloaded the new version and installed it
> manually, everything worked fine.

There are a few bugs about that (notably bug 318855 and the bugs blocking it, and bug 407875) blocking bug 489139, which depends on this.

Comment 17

[Marc Schumann [:Wurblzap]]

Attachment: Update-Bar

This is what I'd like to see. Note the missing "X" -- no way to remove the bar if there is an update ready.

Update is already applied, restart is a matter of seconds; I can have it done when leave the keyboard for a minute or when I feel I can spare these couple of seconds.

Comment 18

[Jesse Ruderman]

> restart is a matter of seconds

You trust session restore more than I do ;)

Comment 19

[Tyler Downer [He/Him]]

What is still needed here? We have very silent updates in current Firefox versions, so is this bug irrelevant now?

Comment 20

[Thomas Bertels]

Bug 579990 makes the user aware of the update and interrupts him on the next startup.