2017 could be the year of the sandboxed app

One of the things that makes Linux awesome is that finding and installing common software is really fast and easy. If you use a graphical tool like GNOME’s Software, you can download and install an app in a couple clicks. If you’re a command-line commando, you can install an application with one or two relatively short console commands.

It’s all thanks to the package manager. And while the trusty package manager has served as a centerpiece of Linux distributions for years, it has some serious shortfalls as well.

The problems with package managers

Package managers make life easy for the desktop Linux user, until they don’t. Sometimes things go awry. Library conflicts can break compatibility with other packages. Nothing can dissuade a Linux newbie like a system-upgrade attempt that fills the console screen with errors. Even for an advanced user, this can be disheartening.

On top of that, there isn’t just one package manager. Package managers differ from one distribution to another, meaning that instructions for Fedora won’t completely translate into instructions for Ubuntu. Switching between distributions means learning a new package manager. It also means that what works for one system may not work the same on another.

Not only can it be tough for newbies to get it all right, but it’s also a pain for software vendors to distribute their programs. Just think of it: To distribute your program, you might have to repackage it as an RPM (Fedora), Deb (Ubuntu and Debian), or a tar.xz (Arch and Manjaro), in addition to providing the source as a tarball (tar.gz).

Many software vendors simply pick one and leave it to package maintainers to do the rest. This creates an entire class of volunteers who spend a lot of energy repackaging software for their chosen Linux distribution. That’s a lot of extra work and testing. It’s little wonder that proprietary apps that are widely available on Windows and Mac aren’t always available on Linux. 

Simplifying distribution

Some smart folks realized that packaging software for Linux was a nightmare. To remedy this, there are a few new formats that have been worked on over the past year to simplify this.

Portable Linux applications aren’t exactly new. Container systems like Docker are popular among enterprise app developers and server administrators, but they aren’t really designed for the desktop user like you and me. The portable desktop systems package applications with all of the stuff the apps need to run (libraries, runtimes, etc). The portable app is then offered as a single-file download, that can be run without a lengthy unpacking and installation process.

This distribution method also promises added security, since each application can be run in relative isolation from the rest of the system. That means that a misbehaving email or malicious web script would have a harder time touching any of the data on the system outside of the app’s environment, or sandbox. In some cases, the application must be granted certain permissions to function properly. If you’ve ever had an Android app prompt you for permissions to your phone’s camera or storage, the idea is very similar.

The contenders

As with anything Linux, there’s never just one solution. Several people have come up with and worked on similar solutions, which means there are now another set of competing formats. There are three formats that are trying to address this problem: AppImage, Flatpak, and Snap.

AppImage is one of the earliest solutions, and first began development back in 2004 as a project named klik. AppImage allows users to download a single file, set it as executable, and run it without any installation. A library of AppImage apps does exist at JFrog Bintray, but some of the applications are a little old. The Chromium application, for instance, is a build from August 2016.

Canonical was early to the portable application game in 2016 when it introduced snaps with Ubuntu 16.04. Snaps are billed as being more secure and easier to install. To use snaps, you have to install the snapd daemon on your system. (Ubuntu users running 16.04 or newer already have snapd as part of their base install.) Snapd is available on most major distros, so you don’t have to be an Ubuntu or Mint user to make use of them. There’s also a good selection of snaps at the Ubuntu App Explorer website. It’s worth noting that Canonical is mixing server and desktop applications in its snappy ecosystem, which creates a little overlap with solutions like Docker.

Finally, there’s flatpak. Flatpak is a format developed by Red Hat that’s intended for desktop applications, and isn’t really intended for servers. Flatpak was “released” at the same time Fedora 25 hit the web in late November of 2016, and hasn’t had the time to accumulate a library of apps like Canonical’s snaps have. There are few applications available as flatpaks, but the collection is growing.

Works in progress

Making Linux applications portable is a bit of a new process, so not everything works perfectly just yet.

Canonical’s snaps lack support for SELinux on Fedora. In addition, both flatpaks and snaps rely on the additional security provided by the Wayland and Mir display servers. (A display server is what creates the canvas that your desktop is drawn on.) Unfortunately, most Linux systems still rely on the aging X11 (or X.org) server. While Fedora 25 shipped with Wayland as the system default server in November, the April release of Ubuntu 16.04 still used X11 (though you can install a Unity 8/Mir preview if you like).

AppImages don’t have any sandboxing or security built in at all. Instead, the user has to manually sandbox AppImages using the firejail application.

Another thing that needs a bit of tweaking is the user interface for these formats. AppImage files must manually be set as executable. It’s not hard to do, but can be an easy sticking point if the user doesn’t know they have to set the bit, or if they simply forget.

Flatpak versions of applications are available in GNOME Software if you’re running Fedora 25 or have flatpak installed. However, the only hint that an application is a flatpak in GNOME Software is a little blue icon showing that the app is sandboxed. 

Conclusion

All three of the solutions attack the task of unifying Linux application distribution in their own ways. All three have advantages and shortfalls. While it will be interesting to see this year which of the three ultimately wins the hearts and minds of users, I’ll be looking forward to the more user-friendly desktop Linux ecosystem that these projects promise to create.