Recent versions of Ubuntu turned on a particularly annoying feature: intrusive system notifications that warn of the pending update of a Snap managed application. Here’s an example:

Aside from this notification apparently not being tied properly into the KDE notification system (it doesn’t show in the list of recent notifications that’s available from the system tray notifications widget, and so therefore seems to be using a different notification system), this highlights a particularly annoying (and anti-user) line of thinking by the Snap development team.

A little background, before going into detail on the issue here (skip down to the next image if you’re up to speed on Linux packaging). As is standard operating procedure in the Linux ecosystem, competing systems are vying to become a standard to solve a particular problem, and as usual we’ll end up with segmented user bases, inefficient use of sparse developer resources, and multiple ways to achieve the same thing. Human nature, ftw. The problem that’s being addressed in this case is that of software distribution.

The status quo for obtaining software for Linux distributions until fairly recently was the idea of repositories, i.e. managed collections of software, and tooling baked into the distributions to allow installing and updating software from these repositories. (Linux repositories preceded the popularity of “app stores”, but it’s basically the same idea.) Part of the differentiation between competing Linux distributions is how (and how often) they curate their repositories. While some distributions opt to be “bleeding edge”, and allow highly streamlined updates from developers to make it through to end users with a minimal amount of testing, many other (and most mainstream) distributions opt for periodical release cycles, whereby critical security updates (and some important bugfixes) can be made and pushed out quickly, but generally most other significant updates will be held until the next big release of the distribution.

This was both good and bad for users. If your system was in a fairly stable state, you could expect that applying updates when prompted to do so would leave your system in at least as stable a state as it was prior to the update, at least until the next distribution wide release (and then, your mileage might vary depending on hardware, drivers, amount of upstream testing, your own customizations, etc). “Long term support” releases were introduced, and if you opted into these, you’d be protected from distribution releases for years at a time, giving you stability at the expense of recency. Unfortunately, this meant if that if you needed an important feature update from an application, you’d either have to “sideload” it, or you’d need to wait for the distribution to include that update in the next release.

Furthermore, for developers fed up of the splintering of the distribution ecosystem (and the multiple repositories and packaging formats that they needed to target in order to allow a reasonable percentage of the Linux desktop install base to access their application), the process of packaging your software became increasingly onerous. Since the Linux ecosystem as a whole benefits from having more users, and user adoption is often blocked by the lack of availability of software that users depend on, the need to make publishing software on Linux more streamlined was and is real. And thus we get to the competing systems.

Three alternatives arose: AppImage, FlatPak, and Snap, the latter two of which now seem to have the majority of traction. All three systems have their own sets of deficiencies. The basic idea is that distributions (or third parties to distributions) set up publishing channels for software applications separate from the distribution repositories; applications get packaged with most of their depencencies in a file that can be atomically downloaded and installed, without affecting the versions of other libraries on the system; software developers are then free to push out updates quickly, because they don’t have the ability to affect other applications with their updates. These channels are most typically for applications rather than libraries; library (and OS) updates become the province of distribution packagers, and application packagers can sit on top in this additional channel. In the platonic ideal of this architecture, applications installed in this way are sandboxed, and convenient OS level controls allow users to expose the applications to only the system resources that they need access to, maintaining security and reducing the risk of a system compromise by a backdoor introduced through this loosier-goosier update system. In reality, the sandboxing system is undermined in all three alternatives in the name of usability (c.f. Windows Vista), but perhaps we’ll get there in future.

FlatPak and AppImage have their own set of problems; maybe I’ll blog about them in future, but the rest of this article is about a big problem with Snap.

Snap as a system gets a lot of flak for its proprietary “app store”, which is managed in a fairly non-transparent way by Canonical, the company behind Ubuntu. I actually don’t mind Canonical’s role in this particular setup; having a robust and trustworthy gatekeeper to the app store is IMO a good thing, at least until application sandboxing is generally applied and in wide use.

The bigger problem with Snap is highlighted by this new notification. Let’s look at that screenshot again:

Let’s start with a critique of the UX. The notification is telling you that a “firefox” (with quotes!) “snap” is pending updates, and tells you to close the app to avoid “disruptions”. Imagine a non technical user seeing this.

First, the name of the application is lowercased, and in the case of applications with multi-word names has dashes instead of spaces between those words (e.g. “intellij-idea-ultimate” - granted not a great example of an application that non technical users might see). Why on earth didn’t they use the full application name as stored in the Desktop file (which is used in system menus to launch applications with a human readable name)?

