Flatpak Is Not the Future
Lots of other debate (both pro and con) that I&#x27;m not going to get into. I like the effort going into Flatpak, but I don&#x27;t like everything it&#x27;s doing.<p>Is Flatpak really secure, is it&#x27;s permission system good, how does resource sharing work, whatever. I&#x27;m not going to comment on any of that in either direction.<p>But I do want to call out this specific paragraph:<p>&gt; 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.)<p>Heck client APIs. This is the <i>correct</i> way to do sandboxing, for two reasons:<p>----<p>First, this is not something that&#x27;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&#x2F;block behavior, or try to &quot;trick&quot; users into granting unnecessary permissions.<p>For a filesystem, an application should not be aware of whether it has access to every file, it shouldn&#x27;t be aware of whether or not it&#x27;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&#x2F;temporary location.<p>A lot of existing sandboxing doesn&#x27;t follow this rule. The web is normally pretty good at sandboxing, but in this regard it&#x27;s honestly pretty bad. We can&#x27;t follow this ideal with everything, there are some permissions that are impossible to fake. But in general, we don&#x27;t want to make things too easy for malicious developers.<p>&gt; 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?<p>In this regard, Android and iOS are <i>wrong</i>. 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&#x27;s not their fault, I wouldn&#x27;t have done a better job. This is something that we&#x27;ve become more aware of as we&#x27;ve seen how sandboxing has evolved, and as it&#x27;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&#x2F;Android) are likely to move towards seamless permissions that are hidden from applications themselves.<p>Remember we sandbox applications in part <i>because we don&#x27;t trust developers.</i> And while it&#x27;s not the only reason for hiding user controls from apps, it is a good enough reason on its own. Don&#x27;t give attackers unnecessary information if you can help it, this is security 101.<p>And the author is right, this approach is genuinely more brittle because it requires building mocked&#x2F;sandboxed API access rather than just throwing an error. But hey, sandboxing itself is more brittle. We deal with it for the UX&#x2F;safety improvements.<p>---<p>Second, for the reason that the author hints at:<p>&gt; 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.<p>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&#x27;t want to force updates of a large portion of user-facing apps. And we want them to be easy to get into Flatpak.<p>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&#x27;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.<p>There is also a sort of future-proofing built into this, which is that there is no such thing as a sandboxing system that&#x27;s secure from day 1. We&#x27;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&#x2F;permissions need to be added.<p>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&#x27;s at all possible to avoid that scenario, avoiding it is the correct move to make.<p>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 &quot;base&quot; 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.<p>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.<p>----<p>Other criticisms, whatever, I have some thoughts but it&#x27;s not important for me to give them.<p>But the sandboxing criticisms I see in this article betray (to me) a lack of understanding about what the current problems are with phone&#x2F;web security and what the next &quot;generation&quot; of sandboxing problems are that we&#x27;re going to face. And I think that Flatpak is at the <i>very</i> least approaching sandboxing through a more mature&#x2F;modern lens than the one we were using X years ago in early smart phones.