Flatpak Is Not the Future

There quite a few things I don't agree with in regard of this article.

First, the suggestion that permission should be prompted when running the app, the app using some sort of API. This would mean that Linux app should become tightly coupled to Flatpak. I have no idea how it would be possible to convince all developers, distributions, vendor to adopt Flatpak. I think it would be largely ignored so an ineffective way to bring those change to the Linux ecosystem in the end.

Then, I don't have the real answer, but prompting users with questions when they use the app is the worst approach to security. Being tech literate helps understanding what's happening, but people with less understanding answer those out of annoyance because they're trying to do something and, all of a sudden, the operating system gets in the way. The choice is not driven by security concerns but by frustration or urgency.

I can't think of any operating system that found the right solution yet, but I do think that the Flatpak approach is by far the smartest. Just naturally give access to things by following user choices (just give access to the select file once the file is selected, just give access to the screen the user choose to share once the user choose to share it). No more stupid prompt that gets in the way of things.

Speaking of runtimes, it's exactly the same problem. For Flatpak to be adopted, it would require all distribution to invest a lot in it. How would it work for Gentoo and its use flags for example? How to deal with different versions of dependencies?

What would happen would likely be for distribution to build the equivalent of runtimes, but on their side, allowing to have several versions in parallel. So in the end, it would be a similar situation, but much more messy as each distribution would have to do the job. Is having those runtimes an actual problem or the solution that Flatpak came up with to the problem of fragmentation in distributions? In my opinion it's the second.

This article is full of either errors, or at least misleading statements. It comes across as trying to say something controversial to get attention.

Just one obvious glaring issue with the article:

>Note that the app package itself is only 4.4 MB. The rest is all redundant libraries that are already on my system

Um, no. It's not redundant. Your system might get updated, replacing the needed libraries with backwards incompatible libraries, and then your app would break.

I do agree with the general idea that not limiting possible runtimes to an approved list means essentially infinite runtimes, which can balloon disk space. I think you need choice to prevent stifling innovation. At least at first. But hopefully the community will end up doing the right thing here over time.

> As a replacement for "native" package management? No. Flatpak makes sense if you have a small number (There are several "Linux" operating systems that use an immutable base image: Fedora Silverblue, Endless OS, purportedly Steam OS 3. The idea here is the distro packages are great for composing your base system, but once that is done, the entire `/usr` filesystem is frozen. You can upgrade it or roll it back atomically, and in some cases you can do some magic to apply smaller changes (Silverblue has a nice implementation with `rpm-ostree`), but distro packages are intentionally not a typical end user thing. In this kind of OS, the best way to install apps is using something like Flatpak. And that's very much what Flatpak is designed for.

So…

$ flatpak list --app | wc -l

94

And it works well :)

I was thinking about this the other day and a wasteful solution to the packaging problem in open source is the decentralized build solution on a blockchain like platform. Either with PoW or PoS. In PoS, a node builds the code pulled from source control, multiple other nodes validate the build and its hash and add to the blockchain and to the repository. Now the builds are relatively trustable. Of course need to figure out an incentive structure for miners/validators to do this expensive work.

Lots of other debate (both pro and con) that I'm not going to get into. I like the effort going into Flatpak, but I don't like everything it's doing.

Is Flatpak really secure, is it's permission system good, how does resource sharing work, whatever. I'm not going to comment on any of that in either direction.

But I do want to call out this specific paragraph:

> Apparently, developing client APIs for apps themselves is antithetical to Flatpak’s mission. They want the apps running on Flatpak to be unaware of Flatpak. They would rather modify the core libraries like GTK to integrate with Flatpak. So for example if you want to open a file, you don’t call a Flatpak API function to get a file or request permissions. Instead, you call for an ordinary GTK file open dialog and your Flatpak runtime’s GTK internally does the portal interaction with the Flatpak service (using all sorts of hacks to let you access the file “normally” and pretend you’re not sandboxed.)

Heck client APIs. This is the correct way to do sandboxing, for two reasons:

----

First, this is not something that's immediately obvious, but over time with both phone platforms and on the web have been starting to learn that applications should not be able to change their behavior or monitor whether or not they are sandboxed. This closes an important hole in app security where application developers either change/block behavior, or try to "trick" users into granting unnecessary permissions.

