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

You may be right. And it’s even possible that the flatpak developers believed you were right.

And it mah still not have been the right decision because when it comes to products like Flatpak there are a lot of considerations beyond just what the best technically correct choice is.

For example, based only on your comment, basically every other OS does it the same way Flatpak does it. So if the Flatpak developers had done it the technically correct way like you suggested, it may have been enough of a burden for app developers, especially multiplatform app decelopers, that they wouldn’t have used Flatpak in the first place.

You are right, but actually I think you would want to go beyond that and build a hybrid of your approach and their approach:

For your documents, you will usually want your approach. Maybe with some optinal allowance for useful things like a "recently used documents" menu or something.

But for more enviromental things, I would want at least the option of allowing all instances the same access without a lot of permission prompts later on. E.g. my git config, my fonts folder, my code snippets library, stuff like that.

Yes, that would be better, for specific instances of the running program to have a set of permissions instead. However, I think this is not the only issue.

It is what I had wanted too, not only you.

I think that the entire operating system should need to be redesigned for many reasons (I mentioned before how to design a better one), and it would have that effect, that specific instances of a running program would be given capabilities as arguments (or through other capabilities, but the first ones must be given as arguments), and these capabilities can have restricted permissions, as well as more versatile things e.g. to log access, or to go through a proxy, or to set a disk quota, etc.

I do think this would be good for power users who want strict isolation between different instances of apps (and I'd also love to see better QubesOS type approaches, using a hypervisor), but perhaps most of this kind of work should be prioritized inside the application itself, using nested sandboxing. That way, the barriers are exactly where the user expects them to be based on the normal behavior of the application. Assuming vulnerabilities in the code that glues it all together don't get explosive, of course.

Web browsers do already use a variety of sandboxing techniques to achieve separation between tabs. Some of these techniques work inside Flatpak, but some of them are broken by Flatpak:

> Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces.

Some of them are replaced by Flatpak, for application developers that wish to use the APIs:

> What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further

Fortunately, it seems Wick is optimistic about UID namespacing, the main thing stopping Firefox and Chrome from fixing this:

> Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.

Back to the topic of instanced Flatpaks, as I understand one snag is that there is a long-term desire (by app stores/platforms in general) for a full boot-to-userspace code-signing setup to be tied into the sandboxing. The identity of each application should remain the same (unless specifically overridden by a power user) so that a fake version of an application can't adopt an existing application's confidential encrypted files if it doesn't meet the codesigning requirements. I guess one solution here would be for the segregated instances to be nested inside the application's identity, but that's getting quite complex. And we don't even have encryption nor any functioning secure boot + confidential computing implementation yet -- all we really have so far on this front is the reverse domain name notation being verified by Flathub, with filesystem access sandboxing to keep these folders separate.

I might have misunderstood this part, isn't that the role of the xdg-portal which gives ephemeral access to whatever gives access to to the instance?

Like VirtualBox snapshots? Then you will want to branch, merge and rollback these snapshots.

This is like Qubes TemplateVM vs AppVM.

Even if you’re right about how software packages should work (I tend to agree), whether Flatpak should take on enforcing this model is a whole other question.

As far as I know, older packaging systems like dnf/yum and apt allow what Flatpak allows.

Maybe the developers just wanted to focus on being a good packaging system, which as we’re seeing is a hard enough job, and not on changing the permission model of packaging systems. Seems reasonable?

Mildly OT but I have longed for this kind of app portability in Android too. Some OEMs like Xiaomi apparently took note a few years back, offering inbuilt app "duplication" features in their OS's but only for a few popular apps like WhatsApp.