5 comments

[ 7.6 ms ] story [ 33.2 ms ] thread
[flagged]
Flatpak's "sandbox" is mostly theater, and it gives little when it comes to privacy. Apart from the obvious that packages sometimes come with overly broad permissions to be usable at all (but you are still given a marketing pitch about enhanced safety, granted, flatpak.org doesn't do it but flathub does), the fact that some paths are denied or some access is revoked is also a data point.

I'd like to have a system where I can choose to give any bitmap, movie, or blank screen when an application asks me for permission to use my camera. It shouldn't know that I have denied it. When it asks for my microphone, I should be able to choose to make it think I allowed it microphone access with dummy audio stream with no audio or audio of my choice. When it asks me to open a file, or a directory, it should invoke a system dialog that cannot be faked, and when I pick a file/directory for it, that directory or file should be bind-mounted into its mount namespace without giving it extra information about other files beside it, or indeed what's the full path of the file. When recording a screen, I should be able to pick which regions and which applications it should be able to see, and the system should make it think it's all there is.

All the while the application doesn't even have to cooperate. This is the important bit.

I think the pieces to do this are mostly there already (portals, Pipewire, namespaces), it's just a lot of faff to actually implement.

Flatpak, Snap, appimage, etc...

I have pretty fastidiously avoided ever using any of the "package everything into the image" projects, and my life has been considerably better off.

All these things serve to do is make the developer experience easier, at the cost of delivering a much worse user experience.

I can't think of any reason a user would ever prefer packaged variant of something.

A lot of Flatpak applications ship with filesystem=home, and this is effectively opens up ways of indirectly getting root access (since you can override sudo by editing .bashrc) or overriding .desktop files (of say system settings) to point to your application instead which a user is more likely to enter their password when opening, or override environmental variables, you get the picture.

It's not as if non-Flatpak apps can't do this either, but the false sense of security from Flatpak may encourage people to download apps they wouldn't otherwise.

Unlike Android/iOS where Google/Apple can push developers to update their apps to use new apis, or say bye bye to those that don't, there's no motivation for Linux app devs to update their applications to use portals to avoid the need for filesystem=home, and as long as that exists people will just install them with a false sense of security.

Flatpak is not a security project, it's an app distribution one (which I think it does a generally better job than native packages, but the bar is low). The sandbox should be considered part of the separation from host dependencies, nothing else.

Personally I'd just as soon have something that is like Flatpak but without the security pretensions. The main advantage for me is just being able to update each program independently of an OS-level package repository.