Ayatana : Issues with the Update Manager and updates in general

The goal of this page is to identify current issues in the process of package updates and to confront currently proposed solutions to each of these issues, in order to determine how well they are addressed.

We need to voluntarily adopt a paranoid point of view regarding security updates. For every flaw is considered serious enough by the security expert people to be granted a SRU, we need to deploy a fix as fast as possible. History has shown that a (critical) security flaw could be exploited 6 days after it was unveiled. If we count a good 2/3 days in order to make the update available at download, it means the time left to fix it is short, and thus we need to make sure users will update within a few days in order to be totally safe.

Identified issues

You are welcome to add more valid issues , try to avoid duplicates. Don't modify or remove someone else's issue without discussion on the ML. Please explain why they are issues, and what are the negative consequences they have.

The issues currently identified, by the Ayatana Discussion members, are :

1. Some updates take effect only after a reboot

Some updates, typically kernel and modules updates, take effect only after a reboot. Those updates, in the current Ubuntu stable releases, are allowed only if they are important security updates that need to be performed for the safety of the users. If the users don't reboot after performing the updates with the current implementation, they put themselves at risk till they reboot.

Even among users who do perform their security updates quickly, some may forget to shut their computer down and thus stay at risk.

2. Some updates require an application to be restarted, otherwise this application doesn't work as expected

Some applications, when updated, require an immediate restart in order to keep working. This is the case of at least one default application : Firefox. As the applications need to be restarted in order to keep working, this actually breaks the user's workflow.

3. The update notification mechanisms should never be rude / intrusive towards the user, at the risk of the user trying to neutralize it

Even if security issues are important and even if they may require some additional mechanisms than the normal updates, the goal of changes in the update-manager's policy is to increase the amount of people performing security updates.

If a majority of users (I consider this due to a very low level of expectation from users towards their OS) will accept intrusive or coercive methods for making them perform the updates, another part of the users may refuse anything they consider intrusive, and try to disable methods used to notify them of security updates. We should thus be looking for ways that will have a similar rate of fast updates with a consequently lesser rate of unhappy (end/average) users.

4. A fair proportion of users do not perform security updates fast enough

GNU/Linux is safer than other OSes because security breaches are unveiled, fixed and deployed faster than any OSes using a proprietary development model. If unveiling and fixing are usually performed extremely fast, deploying is often too slow - sometimes slow enough for a flaw to be exploited.

Some people will argue that they will be exploited on a little scale, but there are people who would benefit from an issue on a large number of machines (opponents, malicious hackers, commercial security products editors, etc.). The way we can avoid this is by making the deployment part as fast as possible, and hit the most important amount of machines possible. This is why security updates must be performed within days, and once the fix is patched and available in the repositories, we should have a 80% adoption rate in 3 days and a 90% adoption rate in a month.

5. "Restart Required" alert is misleading for users ,Especially for new users from Windows

In Ubuntu/Linux Restart is 'not required' for the updates to be installed but rather only needed to start using the new updated version.

New users to Ubuntu are most often from Windows OS , where "Restart Required" almost means a warning that they can expect grave consequences if the system is not restarted immediately. Which is true in Windows, Programs most often tend to misbehave/freeze. Hence most users restart immediately to avoid loss of work. The Windows dialogue also includes :" Windows can't update important files and services while system is using them " , which the average user is most used to, and thinks this is the same in Ubuntu, And feels the need to stop his work lest his system should freeze/hang.

Template For Ideas

Idea name

Rationale

This is primarily designed to solve issue #X and #Y.

Description

Describe the idea in a few short paragraphs, almost exhaustively , ie. I should make sure that what I propose can be interpreted only one way, so that if people like my idea but think it is perfectible, they can edit it and make it better, without leaving too much room for differences of interpretation that would provoke the need for a rewrite and reevaluation during the implementation if my idea.

Consequences for issue #X

