The Future 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

The whole “server facing the Internet” attack model is real, but it’s rather out of date. Especially if you’re a programmer, the software on your machine is likely to try to attack you.

In any case, the right solution for saving files from Thunderbird has been known for years: “portals” or whatever a particular sandbox system calls it. The sandboxed code in Thunderbird asks more privileged code to pop up a file chooser, and Thunderbird gets to save the chosen file. Zero friction and excellent security. Sadly, no one has gotten the whole ecosystem to play along. Android has supported this for years and app developers complain and refuse to use the correct API. iOS apps barely support files. I think Flatpak can do this, but almost no one does it.

Thanks for answering.

The threat model for a programmer is likely much more complicated than for a regular user, but not related to sandboxing.

Regarding the "server facing the internet is real", I am not sure I get your point. Could you elaborate?

The point you make about portals and how the support exists but neither Flatpack/IOS or Android ecosystems get it right is very revealing: when nobody gets it right then it likely means the design is broken. Even Fuscia failed and it was an OS built from scratch to focus on userspace isolation and contracts for IPC and syscall.

Anyway it is very unfair to the users when designs supplant existing ones breaking things that used to work. Again we are talking about very basic computer usage patterns that have existed for several decades.

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.

> I think Flatpak can do this, but almost no one does it.

Flatpak can do it poorly. What I see is opening a file for read once gives the sandboxed app write access to that path name forever.

> Regarding the "server facing the internet is real", I am not sure I get your point. Could you elaborate?

What I mean is: once upon a time, computers were often not really accessible to the Internet, and a server with an open port was the major attack vector. Sure, you could maybe get compromised by opening a malicious document that someone emailed you or gave you, but that was a slower-moving and more unusual attack vector. The code that you intentionally executed was largely things that you bought, possibly offline and possibly online, installed, and used for a long time.

Nowadays, everything has a web browser, but fortunately it has a decent internal sandbox. But people run "apps", and "apps" have broad permissions and, by design, execute code that comes from their supposed vendor. And people literally buy out vendors of popular apps to be able to deploy arguably malicious code to their user base. And some of these "apps" and plenty of developer applications, by design, run code or the equivalent of native code (thanks, Apple, for your lovely incoherent policies about code integrity) that come from third parties, and possibly from the fourth parties selected by those third parties, etc, and auto-update this code. Increasingly, people do things like running MCP, which is basically a tool to give a remote system remote control of your system. And, in my book, on client machines (e.g. the kind that are likely to use Flatpak or similar systems, all these things are more important attack vectors than servers facing the Internet.

Supply chain attacks have been an issue as long as you've relied on distributions. I can point to plenty examples in the wild, but you don't have wait for an incident to occur before creating a safer userspace.