It’s time to learn about Flatpak and why you need to use it. Flatpak is the way to go and is going to revolutionize Linux, whether you want to or not, especially since it’s the easiest way to get things that you want. I’m going to be going over what Flatpaks even are, how to use it, and how to control what your Flatpaks do.

What are Flatpaks?

Flatpaks are sandboxed apps using bubblewrap, designed to universally work across many Linux operating systems, but specifically on desktop. Flatpak acts as a front-end for bubblewrap, which has really complex command-line arguments, and as an easy way to install packages independent of the operating system you use (a Debian user and an Arch user install the same packages together in harmony).

Since apps are sandboxed, Flatpak downloads dependencies and libraries independently, so your programs work the everywhere. Gaming on Linux is one desktop activity that greatly suffers from this, whether you’re running SteamOS, Ubuntu, Arch, you and developers will experience the agony of inconsistent results, when they could be universal. Flatpak also simulates architecture, so you can still run all your 32 bit libraries, ARM programs, or x86 games and graphics using Flatpak.

Linux Can’t Sandbox

On desktop Linux, applications are given access to daemons or allowed to access all files on your system. Ideally, your operating system shouldn’t be allow this to happen, but this is a very real problem Flatpak wants to solve, especially as Apple and Google have figured out how to do this already (with Android, ChromeOS, and iOS, MacOS has sandboxing too, but it’s opt-in for developers, so tyranny of the default).

The technology Flatpak is built to provide an answer to both of these problems. Flatpak is also integrated in major Linux app stores like GNOME Software, Discover, and pamac. Flatpak also provides a container folder which separates your data from your raw home folder, keeping your system and all the data inside organized.

Wayland Only

To take full advantage of Flatpak, you need to be using the Wayland display server. While you can use Flatpak on X11, it can’t properly sandbox applications using X11 only because X11 does not provide any GUI isolation whatsoever and will work against your security. After all, in order to future-proof our stuff, we need to use Wayland to get that sweet fractional scaling and HDR support (coming soon™).

Why Not Snaps or AppImages?

Since Linux has no sandboxing at all, you NEED to be using something that provides sandboxing. Almost every Linux distro will not do this for you.

AppImages

AppImages, another universal format that while nifty, still won’t do for you, especially since you are just trusting random packages on the internet, rather than a centralized store. This also results in the same user behavior that happens on Windows (and MacOS to a good degree) and we shouldn’t go back to.

AppImages also pack duplicate versions of programs. If you install Electron apps like the private messenger Session and the note-taking app Standard Notes, you now have duplicate copies of Electron, which eats up more space.

There are people who argue Flatpaks also duplicate on multiple different versions of libraries, but this is greatly mitigated by compression, which AppImages don’t allow for. That way, you aren’t downloading the full package.

It has also come out the main dev of AppImages is a dunce who refuses to use Wayland and to update the FUSE module to work with modern systems.

Snaps

Canonical’s snap packages also seek to solve the same issues Flatpak does, but it’s mired with problems.

  • Many people don’t like Ubuntu pushing snaps or packaging Chromium/Firefox as a snap (even though Debian’s maintainers are way too taxed to properly maintain Chromium fast enough).
  • Many people don’t like the concept of snap’s backend being proprietary (in my opinion this is silly because even if it was open-source, there would be no way to verify if Canonical were actually using the open-source code or not).
  • Snaps auto-update and don’t allow users to disable it except through experimental settings.
  • Snaps’ sandboxing doesn’t apply to legacy apps (“classic snaps”) and requires AppArmor. The sandboxing is worthless if you use SELinux or systems without mandatory access controls.
  • Many people, including me, also hate that Canonical logs everything you install, which assigns a unique ID to on installation and for Canonical to do who knows what with. Anonymized statistics will always eventually be deanonymized, so it’s only a matter of time, even if it’s something like the flavor of Linux you use, the branches you enable, or the timezone you reside in. There’s no way to opt out either.

No doubt people will pick something to hate, but for me, inescapable telemetry and lack of SELinux is reason enough to give snaps a wide berth, unless you are locked into an application that absolutely needs it.

Flatpaks Are Better

Flatpak doesn’t collect any telemetry, lets you add/host your own repositories, also doesn’t require root, so it’s more secure for you to use and more convenient for desktop users who want to download their favorite applications. Flatpaks also provide a powerful permissions access system, which controls exactly what programs are allowed to access.

Flatpak may be imperfect, but some sandboxing is better than none at all.

The Cons

  • Many people cite flatkill.org, which at the time, presented valid points. Unfortunately, that site hasn’t been updated in years and some of what was said then is no longer true now. However, Flatpak is still irrevocably broken because of the fact it’s built more to be a container than an application sandbox. As a result, this makes it really easy to bypass, but the devs are working on a solution.
  • Flatpak’s poor security realistically could be fixed in the future through apps makers their sandboxes based on a standard (say, XDG portals) by coding their apps to distrust certain permissions by default. In fact, Whonix’s devs are working on a sandboxed app launcher and Chromium has stronger native sandboxing than Flatpak.
  • Flatpak relies on every application operating off of the same libraries. This can result in dependencies not updating while some programs play catch up. Flatpak’s developers appear to be aware of this and developed an internal tool for making sure their package manifests are up to date.
  • Wine and 32-bit dependent gaming needs a lot of work. While some programs like Heroic work flawlessly, I’ve seen problems with Lutris where some games will not install where they installed on the native package.
  • Flatpak strongarms people into Pipewire. While there are still some edgecase holdouts, we need to be moving towards more secure defaults rather clinging futilely to PulseAudio. In fact, when I was testing Pipewire when it first came out years ago, I had far less issues in its beta state than PulseAudio.
  • Some developers do not support Flatpak altogether. I had mentioned Session in the last video, but the Flatpak is not official. Many other programs fall into this category, so it’s vital you analyze the build manifest. As of the time of recording, the beta Flatpak site gives direct link to the manifest and with a teeny bit of know-how, it’s pretty easy to figure out what’s going on. Flatpak now has a pretty simple and robust verification system to mitigate this, but anything without a checkmark should be suspect.