Describing the expected result for the issue you are trying to address. It should be done for all the aimed issues, and also the issues for which you suspect there will be negative consequences. I shall not do it at all for issues which are not concerned and upon which my idea visibly has no consequences at all. I can give an explicit rating between -5 and +5 (that's all about feelings though).

Conclusion

Here try to explain why you think the downsides are worth the upsides, and propose ideas that may be able to make the user experience even better if used with this one.

Sidenote : one may disagree with another, but in order to keep things constructive, i think one should comment the idea directly but keep the original description. One comment per person sounds fair, and people can then edit their own comments for each idea. Also, don't hesitate to give a mark to other ideas so that we can see which ideas have a consensus and which need debate. Thanks for reading till here ! (Template is very probably perfectible)

Ideas

If you think you have an idea that could address one of the above issues, please describe it and evaluate it's influence on all the listed issues. You can use the template for adding your own proposals .

Progressively intrusive update notifications upon time

Rationale

The idea is to propose a good fix for the issue 4. (updates must be done) without forgetting 3. (updates shall'nt be intrusive) in the process.

Description

We will consider security and normal updates separately. We will also make the distinction between the kind of account (can / can't perform updates) and also whether or not other admins (by admin i mean someone who has the rights to perform updates) logged in since last security update was available, and propose a behaviour for each situation :

Security updates - Admin account

• The first 48 hours of availability

Use the tray icon to notify the presence of security updates, plus an unique libnotify notification per day (8.10 behaviour).

• Between 48 and 72 hours of availability only of the tray icon already spawned

When the admin logs in, spawn Update Manager unfocused, and only once.

• After 72 hours of availability only if the Update Manager spawned unfocused once

The Update Manager now spawns with a warning icon and a message explaining the importance of updates, it also contains a checkbox proposing automatic security updates (as in software-properties-gtk). You can see a mockup (with a quite bad wording) below.

• If the user performs some updates but not all the security updates available

It means (s)he may have good reasons to believe (s)he should not install packages that would possibly break his/her system, or that some packages couldn't install. The best approach is probably to go back to the tray icon till other security updates are available, in which case we go through the above procedure again.

Security updates - Restricted account - No admin logged in

• After 7 days of availability

Show a notification bubble at the opening of the session, and only once (till other security updates arrive), that more or less says "Important security updates have been available for a while now. Please contact your system administrator", for the companies that "forget" updating their machines or setting them to auto-update for security updates.

Normal updates The tray icon is enough in this case. I really don't see why the update manager should have a rude behaviour for non-security updates. If some users don't want to perform updates and prefer carrying bugs till the next LTS release, then so be it. At worse, you could spawn the update manager unfocused once if normal updates have been pending for at least two weeks, but I don't think it's needed to spawn it every week, and focused. Users should not get used to being disturbed.

Consequences for issues

• 3. I think there is a (little) positive impact for this issue. That is to say, instead of popping-up on first day, you leave users with a mechanism that allows them to chose when they want to open the Update Manager. And if on second day they didn't then only you begin poking them.

As for normal updates, I think this proposal is better than the current way it is. There is no need to urge the users for normal updates (ok, there can be dramatical bugs like "your FS is wiped when you do this or that", but I don't believe this is frequent enough to systematically bother users about normal updates).

• 4. The impact compared to the current implementation is almost null : the user is still notified every day about security updates, but if he doesn't perform them for a while, he's asked if he wants to toggle automatic security updates. This will not change paranoiac users' behaviour, but at least lazy users could learn about this possibility and stop delaying security updates for no reason.

Conclusion

I think that this proposal will significantly less disturb users who do perform their updates as soon as they're available and who complained about popups opening without their explicit consent, without damaging the efficiency of the current update notifications. ---SiDi

Hassle-Free In-Session Updates

Rationale

The main rationale is to allow the user to focus on his work without being troubled by updates/restarts and In-session updates allow us to finish the updates without the user having to wait on the update installation.

Since updates are not the main concern for an end-user , but rather, updates are the responsibility of the OS devs to ensure the OS is secure. The update process has to be non-intrusive and simple, to ensure that users update regularly.

Users most often do not perform updates because, Updates often end up obstructing work-flow/system usage and thus users tend to postpone updates or avoid them totally. Obstructions are either:

• 1.User is actively using the Network , so doesnt do the updates to avoid interruption of bandwidth.
• 2.User is on a pay-per use network connection.So avoids downloading large updates.[for the first 2 the OS can only provide few solutions]

• 3.Certain Updates force the user to restart. [> This can be easily corrected in Ubuntu]

User scenario Groups:

• A. On an average , users spend 14.6 hours per week on their computers. Which is roughly an average system usage of 2-3hrs daily after which users shut down the system at the end of their work.

• B. Systems run only 1-2days very week[weekends] and are shutdown at the end of the use.
• C. Systems running for an average of 9Hrs daily and are shutdown at the end of the day.
• D. Some users hibernate/suspend the system after their work.
• E. A very minor percentage of users keep their system running.

Since the majority of users shutdown the system regularly and there is no absolute necessity for an update to disrupt the user workflow, it is better not to force a restart immediately after an update.

Description

Updates Display:

The present display of update manger is overloaded with information non-essential for an end-user , and opens minimized and is not centered. Since the Update manager window is minimized , the user only notices it in the end of all work . This leads to users not doing the updates,[since user has now finished with work]and postponing them for the next session. Also the Update manager display needs to be more minimal and user friendly.

A mockup of the update manager, with minimal & precise information --->

Note :

• The Check button is removed , since the Update manager auto opens , there is no needs for the check button.

  • When the user opens the Update manager from the Administration menu, apt-get update is done automatically by the update manager , if >12hrs has passed since the last apt-get update.

• The user has a master control over which updates[Security/Software] he chooses to install. By separating the security from the software , we ensure that users at minimum install security updates.[A solution for users on pay-per use connections]

• The update manager must always open in the center of the screen ,

  • If the user has other windows open, the Update Manager remains behind the most active window.[z-1] , this is to ensure that the user notices the Update Manager during his session , but after he closes his active window , so as to inform the user immediately and ,if user chooses ,performs the updates immediately.
  • If there is no window in the user desktop , Update Manager opens focused.
• The use of the present icon for a pleasant experience [-David Siegel]

Present Post-Update Dialogue:

The current Post-Update Dialogue borders on being a warning for an average user.

The present dialogue is misleading. Because:

1. The update installation does not Require or need a restart ,The update has been performed and is over , it is just , in order to use the new updated version , we have to restart the system. The words 'Require' and 'need' , imply that it is almost necessary to perform a restart for the system to work properly.

2. There is no warning of the user to save his work.Lack of the warning/confirmation to save work causes risk of the user loosing work over accidental clicks, Because the button to 'Restart Now' is placed on the right , which is the location where users commonly click "Close" [Inspite of the right side being the location of the affimative button ]. But we need the affirmative action to focus on the users work.[Session management can restore the apps but there is considerable risk of loss of work]

3. Improper wording of the dialogue, Lacks punctuation and unnecessary long sentences.

This restart ,which OS can control, is a major frustration for users and prevents them from updating immediately , since this restart is not entirely necessary in Ubuntu, we should refrain from using the word restart for system restart.

Post-Update Dialogue mockup:

Reword the dialogues, so that the word Restart is not used for any system restart dialogues.

Note:

• Deliberate switch of the buttons , So that the "Continue Working" option is located on the right, which is the location of all the 'Close' buttons.This is deliberate because the affirmative button here needs to be, to allow the user focus on his work. This allows the user to not worry too much about the update/restart and to continue working.

When the user selects the Use Latest version option , he is taken to the Confirmation dialogue:

If the user selects NO , he is taken back to the System updated dialogue. where he can dismiss the dialogue.

Timed Restart Reminder :

If the user has installed the updates but has postponed the restart. We should not intrude user with a restart prompt ,which only disrupts the work flow of the user. Rather we need to find optimal times to prompt the restart.

For security Updates:

• Prompt the user at 01:00pm / 6hrs after the installation of the security updates which ever is earlier.

• The 01:00pm prompt is worded: Its almost lunch time now, you might want to consider starting your system afresh , this allows you to use a fully secure system after lunch

• If the user has postponed the security update again , user is reminded again 6hrs later, and beyond 12hrs the reminder is repeated every 3hrs.
• Note the first reminder , at 6hrs, is orange colored. while the rest are red colored icons

Rationale for the prompt delays, as per the User scenario groups listed above:

• A. B. When the average user is using the system for only 2-3 hrs, it is better to install the updates and not disturb the user with a restart prompt during his limited use time. It is not ideal to disrupt their limited use time with restart prompts.

• C. E. [01:00pm>lunch, 6hrs >for users who have their systems constantly running]

• D. When the user suspends/hibernates without applying the updates , the user is prompted at the suspend/Hibernate dialogue : System is not using the latest updates , Please shutdown instead of suspend/hibernate to use a secure system on the next boot.

For Software Updates:

• The reminder is only at every 12 hrs.
• The icon remains the package icon at all reminders.
• Since there is no security risk the user's workflow is only intruded at longer intervals

  

Firefox Updates:

Firefox is one app in the default install which requires an app restart. Most often when the update is done while Firefox is running , the app misbehaves and either Firefox or one of its extensions dont work properly.

Since this is a known issue, it is better to identify whether Firefox is running and defer the update to when the app is closed.

• If the user choses "Continue working", the update manager waits for Firefox to close and immediately after Firefox is closed, silently installs the updates , without disturbing the user.

• If the user shuts-down immediately without closing Firefox. Firefox is updated on the next system startup.
• Similar protocol is maintained for other apps which fall in this category.

asac: waiting for users is not feasible for upgrades; so this solution is not suitable for this problem; we need a different solution that is supported by firefox codebase itself.

For Outdated security Updates:

Users who have postponed the installation of security updates , on the second day they are shown the same dialogue as above , and for any security updates pending for 3 days and above the number of Days elapsed since the security update was issued is shown and warning colors are used.

For software updates the user is reminded only every 7 days with the same dialogue.

Consequences for issues

1. The user does the restart at his leisure, or after his work is done.
2. Since the update is not started when the app is running, but rather done on the close of the app, there is no need for a restart of the app.
3. This does not intrude the user, but rather works around the users schedule.
4. When updates are non-intrusive , there are higher chances of users choosing to installing the updates earlier.
5. The word ,"Restart" is never used , so there is no panic/misunderstanding for new users.

Conclusion

An In-session update is always better than a shutdown/login update , as there is no wait time involved and the updates are done in the background. Also In-session updates in Ubuntu are fairly safe. We only need to make sure they dont intrude the user.

Since end-users never really care much for updates , if we takes pains to make updates highly non-intrusive,stable and easy to install, we can be assured that all users will perform updates regularly and reboot the system accordingly. --- mac_v