Second, this assumes that a user knows what a “firefox snap” is. Do regular system updates tell you that a “firefox dpkg” needs to be upgraded? Do end users need to know what Snap is, if the system is working as it should? This message was written by a (likely quite young) developer who is oblivious to how end users think. That this got past the product managers at Canonical is worrying. (Are there product managers at Canonical?)

Third, the notification has one call to action: shut down the application. This application will be updated, so shut it down. If the user closes the application, presumably that then triggers it to be updated, right? But no: the snap updater runs on a schedule, and it could take 6 hours for it to run again, check whether the application is running, and then apply the update if it’s not. Is the user supposed to leave the application shut down for up to 6 hours? How could they possibly know to do that? You could see a user getting into a cycle (for 13 days!) where they restart the application, and then 6 hours later the intrusive (and apparently not suppressible) notification pops up again.

Fourth, this notification cannot be moved / dragged by the window manager controls, at least on KDE. Covering the system tray? Out of luck, it can’t be moved. In a full screen window? Out of luck, this sits on top of it. The only thing you can do with this notification is close it.

Fifth, “disruptions”. What kind of disruptions? It’s an extremely bland and non specific notification message. Really, the developers are trying to warn about data loss in applications if a document is unsaved when the update is applied. But, you might ask, why would there be data loss from an update? Updates on Linux don’t risk data loss. That’s not a thing. Right? Well, now we get to the crux of the crushingly bad situation here.

After 13 days have expired with the application running for the duration (I guess it’s really a two week cycle, and the first time you see this is 14 days minus a few hours, hence “13 days”), guess what happens? Snap’s update system kills the running application and applies updates, without user consent. What happened prior to this notification being introduced was that sometimes some users who left their computer turned on and applications running for long periods of time would log on to their computer one morning and discover that those applications “crashed” overnight, and that the document they were working on and forgot to save before going to bed lost all of their recent updates, and they blamed the application’s developers for this. This happened because an update was pushed out to the Snap update channel, and two weeks later any running instances of the software were killed and updated by the Snap system, because it was tired of waiting for a system restart. These updates happened without user consent. The software developers bitched at Canonical about being bitched at by their end users, and this junior engineer designed update notification was added.

You may be ahead of me here at this point, but let me spell out the awfulness that’s going on here.

Traditionally, updates on Linux systems are controlled by the user. You get an icon in the system tray that looks important; you click on it; it asks you if you want to install updates; you say “yes” or “no”; updates are applied, or not; when you next restart any applications that you have running that were updated, the new version is picked up. Data isn’t lost, because updates don’t restart the application. You can (and do) update the Linux kernel in this way, and your computer just stays up (usually running on the old version of the kernel until you next restart.) Mechanisms have been added over time to allow auto updates to take place for critical security patches (“unattended upgrades”) but these have typically to be opt in. And again, they don’t restart running applications.

Snap breaks this contract. The update channel for Snap is independent from the KDE updater (on Kubuntu), and seemingly the Gnome updater (on Ubuntu). If you consent to applying updates from the general system tray “updates needed” notification, Snap updates are not included; they’re not even listed in the pending notifications from the system tray. Snap updates only happen when the Snap updater is running, either if the application is not running or after the period of time required to force updates has expired. Snap updates happen without consent.

Snap updates happen without consent. Across the board. You can (in upcoming versions of Snap) put updates on pause using snap refresh --hold, but it’s not clear to me whether that’ll notify you that updates are available and held. It seems to be another patch on a fundamentally bad design decision.

The notification is not the real problem here, although it is bad. The fix to applications “crashing” and losing data because of Snap updates that take place without consent is not to pop up a terribly designed nagging notification with no clear call to action, but it’s to tie Snap updates in with the rest of the system update ecosystem. Snap updates should require consent. Snap updates should show up in the same system tray updater as the rest of pending updates, and should be able to be chosen or held by the same interface. (What end user wants two update systems?) Snap updates should not restart running applications. These are bad design decisions, and they should be revisited.

Canonical started out (https://bugs.launchpad.net/ubuntu/+bug/1) trying to be an alternative to Microsoft. Forcing updates and restarting applications is a poor design, an awful compromise, and a good deal of the way towards the obliviousness to end user choice that drove many Linux users away from Windows in the first place.