For a filesystem, an application should not be aware of whether it has access to every file, it shouldn't be aware of whether or not it's running on a temporary filesystem. And while it should be able to ask the user to grant it access to a directory, it should have no easily way of validating whether or not the user granted that permission -- it should just get a folder pointer back, regardless of whether that pointer is real, a different folder, or a virtual/temporary location.

A lot of existing sandboxing doesn't follow this rule. The web is normally pretty good at sandboxing, but in this regard it's honestly pretty bad. We can't follow this ideal with everything, there are some permissions that are impossible to fake. But in general, we don't want to make things too easy for malicious developers.

> If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs to request permissions first. iOS is the same. So why shouldn’t I be able to just call flatpak_request_permission(PERMISSION) and get a callback when the user approves or declines?

In this regard, Android and iOS are wrong. Not as a matter of opinion, I will make a medium-to-high confidence claim that they are just flat-out approaching sandboxing security incorrectly. It's not their fault, I wouldn't have done a better job. This is something that we've become more aware of as we've seen how sandboxing has evolved, and as it's become more obvious how apps try to circumvent sandboxes. And this could be a longer conversation, yes there are tradeoffs, but the benefits of this approach far outweigh them, and I think in the future that more platforms (including iOS/Android) are likely to move towards seamless permissions that are hidden from applications themselves.

Remember we sandbox applications in part because we don't trust developers. And while it's not the only reason for hiding user controls from apps, it is a good enough reason on its own. Don't give attackers unnecessary information if you can help it, this is security 101.

And the author is right, this approach is genuinely more brittle because it requires building mocked/sandboxed API access rather than just throwing an error. But hey, sandboxing itself is more brittle. We deal with it for the UX/safety improvements.

---

Second, for the reason that the author hints at:

> Fedora is auto-converting all of their rpm apps to Flatpak. In order for this to work, they need the Flatpak permission system and Flatpak in general to require no app changes whatsoever.

There are substantial advantages to having sandboxes that work with existing apps. This is always a give-and-take process, but in general we don't want to force updates of a large portion of user-facing apps. And we want them to be easy to get into Flatpak.

The core libraries, user portals, distros themselves -- it is a pain to update them, but they have more eyes on them, they are more likely to be updated securely, and they have more resources available to them. I think it would be a mistake to shift that burden entirely onto application developers. Linux has a habit of doing this kind of thing sometimes, and it's a bad habit. We want Flatpak (or any sandboxing system) to be something that can be wrapped around applications without a lot of work. Ideally, a 3rd-party maintainer might even be able to bundle an app themselves.

There is also a sort of future-proofing built into this, which is that there is no such thing as a sandboxing system that's secure from day 1. We've seen this pop up on the web, which (for all of its general criticism about expanding capabilities) still has a much smaller attack surface than most native apps. Web standard developers are very careful, but there are still breaking changes sometimes when new security measures/permissions need to be added.

It would be very good if (as much as is possible), introducing additional new privileges and sandboxing capabilities to Flatpak did not require code updates for every single app using those capabilities that was built for an older version of Flatpak. If it's at all possible to avoid that scenario, avoiding it is the correct move to make.

And finally, touching on burdens for maintainers again, different people may prefer different permission systems. If at all possible, we want to avoid forcing individual app developers to fragment their codebase and maintain different branches for different security sandboxes. Flatpak should run the "base" version of your app with little to no changes. This also benefits users, because fragmentation and forcing users to install multiple simultaneous sandboxes on their machine is heckin awful.

So for all of those reasons, minimizing code changes for individual apps is a really good goal to have, even if it admittedly makes Flatpak more complicated and a bit harder on core platforms like GTK.

----

Other criticisms, whatever, I have some thoughts but it's not important for me to give them.

But the sandboxing criticisms I see in this article betray (to me) a lack of understanding about what the current problems are with phone/web security and what the next "generation" of sandboxing problems are that we're going to face. And I think that Flatpak is at the very least approaching sandboxing through a more mature/modern lens than the one we were using X years ago in early smart phones.