There seems to be a lot of discussion of whether Flatpak is terrible or is great, whether it’s the future or whether it’s complete trash.

I think Flatpak does a lot of very useful things, and requires more work in other aspects. I’m not sure what the The One True Package Manager™ will be, but I’m sure we can all learn some lessons from flatpak.

Isolation

[permalink]

Flatpak itself does a pretty good job of isolating applications. A package can be set up to have no access to the filesystem and several other resources, and it won’t have access to them. It builds on a lot of existing system APIs, rather than try to reinvent the wheel in this aspect.

I really like this aspect of Flatpak, to be honest, and I hope stronger isolation continues to be the trend.

So, if permissions are set up correctly and the package misbehaves (be it malice or a bug), you don’t have to worry about it sending your photos to strangers, stealing your SSH keys, or installing a keylogger on your terminal.

And that’s a big if…

Permissions cannot be rejected

[permalink]

The permissions model in Flatpak is broken, in that packagers declare what permissions they want, and users must accept all of them to install the package.

During package installation, there’s no option to “say no” to a permission. If a package wants to read-write all files on your home directory and use your webcam and USB ports, then you MUST grant it permissions to continue installation, even if you know they won’t be needed for your use case.

This is a big pain point right now. A lot of package on Flathub require too broad permissions since they try to cover all possible use cases out-of-the-box. So it’s very common for packages to have enough permissions to steal your SSH keys, or install a keylogger without any hassle. This defeats the purpose of even using the isolation in the first place.

Of course, the alternative would be to break some edge-cases for some users, and that’s not a nice thing to do either. There’s no correct answer here (convenience vs security), and, ultimately, it should be left up to the user to decide. This is one of the few things that iOS actually gets right: when installing an application, it has no permissions by default, and the OS later prompts for things like access to photos, camera access, etc. The user is free to accept or refuse.

With Flatpak, users can manually opt out of permissions, by either using the command line, or a third party app called Flatseal (BTW: it’s a must-have if you want to use Flatpak). Both of these solutions require installing the application (granting all permissions), and then manually opting out.

Opt-out is never the right approach in terms of permissions or consent.

Poor default permissions

[permalink]

Flatpak and Flathub are slightly distinct things. Flatpak is the package manager and runtime that fetches and runs packages. Flathub is a public package repository with community maintained packages.

Because users can’t answer yes/no to individual package permissions, maintainers are always left in the awkward situation: do they make sure it “works for everyone in all edge cases”, or do they focus on security and isolation? Results vary on a per-package basis.

Ultimately though, this issue is more of a symptom of the previous one than an issue in itself.

Explanation on permissions

[permalink]

Currently, FLatpaks merely declare the permissions they require, but there’s no explanation as to why. The package definition format has no mechanism to explain this, and it often leaves users wondering “Why does this app need unrestricted access to my entire filesystem?”. There’s plenty of issues of people asking “Why does X need Y permissions?”.

So maybe it make sense to switch permissions from a list:

[
    "--socket=x11",
    "--socket=wayland",
    "--socket=pulseaudio",
    "--share=network",
    "--device=all",
    "--filesystem=xdg-download",
    "--talk-name=org.freedesktop.Notifications",
],

To an actual map of explanations:

{
    "--socket=x11": "To render windows on X11 desktops.",
    "--socket=wayland": "To render windows on Wayland desktops.",
    "--socket=pulseaudio": "For microphone and headphone access for videocalls",
    "--share=network": "To communicate with the server and send/receive messages",
    "--device=all": "For webcam access for videocalls",
    "--filesystem=xdg-download": "To save received files",
    "--talk-name=org.freedesktop.Notifications": "To show notifications",
},

The format might be terrible, but the general idea is clear: give users a clean explanation on why you’re asking for permission, and enough context to understand if they need it. Because, if they don’t need it, then users should always opt to click the now-non-existent “Refuse” button.