A single percentage of the revenue google generated by using ffmpeg would fund development indefinitely.

Well put.

Would it make more sense if this Sovereign Tech Agency behaved less like a Sovereign Tech Fund and simply hired the developers? Or is civil servants developing OSS commodities too much of a heresy?

Well said.

On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.

We do all this self-congratulation around funding OSS companies and then end up with OSS companies that exist only thanks to government subsidization. Why? Isn’t governmental control over funding what we hate about Microsoft? What is so bad about letting real customers decide which companies need funding?

By default, software has a sandboxed location that is exposed to the host in `~/.var/app/[APP]`.

Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.

The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.

Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.

It's up to you, really, to only use flatpaks that declare tight permissions and implement the proper protocols to safely access resources they don't declare.

This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.

> But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.

That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.

Tech debt, primarily. Flatpak is designed to be able to package apps not designed with it in mind.

If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.

Same prefer, although I'm not sure what you mean by "installing changes data in places on my disk"?

Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.

I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.

I'd prefer that too. Preferrably with permission popups for requesting folder access outside of it. Shared libraries / whatever flatpak calls them could live at a central symlinked location?

Isn't that exactly how it's supposed to work, though? When I install a flatpak app for my user, it gets put into a standard location as a directory and by default has no access to filesystem other than the apps own config and data dirs (can't remember the paths). The fact that many apps choose to require excess permissions and can then bypass standard locations is a different matter

I use podman for things like this, works perfect until you want desktop applications but you can hack it about a bit to work fine with pipewire and Xephyr and you have. I feel like a lot of these desktop container systems are horrible and are quite hostile to configuring in the way you want around permissions and such and podman or docker does a better job.

In the beginning, Flatpak was seen as savior for the Linux desktop ecosystem by making more applications available for more distributions, possibly packaged by the upstream maintainer, but they didn't realize that Flatpak resp. Flathub are actually just another distro with its own builds, repository, package manager, package format and community.

On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.

Don't know how you installed it, but required permissions are usually shown and warned about. The CLI could be clearer, though, but shows that host filesystem access is granted to calibre when it prompts to install

That’s what the kasmweb images on dockerhub are - desktop apps containerised

> No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on

This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions

https://flathub.org/en-GB/apps/com.calibre_ebook.calibre

> calibre is potentially unsafe

> Full file system read/write access

> Can read and write all data on the file system

So what? I would rather they made Flatpak better so we have unified gui app system.

Same except for Steam. Hope this money revitalizes bubblewrap's development, it'd be nice to get proper signal handling cleanup up then merged (even util-linux's unshare has it, these days).

This is focus on desktop. They just want as good app sandboxing as it is on mobile platforms.

Only issue is with Nix as a long time user, it does not provide a standard way to run your nix builds in some kind of container, there are so many different competing third party systems and some first party systems built in nixpkgs it's self like building oci or docker containers or running systemd containers or even building qcow2 images, each with their own draw back and positives.

More and more I have found myself simply using podman and dockerfiles finding that building nix systems simply gets error prone and annoying and all the containerization systems leave a lot to be desired. Though I have some custom scripts for utilizing btrfs snapshots to create different nix store snap shots for containers or vms running with nix stores with virtiofs. This works quite well but not ready to be released and fiddly when things break and requires BTRFS.

I do agree flatpak and friends are not great though.

Nix is always doing its own thing. The community is fragmented and there are no enforced packaging conventions. They have a "best practices" page that lists language features you're not supposed to use because they break reproducible builds, aka the whole point of Nix. And they don't even restrict network access by default.

It's also not doing runtime sandboxing at all. Isolated builds protect you from supply chain attacks but not malware or vulns in the actual code, and they don't do anything for closed source apps.

Flatpak runs everything in a container with access limited to what is declared in the manifest and you can restrict it even more with Flatseal. It's not as secure as a Firecracker VM but it works way better than any other package system on Linux when it comes to security and distro independence.

Agreed. With all the improvements in namespacing I’m seeing the potential of all desktop apps being namespaced in a reasonable way, where filesystem access to e.g. /home is controlled through a kernel-hook prompt callback, with something like “always allow for this directory” etc. That’d be so awesome!

Flatpaks are a common packaging mechanism used on immutable systems. They are very attractive (conceptually) for large org deployments, so I can totally see the appeal here