The Future of Flatpak

In case anyone ever seriously contemplates a new design, here's an anecdote:

Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.

I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.

However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.

(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)

Rant ahead.

I really dislike these towers of complexity in the name of security. A PC is a general purpose device and it is mine. I don't need to have permissions per each instance, i don't want sandboxes that cannot share files with other applications and I don't want the concept of everything is a file to go away in my PC. My PC is not a single window device, nor do I run a server facing the internet. Please model the threats and adjust security with usability accordingly.

I have a reason for this: Thunderbird and firefox on Ubuntu now do not have access to the /tmp directory and instead have their own directories in some unconventional place. When i want to do something as simple as save an attachment in thunderbird and open it in another program I cannot have done to /tmp and need to put it in some permanent storage. But it gets worse due to the sandboxing. Now thunderbird cannot also show me viewer applications because it is sandboxed and does have the means to suggest other installed applications.

The computer stops being mine so it becomes the playground of architecture astronauts that think usability of said programs are always less important than security. To those people I would like them to tinker on the most secure devices in the planet [1] so they would not intrude on people trying to get things done.

[1] https://en.wikipedia.org/wiki/Useless_machine

That is the problem, though. It was never yours. It belonged to app developers, some of them potentially nefarious. When you have thousands of packages supporting your desktop environment, the only sane security model is to treat everything like a threat, and make permissions opt-in, not opt-out. X for example just lets every program spy on your keyboard input, sample memory /framebuffers, etc.

In the end, when it comes to security, the average user doesn't know best and should let the people who do design the systems. This is why we have seatbelt and child endangerment laws.

> That is the problem, though. It was never yours. It belonged to app developers, some of them potentially nefarious.

But it has been mine for decades and nefarious developers somehow weren't a real issue in my distro's repositories for this whole time. It's a self-inflicted problem.