Using Flatpaks

Forget about all this technical jargon! I’ve talked about why you need Flatpaks, some “drawbacks,” but let’s put this practice.

How to Setup & Use

First, add the Flathub remote. This gives you access to the main Flathub store.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Using flatpaks is also easy! Flatpak uses the same syntax as apt and dnf:

  • update to update the repositories
  • upgrade to run software upgrades
  • install to install
  • remove to uninstall
  • search to search applications in your Flatpak remotes
  • uninstall --unused to remove unused dependencies.

What/where should I download?

Now that we have access to Flathub, this pretty much is the whole kitchen sink to download anything we want. Of course, I do want to address a common thing I’ve read from other people online or seen in other content creators is people is something like this (first to last):

  1. Distro package
  2. Flatpak
  3. AppImage
  4. Third party repo (AUR, PPA, etc)
  5. Snap
  6. Tarball/provided by developer
  7. Compile from source

This has been the way most people have seen packaging on Linux for a long time, but instead, I want to encourage all of us to look at this differently:

  1. Flatpak
  2. Snap (if you use Ubuntu)
  3. Distro package
  4. Tarball/provided by developer
  5. Third party repo
  6. Snap (non-Ubuntu)
  7. AppImage
  8. Compile from source

Flatpak, especially for graphical applications, needs to be your top priority as to where you download a package. Flatpak is far more flexible than many of its distro counterparts and is much robust at providing a secure window to a program without much tradeoff.

The other reason the vast majority of sandbox systems on Linux are unsufficient compared to Flatpak. Only Snap comes close, but Snaps come close and are definitely more suited for command-line programs, but if you don’t use AppArmor, the protections that Snap provides are useless. The sandboxing of Snaps is also very flawed in that the experience is only really geared for Ubuntu as you need a completely separate patch from Canonical for AppArmor to achieve acceptable sandboxing.

The Time to Say No

The other issue people need to look at is the landscape of apps in Flatpak, but consider whether or not you should use them. Here’s some of what find valid reasons to use a Flatpak:

  • The application is old and never received an update to match upstream. For example, one of the packages I could never recommend to anyone in Flathub is a really old copy of Adobe Reader for 32-bit Ubuntu 12.04. While this application is an amazing achievement at demonstrating the fact Flatpak can run multiple architectures, I could never recommend running it because of Adobe abandoning the project and many unfixed security holes remain.
  • Unverified applications. On the topic of unofficial applications, Flathub implements a pretty simple and reliable verification system. Basically, this means you can trust any application with a blue verified checkmark. But what happens with apps that aren’t verified? In these scenarios, you should view the “build manifest,” so you can verify what’s happening. Chances are because of new vetting processes odds of these being malicious are highly unlikely, but be cautious and read the code. If you can’t read the code, how many other people submit issues and star the manifest on GitHub? Do your best here, but odds are you will be fine.

Manage Your Permissions With Flatseal

However, if you use Flatpak, I would strongly recommend double-checking your permissions using Flatseal. Flatpak is way too permissive by default, especially it allows most programs access to whatever they ask for on install silently.

There are plenty of easy ways to use graphical programs to tweak your Flatpak permissions like Flatseal. Flatseal is a program that generates “override” files that change what programs are allowed to do on your system, stored in ~/.local/share/flatpak/overrides. If you use KDE, KDE has a built-in frontend identitical to Flatseal.

These permissions might be confusing and overwhelming, but I’m going to try my best simplify how they work:

  • Network: Does GNOME Calculator or LibreOffice really need the internet, especially when Flatpak manages their updates? Audacity and Musescore adding telemetry? Let’s kill the internet for the apps that don’t need it. Most applications typically only enable it because they need it for their internal updating.
  • Interprocess Communications (IPC): Allows program to read other processes and resources on your host machine. “Is not necessarily required” unless you use X11, but you shouldn’t be using X11.
  • socket=pulseaudio: PulseAudio is a common vector for attack on desktops, since it grants access to your microphones if it’s being used by another application. Applications that don’t need to play audio (e.g. LibreOffice and ONLYOFFICE for example), should have this revoked.
  • filesystem=: make sure you want your program to choose what folders it can access. Look out for global accesses and selectively pick folders to add using “Other files” in Flatseal.
  • device=all: Don’t want an app accessing PCI and USB devices, like your webcam? Limit this, but it is needed if you use security keys, webcams, microphones, etc.
  • Fallback to X11: As X11 is a legacy technology, we should avoid it like the plague. Older applications like Chromium/Electron-based applications, Krita, and Minetest still need it, but applications like OBS, LibreOffice, KeePassXC don’t because they support Wayland natively; just experiment with what works.
  • talk-name=org.freedesktop.secrets: D‑Bus access to secrets stored on your keychain, like say, your GNOME Keyring or KDE Wallet data. This is needed for Chromium/Electron-based apps.

Takeaway

But what’s the point of this discussion? Why are you even covering this? Because you need to use Flatpak because secure solutions need to be easy otherwise people aren’t going to use them. Flatpak truly makes it easy and brings the Linux desktop one step forward to being that much greater.

I’m going to go out on a limb here and strongly recommend you install as many of your applications as Flatpaks. In fact, go uninstall your applications that have Flatpak versions, move your config folders to the Flatpak sandbox, and embrace the future as we wait for the next best thing.

More Resources: