Re-visiting update control on the desktop

snapd
1

With the Ubuntu 20.04 release out of the way, a significant chunk of users are doing clean installs or updates from older releases of the worlds most popular open source desktop operating system :smiley:

A number of conversations have arisen online since (and indeed before then) around the policy of snapd doing automatic updates of applications. Some of these result in user frustration that thereā€™s no simple way to control frequency of updates.

Currently we have the capability to push updates back a number of days, or defer updates to particular times via the methods documented. In addition we can suppress updates for up to 60 days when on a metered connection - if such a connection is correctly identified. We also have the upcoming experimental feature to hold updates for applications while theyā€™re open.

One problem for desktop users is that all these settings are command line driven. Thereā€™s no graphical way to adjust the time when updates happen, putting them on hold, or any of the experimental features. Back in 2018/19 during the metered connection discussion it was suggested we should re-visit this topic.

Letā€™s revisit that. While I appreciate that desktop stuff isnā€™t really the domain of the snapd developers per-se, I think the conversation should happen here (as opposed to the Ubuntu discourse) as itā€™s something cross-desktop and cross-distro which should probably happen with involvement from snapd developers.

As a straw-man, I suggest the following:

ā€œAn easy to use, graphical user interface to control snap refresh parameters should existā€

A the minimum it should allow users to see:

  • When the next update is likely to occur (to be informed) - [Due in 2 hours]
  • If snapd believes the user is on a metered connection [-] - Metered connection

And allow them to control:

  • Triggering an immediate refresh [Update Now]
  • When the next update will happen [Tomorrow] / [Next week] / [DD-MM-YYYY]
  • Whether the network is actually metered [X] - Metered connection
  • Put one application update on hold [X] - Hold Libreoffice.
    • Use case for this is where you are happy to get security updates for most applications, but this one youā€™re giving a presentation from needs to stay stable for the next week of training.

Bonus requested feature by people who like complete control.

  • Ability to completely switch off automatic refresh. [X] - Do not refresh at all

I suspect this needs input from @mpt (design), @kenvandine (desktop), @mvo (snapd) at least.

Should this exist? Who would work on it? Should it be part of GNOME System Settings? What about XFCE / LxQt / KDE users?

18 Likes
2

While I donā€™t like the idea of having updates turned off, I think the (loud) message weā€™re receiving from outside our community is that the ability is a big issue for people to even consider using snaps. Therefore, even though we donā€™t like it, I believe that it is in the platformā€™s best interests to provide the knobs to let the user decide. This will improve the perception of the project and itā€™s direction along with getting more people to consider giving it a try.

17 Likes
3

To avoid a scenario where a user disabled updates and forgot about it, I think when people put any or all app updates on hold, the UI should show this as an ā€œinsecureā€ state. Ideally the update manager should remind the users about this insecure state every time it runs.

5 Likes
4

I kinda threw the ā€œturn off all updatesā€ in there knowing thereā€™d be pushback. Thereā€™s a ton of other things in my strawman argument we could also look at :smiley:

I too worry that if we make it easy to disable fully the update process itā€™ll get left switched to that state. Some, yes, will want that.

1 Like
5

I personally think there should not be an option to turn off all updates, but I do think the current ā€œtoolsā€ a user has to control updates are not well adapted to desktop users. The current tools seem mostly fitted to server and iot use-cases where updates are managed/configured by an admin.

The concerns a desktop user has are things like ā€œI donā€™t want updates right before a big presentationā€. This is not solved by setting update intervals or an update time. The ability to revert updates also doesnā€™t solve it; even if this capability was usable from the GUI and easily discoverable, you will still lose your trust in Ubuntu if youā€™re in front of an audience and have to fiddle around with package reverts because your presentation/demo isnā€™t working.

The current desktop update-manager is well suited for this because every time before the system does major updates, it asks user confirmation. At that time, the user can make a quick decision of ā€œis this the right time?ā€. Could we have the same thing with snap updates? The current apt approach isnā€™t perfect, of course, because it allows users to delay updates indefinitely by just ignoring them. But the idea of asking users if now is the right time for updates is a good UX pattern for desktop users, imo. You give users the ability to say ā€œthis is not the right timeā€ but if they ignore the question, or if they delay it for too long, auto-updates should still happen.

So to continue the discussion; what do you think about this proposal:

  • Every time snapd wants to update snaps on a desktop distro, it notifies the user.
  • This notification has a button ā€œdelay updates for 24 hoursā€
  • If the user ignores the notification, the updates will happen.
  • If the user keeps delaying the updates for more than a week, the notification informs the user that this is the last extension, after which the updates will still happen.

This proposal is of course without any regard of what is easy to implement/feasible.

4 Likes
6

Leave auto-updates a very strong default and have the user specifically disable auto-updates on a per-snap basis if they so desire. The average user will keep it enabled anyway, I believe. However, edge-cases where a manual update process is required are covered by this.

For example an admin needing to greenlight a critical application first before it gets used on workstations or a crucial piece of infrastructure that may not have any unpredictable downtime. Easy pinning of specific versions would also be a use-case.

For the average case, @galgaleshā€™s proposals + the work on refresh app awareness ([WIP] Refresh App Awareness) will solve nearly all perceived problems on the desktop and thus I believe such a setting could be implemented without it becoming the go-to hack for frustrated users.

2 Likes
7

Previous discussion: ā€œā€¦a ā€˜Detailsā€¦ā€™ button, which would open a secondary dialog for controlling the schedule as well as listing recent updates ā€¦ A simple first step ā€” useful and releasable by itself ā€” would be to add a caption below the new label, of the form ā€˜Last check: Yesterday 16:27ā€™. If someone submits a merge proposal to do that, then Iā€™ll design the next bit.ā€

Agreed.

Previous discussion.

Yes ā€” I reported that issue in 2012. It predates snaps because it isnā€™t specific to snaps.

However, following the principle that things more closely related should be closer together, that is #3 on the list:

  1. All snap update settings should be together. (For example, it would be awful for some to be in GNOME Settings and some outside, simply because some happen to be in common with another packaging system while others are snap-specific.)

  2. Snap update settings should be together with .deb update settings. (Though they behave in different ways, these differences are most easily explained to users with them next to each other.)

  3. Update settings in general should be together with other system settings. (The structure of the GNOME Settings UI is quite awkward at the moment ā€” because itā€™s optimised for phones rather than desktops ā€” but even so, Software & Updates settings would still be easier to find inside it rather than outside it.) This would also reduce the problem of Software Updater and Software & Updates being hard to distinguish in the shell, and fix various other bugs (as well as, Iā€™m sure, introducing new bugs).

Ideally, all three of these can be satisfied at once. But if they canā€™t be, they are in order of importance.

Thatā€™s a case where you might sacrifice #3 to achieve the other two. That is, you might put snap update settings in software-properties so that people using other environments can access them in the same place they currently access .deb update settings.

1 Like
8

No need to make 2nd Windows. The update should insist on its update but not force it to install. Imagine a person who rejected blender updates for a long time since he was rendering a heavy movie. And then the moment came when he simply could not cancel the update. it will break him many hours and maybe many days of work.

1 Like
9

That seems like exactly the kind of issue that would be fixed by the App Awareness already mentioned.

But the ā€œ2nd Windowsā€ slur raises a general question, which is why people complaining about automatic updates compare them to automatic updates in Windows, and not to automatic updates in Firefox, Chrome, or Chrome OS.

It might be partly that people using snap systems have more experience of Windows than of those other three.

It might be partly that the kind of people using snap systems are more likely to think that something is wrong because Windows does it, regardless of whether other systems do it.

And it might be partly that browsers change less visibly, less often, and less incompatibly, than other apps do.

But those other systems might also have subtleties that are worth copying in the way that they schedule, reschedule, download, and install their automatic updates.

5 Likes
10

Note; Iā€™m a community member, not a snap/snapcraft developer.

A few notes about the scenario you talk about

  • Snap updates do not change running applications. If blender runs while the snap update happens, blender will continue running. Once you close and restart blender, only then will you use the new version.
  • In one of the next releases of snapd, it will default to not updating an app while itā€™s running. This is not required for the scenario you talk about, but it will further improve the user experience of updates.

A significant part of the security issues on Windows are due to users not installing updates. Most Windows viruses use exploits which are already patched. Itā€™s also important to not become Windows in the sense that there are millions of insecure devices out there. This is not only an issue for the users of the devices, but also for every other user connected to the internet. Itā€™s easy for attackers to weaponize insecure devices and use them to attack secure devices using DDoS etc.

Although I agree the current update policy is not ideal, I would like to see a better solution to these problems than simply ā€œdisable automatic updatesā€. Itā€™s important to have people like you in this discussion so the developers can see what other solutions you can live with apart from ā€œdisable automatic updatesā€.

1 Like
11

This is true, but if clicked, it will not work quietly. I explain why. During the upgrade, the interfaces will be reconnected. For example, a telegram loses its old icon in the ubuntu-doc panel, and if I want to show a minimized telegram window, it is duplicated and I get 2 simultaneous applications. due to reconnecting interfaces, it may happen that some functionality of the application will stop working.

1 Like
12

Note that this has some undesirable side effects:

  • if you click the Blender dash icon in this state, itā€™ll launch the new version while the old one is still running
  • if the application does any session management, the new version will see the saved state as it was at the moment the snap refresh happened, and not at the moment when the user closed the old version of the app

Point 2 is especially noticeable with Chromium: if you donā€™t restart as soon as snap refresh happens, your browsing history and open tabs will not reflect any browsing youā€™ve done since the refresh. This was especially painful on 19.10, itā€™s much better on 20.04 now that you get the notification about the snap refresh of a running application.

2 Likes
13

Thanks for the explanation! These issues should be fixed by refresh awareness and update inhibition.

For more info and future plans, see [WIP] Refresh App Awareness

Having this option set you can try to manually refresh a snap to another channel or to simply refresh to a new revision arriving on edge. For as long as the snap is busy it the refresh will be inhibited. A snap is busy if it has running non-service applications or hooks.

14

That doesnā€™t solve the problem, only postpone it for up to 7 days:

The refresh timeout is not indefinite, though. After a certain period (current default is 7 days), the update will be triggered.

I donā€™t know about you, but I always have a browser open (and since I work with a laptop that has working suspend, I reboot only when Ubuntu tells me I have to, after a kernel security update and such). I had that experimental snapd option enabled in 19.10 and was still bitten by a lost browsing session once a week because the snap would refresh, and I wouldnā€™t notice.

The notification in 20.04 solves this problem in a much better way. (I thought it was a snapd feature, but apparently itā€™s a hack implemented in the chromium snap specifically.)

15

Yes, creating the notification from snapd is part of the future work of Refresh App Awareness. I included the WIP/roadmap doc in my previous post.

4 Likes
16

I m really happy the Ubuntu team is re-considering snap update controls. This is the reason I have moved from Ubuntu MATE to Fedora MATE over a year ago.

It would be great if snap updates were integrated in the Software Upgrades program. My favorite option is to automatically check for upgrades but prompt the user for authorization before installing them. No need for thinking about a userā€™s routine to define snap upgrade schedules, metered connection or anything else. Just train them to approve when thereā€™s time and disaprove when it is inconvenient to upgrade. Simple and efficient.

2 Likes
17

You may have more up-to-date information than I do, but last I knew this was not the case. When a snap updates out from under a running application, it actually updates the confinement profile of the running application. This is why the signal-desktop app eventually crashes with cryptic ā€œunable to write to something somethingā€ type errors after a while: it wants to write to $HOME/snap/signal-desktop/300, but its confinement profile got rewritten to only allow access to $HOME/snap/signal-desktop/321 (revision numbers are made up for the sake of this example).

Inhibiting the refresh of running applications improves things, but I think itā€™s not a solution to the OP.

1 Like
18

We donā€™t have anything like this supported ATM. We have discussed and do plan to implement supporting holding refreshes for single snaps for a period of time (up to some amount), like we do already for the entire auto-refreshes (via refresh.hold config option for that case). Thereā€™s no defined ETA on this for now though.

19

[Iā€™m just a user.]

Iā€™d say: give all the options. Option to turn off (forever) auto-updates on individual snaps, and to turn off (forever) auto-updates for all snaps including future-installed ones. Give stern warnings, but ultimately the user / system owner decides.

More than just an ā€œinsecureā€ or ā€œnot updatedā€ warning tag for each app that has not been updated, you could give a way to click through that tag to see changelists (from the app dev) for all updates that have not been applied. That way the user easily could check to see if any security / CVE stuff is in the changelists. The app dev also could put non-security notices in there (e.g. ā€œfixed a crash which could make the whole database unreadableā€).

1 Like
20

This are the 3 options that I think it should be included:

  1. Auto-update snaps (or maybe download the app and notify the user to update, but this would only work better for small snaps);

  2. Postpone updates, but not disable;

  3. Put updates on hold on metered connections (just show a notification of new update) so the user can update manually