Automatic and silent minor updates?
Alex Faaborg
> at how to address that, because we ship a lot of updates and they're
> pretty important.
>
> This could likely be a d-a-f thread.
Refining our update install process is something I think we should
consider targeting for the next release. In addition to the fact that
update dialogs appear to be one of the largest pain points for our
mainstream users right now, there is the security consideration that
any given moment only 80% of our user base has applied the latest
security patches. We are using this tracking bug for the overall
topic: https://bugzilla.mozilla.org/show_bug.cgi?id=489139
The short version is that the ideal solution may have these three
attributes:
1) automatic and silent security updates on by default
2) the ability to deploy a special OMG update, which we only use in
case of extreme emergency. This might actually prompt the user, or it
might even force a restart and restore in a certain time period based
on how serious the security concern is
3) give users the ability to roll back to an older version (and in the
process be sure to ask them how we broke the Web, because if the user
actively downgrades, they must have a good reason)
Prompting everyone ahead of time is illogical under the assumption
that the majority of our user base would rather load the browser
faster and browse the Web without any pop-up dialog interruptions, as
opposed to having control over something they don't really care
about. Additionally for the minority that does want to carefully
manage what minor versions they are running, they won't know if a new
version is going to be problematic until they have actually tried it,
so preemptive consent isn't useful. The control that this group
really needs to have is undo.
-Alex
On Jun 9, 2009, at 1:51 PM, Mike Shaver wrote:
> On 9-Jun-09, at 4:48 PM, Al Billings wrote:
>> See, I wanted to promote it to some of my Web Design/Developer
>> friends but if I have to tell them to download Beta 4 and then
>> check for updates, a lot of them won't bother. I don't want to
>> point them to our FTP servers either but we have no load balanced
>> way to direct download. I think it will confuse people if it gets
>> blogged about or makes the news.
>
> Yes, we wanted to do a bunch of other stuff that we didn't, because
> of resource and tooling constraints. If installing a single update
> is that big a barrier, we should look at how to address that,
> because we ship a lot of updates and they're pretty important.
>
> This could likely be a d-a-f thread.
>
> Mike
>
Robert Strong
regards to implementing Windows Installer (e.g. MSI) since App Update on
Windows would most likely need to use the MSI patching mechanism for
updates.
Couple of reasons to go with MSI
* supports non admin user updates if the update is signed
* is the standard install mechanism for Windows (e.g. well known
user experience)
* gets us closer to group policy support
* lessens our direct exposure to update vulnerabilities
Couple of issues if we go with MSI
* less ability to customize the install experience
* only one install allowed per MSI app id (e.g. branch nightly,
trunk nightly, release) which cannot (or at the very least should not)
be updated to a different MSI app id
* less control over the update process
* a significant amount of work especially as it relates to our
build and locale repackaging process
* RelEng would need to follow a new process for creating MSI
patches (e.g. MSP's)
* increases our indirect exposure to update vulnerabilities
There are a bunch of questions that need to be answered and research
that needs to be done to figure out how best to implement MSI for
Firefox and I think that if we want to go down this path for
Firefox.next it should happen as soon as possible. The alternative would
likely be putting off MSI until after Firefox.next.
Prior to implementing MSI I think the following bugs should be fixed
1. Update notification for non-privileged users
https://bugzilla.mozilla.org/show_bug.cgi?id=407875
2. Update elevation for non-privileged users when possible based on OS
https://bugzilla.mozilla.org/show_bug.cgi?id=318855
3. Update UI rewrite
https://bugzilla.mozilla.org/show_bug.cgi?id=476501
4. Fix update notification prompt
https://bugzilla.mozilla.org/show_bug.cgi?id=462568
5. Clean up overridden values in update xml
https://bugzilla.mozilla.org/show_bug.cgi?id=475671
This last bug needs to be morphed. The overridden values caused a last
minute blocker for 3.5 and this should really be cleaned up to prevent
this from happening in the future.
For the Update UI rewrite it would be very helpful to have info on
"update dialogs appear to be one of the largest pain points for our
mainstream users" if it is in regards to interaction with the UI. If it
is in regards to just the displaying of the UI for updates then the
problem is fairly well understood and additional info should be added to
https://bugzilla.mozilla.org/show_bug.cgi?id=489139
or
https://bugzilla.mozilla.org/show_bug.cgi?id=489138
Cheers,
Robert
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Alex Faaborg
> * less ability to customize the install experience
Can you provide more information about what the less control would
entail? For instance, something that we might want to consider with
the install experience is having a very small app download that then
downloads the real installer, under the assumption that this would
increase the percent of people who actually complete the installation
(a surprising percent cancel the download or never open the
installer). Would going with MSI take away our ability to do this?
> For the Update UI rewrite it would be very helpful to have info on
> "update dialogs appear to be one of the largest pain points for our
> mainstream users"
> If it is in regards to just the displaying of the UI for updates
> then the problem is fairly well understood
Yeah, this is in regards to simply displaying the UI at all, and I
believe that in many cases users also do not understand the difference
between a Firefox update and an extension update. So some of the
complaints about Firefox updating too often are actually misdirected
complains about extensions updating. A lot of people don't realize
that their computer speaks with more than one voice, and either case
they would like it to speak less (regardless of if it is Firefox or an
extension that is seeking their approval).
-Alex
Robert Kaiser
> Couple of issues if we go with MSI
One more:
* We would need to figure out all update procedures in both MSI for
Windows and our own solution for other platforms in parallel
One reason why we have been mostly avoiding platform-specific solutions
so far is that we can write one set of code and procedures that apply on
all platforms we support (tier-1 and even tier-lower).
Robert Kaiser
Robert Strong
>> Couple of issues if we go with MSI
>> * less control over the update process
>
>
> Can you provide more information about what the less control would
> entail? For instance, something that we might want to consider with
> the install experience is having a very small app download that then
> downloads the real installer, under the assumption that this would
> increase the percent of people who actually complete the installation
> (a surprising percent cancel the download or never open the
> installer). Would going with MSI take away our ability to do this?
installer / uninstaller that aren't standard for installers /
uninstallers and it is very possible that some of these customizations
wouldn't be possible with MSI or could be very difficult with most of
these being discovered during the initial investigations.
A stub downloader as you described would still be possible with MSI.
Cheers,
Robert
>> Couple of issues if we go with MSI
John J. Barton
...>
> Yeah, this is in regards to simply displaying the UI at all, and I
> believe that in many cases users also do not understand the difference
> between a Firefox update and an extension update. So some of the
> complaints about Firefox updating too often are actually misdirected
> complains about extensions updating. A lot of people don't realize that
> their computer speaks with more than one voice, and either case they
> would like it to speak less (regardless of if it is Firefox or an
> extension that is seeking their approval).
I agree the basic model of user-empowerment is broken by having
pointless popup dialogs with insufficient information, tedious progress
graphics, and controls that don't actually have any function. The
extensions use the same model and magnify the problem.
I think the origin of the problem is a compromise that satisfies no one:
allow control over the update process but not make that control
obnoxious. Since the control is weak, it is ineffectual, but attempts to
allow control annoy.
One solution is to shift the compromise in one direction or the other;
as I understand Alex's proposal it is a shift away from 'control'.
Another solution is to break the user-population into controllers and
passive followers. Followers delegate update control: they never see
dialogs or progress etc. Controllers decide when to accept updates and
they take responsibility for the followers user experience. This is a
natural extension to extension bundling discussed for AMO and to the
extension bundling used by eg eclipse. This also addresses the "which
ones of 8000 extensions to install" problem. It is related to our
upcoming effort on Firebug 1.5 to bundle pre-tested Firebug extensions.
jjb
Mike Beltzner
> Refining our update install process is something I think we should
> consider targeting for the next release. In addition to the fact
> that update dialogs appear to be one of the largest pain points for
> our mainstream users right now, there is the security consideration
> that any given moment only 80% of our user base has applied the
> latest security patches. We are using this tracking bug for the
> overall topic: https://bugzilla.mozilla.org/show_bug.cgi?id=489139
It's actually much closer to 90% within a major version (ie: all
2.0.0.x users on latest-2.0.0.x, all 3.0.x users on 3.0.x-latest, etc)
It's unclear that the 10% who aren't updating within a major version
range are all doing so by choice (ie: by turning off "automatically
check for updates") as opposed to being "trapped" in a minor version
due to some other problem with the update process. Arguably, that's
even more frustrating :)
Assuredly, though, some subset of our userbase has turned this feature
off, and some subset of that group did so due to update fatigue.
Further, people who haven't turned off automatic updates most
assuredly do suffer from update fatigue.
> The short version is that the ideal solution may have these three
> attributes:
>
> 1) automatic and silent security updates on by default
As I mentioned in the bug, I don't think we want 100% silent. We want
"zero-interruption," which is not what we have now. It is my ardent
belief that there are transient, non-interrupting ways in which we can
pleasantly inform users that they've gotten an update, are more safe
for it, and should go about their business.
I don't see this as a branding issue, I see it as one of comfort. If a
user is to read about some new web threat, it is comforting to know
that their browser is being constantly updated to keep them safe.
Further, I am also sympathetic to the argument that, unlike a website,
this is software that lives on a user's computer, and letting them
know when it is modified or changed is ... just ... polite.
> 2) the ability to deploy a special OMG update, which we only use in
> case of extreme emergency. This might actually prompt the user, or
> it might even force a restart and restore in a certain time period
> based on how serious the security concern is
This seems virtuous. To achieve "zero interruption" without figuring
out how to install updates without a restart, we'll need to hold off
on insisting that the user restart. That's fine for most updates, but
in cases where we're shipping fixes to zero-day exploits, we probably
want a way to sound some sort of horn.
> 3) give users the ability to roll back to an older version (and in
> the process be sure to ask them how we broke the Web, because if the
> user actively downgrades, they must have a good reason)
I'm less sure of this. Email histories will point out that I've
usually been pretty insistant on having roll-back ability, but the UI
there gets horrendously complex (how do you manage re-applying a
rolled back update?) and I'm not sure it's worth it.
I'd much rather we get better at ensuring that we never ship an update
that someone wants to roll back than invest in enabling rollbacks in
the first place.
> Prompting everyone ahead of time is illogical under the assumption
> that the majority of our user base would rather load the browser
> faster and browse the Web without any pop-up dialog interruptions,
> as opposed to having control over something they don't really care
> about. Additionally for the minority that does want to carefully
> manage what minor versions they are running, they won't know if a
> new version is going to be problematic until they have actually
> tried it, so preemptive consent isn't useful. The control that this
> group really needs to have is undo.
I'm not sure how we got to here ... when do we prompt someone ahead of
time? I think I'm missing something.
cheers,
mike
Justin Dolske
> 3) give users the ability to roll back to an older version
I'm wary of this for a few reasons:
* Users are typically very bad at determining correlation-causation
relationships. We could easily end up with lots of people reverting to
old versions because they *think* it was the cause of some problem, but
in reality it was something entirely unrelated.
* Users who roll back are almost certainly not going to undo that
rollback until the next version comes out, so they're going to have an
increased window of vulnerability. I'd also worry that, in general,
providing more knobs to control upgrades will just result in fewer
people upgrading for various reasons.
* Rollbacks are likely going to be complex to implement and won't be
well tested (compared to the huge numbers of users upgrading forwards).
So I'd be concerned about the development/QA cost to make this reliable,
considering that it shouldn't even be a commonly used feature. This
effort would be better spent at making *upgrades* more reliable, IMO.
* This feels a lot like a feature that's only going to be seen/used by
1% of the most advanced users; while the rest of the user base will be
completely oblivious to its presence.
Justin
Robert Strong
restore points for app update which could provide this functionality on
Windows and found that the time it takes to create the restore point can
easily take longer than the time it takes to apply the update itself.
There is also the issue of restore points for nightly users in that the
restore points are first in first out which means we would cause other
restore points to drop off much faster than normal.
https://bugzilla.mozilla.org/show_bug.cgi?id=351216
Cheers,
Robert
Alex Faaborg
> range are all doing so by choice (ie: by turning off "automatically
> check for updates") as opposed to being "trapped" in a minor version
> due to some other problem with the update process. Arguably, that's
> even more frustrating :)
Yeah, I think that may be the case as well. However it would be
interesting to track with Test Pilot how often users click "not now,"
because for some users, it may end up being a kind of a continuous
thing. Kind of like not setting the flashing 12:00 on your microwave
because it takes a small amount of time, but that immediate decision
in favor of short term gains ends up causing more discomfort overall.
It might be the case that we have a set of users who update every
time, and a set of users who click "not now" every time.
> I see it as one of comfort. If a user is to read about some new web
> threat, it is comforting to know that their browser is being
> constantly updated to keep them safe. Further, I am also sympathetic
> to the argument that, unlike a website, this is software that lives
> on a user's computer, and letting them know when it is modified or
> changed is ... just ... polite.
I view it more as an implementation model in the interface model
issue. I think telling the user that a (roughly) bi-monthly update
has been applied is just as slightly impolite as an operating system
that informs you when it has automatically defragmented the hard
disk. Also while I believe there are lot of Firefox users who
switched after IE gave them a loads of malware/spyware/adware,
shouldn't simply the lack of these problems serve as a reminder that
they are being kept safe.
Do we know that user's reaction to "we patched a vulnerability" is
more likely to be "great, I'm now safe again" or "what, why did you
have that vulnerability in the first place? I trust you slightly
less." (or perhaps the third option of not reading the dialog,
clicking the whatever button, and then being every so slightly annoyed
that something momentarily took a segment of their attention).
> I don't see this as a branding issue, I see it as one of comfort
For the user to be more comfortable knowing when software is updating
on their system, as opposed to not knowing, I think they need to share
a lot of the same values that we all have about software, and control,
and versions. I honestly don't know how mainstream these views are,
and I think it would be useful for us to try to find out.
-Alex
Robert Buecheler
>> It's unclear that the 10% who aren't updating within a major version range
>> are all doing so by choice (ie: by turning off "automatically check for
>> updates") as opposed to being "trapped" in a minor version due to some other
>> problem with the update process. Arguably, that's even more frustrating :)
>
> Yeah, I think that may be the case as well. However it would be interesting
> to track with Test Pilot how often users click "not now," because for some
> users, it may end up being a kind of a continuous thing. Kind of like not
> setting the flashing 12:00 on your microwave because it takes a small amount
> of time, but that immediate decision in favor of short term gains ends up
> causing more discomfort overall. It might be the case that we have a set of
> users who update every time, and a set of users who click "not now" every
> time.
As a user, I keep FF (and the system) running 24/7 with certain pages
open to compare previous values at a glance (if I close the tab/window
I lose that info) so I only update FF and add-ons when I know nothing
is changing.
When M$ tells me there's a new update, I check what it is, and upon
that info I update or wait as mentioned above.
I.e. last reboot of the system was June 4, and FF has been running
since at least June 6. (is there an about: page to see how long FF has
been running?
OK, looking at the "oldest" open page, the [page info] says: Saturday,
June 06, 2009 3:03:33 PM
so that's when FF was last restarted (can't remember why though - last
update was end of April)
Personally, I'd rather know about the update beforehand and decide
when to install it.
On other systems, I have automatic installs set up, although to the
users they are confusing at times, as the messages pop up and they
don't know what to do.
>> I see it as one of comfort. If a user is to read about some new web
>> threat, it is comforting to know that their browser is being constantly
>> updated to keep them safe. Further, I am also sympathetic to the argument
>> that, unlike a website, this is software that lives on a user's computer,
>> and letting them know when it is modified or changed is ... just ... polite.
>
> I view it more as an implementation model in the interface model issue. I
> think telling the user that a (roughly) bi-monthly update has been applied
> is just as slightly impolite as an operating system that informs you when it
> has automatically defragmented the hard disk. Also while I believe there
> are lot of Firefox users who switched after IE gave them a loads of
> malware/spyware/adware, shouldn't simply the lack of these problems serve as
> a reminder that they are being kept safe.
>
> Do we know that user's reaction to "we patched a vulnerability" is more
> likely to be "great, I'm now safe again" or "what, why did you have that
> vulnerability in the first place? I trust you slightly less." (or perhaps
> the third option of not reading the dialog, clicking the whatever button,
> and then being every so slightly annoyed that something momentarily took a
> segment of their attention).
or "great, now I lost the info I was checking on"
or "why do I have that message box with [reboot now to apply new patches]?"
>
>> I don't see this as a branding issue, I see it as one of comfort
>
> For the user to be more comfortable knowing when software is updating on
> their system, as opposed to not knowing, I think they need to share a lot of
> the same values that we all have about software, and control, and versions.
> I honestly don't know how mainstream these views are, and I think it would
> be useful for us to try to find out.
on some systems I like the control, on others I prefer the automatic updates.
--
Robi