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.
fake-name · 5h ago
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.
ChocolateGod · 4h ago
> package everything into the image" projects
But Flatpak does not do this. It consists of runtimes that usually contain the most of what applications needed, and are updated separately from the application itself.
yjftsjthsd-h · 3h ago
Yes, flatpak does do that; its base images only have the basics, leaving apps to bring the rest of their own libraries/dependencies.
paulddraper · 55m ago
Have you as a user never encountered dependency hell??
Who are you and how can we trade places?
jwrallie · 4h ago
It is better when you cannot get a package otherwise, so if you use a distro with a big repo, it happens mostly with proprietary software.
xorcist · 4h ago
Most proprietary software ships as tgz files which you can just unpack and run.
A few ships with "installers", which are mostly just bash scripts with the tgz embedded.
Simple enough.
WesolyKubeczek · 6h ago
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.
its-summertime · 11m ago
> 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.
This is the norm under Flatpak + pipewire for single application captures. For full screen captures, Niri supports blanking specific windows from appearing in captures.
CaliforniaKarl · 5h ago
That reminds me of something iOS is doing (though I don't know when it was introduced).
An app wanted permission to my photos. In addition to the normal "Allow" and "Deny" options, I was also given the option to allow a subset of photos. I chose that option, and was given the normal photos UI, as if I was selecting a set of photos to share or delete. I guess in the back-end, iOS constructed a new photos library consisting of just the ones I selected.
It was cool! And it's good to see things at least one of the things you describe is being shown to a large number of folks. Hopefully that'll drive momentum to wider adoption.
zzo38computer · 44m ago
> 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. 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.
It is what I had thought too (you could also provide a filter, or the video and/or audio output of another program, or other stuff), and I have also seen others with similar ideas than that as well. (It also does not know whether or not you even have a camera or microphone; this way, you can use a program that expects a camera even if you do not have it.)
Although it could be made with Linux and existing systems, my idea was to redesign the entire operating system and computer to support this in order to work better. There is some issues which are not handled by the existing systems, including some fingerprinting, and date/time, and some others.
> 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.
This would be insufficient for many uses, e.g. if a file name is specified by command-line arguments or by configuration files, or if the program does care about other files with a similar name (which SQLite does, so many programs that use SQLite also will). (I had thought of how a sandbox library could be made to support some of these things could be made on Linux, although I had never actually designed or implemented it.)
> 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.
Yes, I agree, it is also a good idea. But, screen recording will also be video input, which the camera also is, so it might work in a similar way.
> I think the pieces to do this are mostly there already (portals, Pipewire, namespaces)
I also think there is problems with the ways some of these things are working. One is that the system will use ambient authority (which is one reason why I had suggested to make up a new operating system instead), and some of the protocols expect use of Unicode and do not support other character sets so well, and the existing sandboxing also does not work very well for user-specified commands to use with popen (many of my own programs do use user-specified commands with popen).
dylan-m · 4h ago
> 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.
You've described exactly what flatpak is doing? I'm curious what gaps you see with its approach in particular.
dylan-m · 1h ago
If it’s important to you that an application doesn’t need to cooperate, then that’s something Snap has an answer for. I don’t remember the name of it or if it got past the proposal stage, but it’s like “if an app opens a file, intercept the syscall and show a dialog.” I think it’s a disgusting solution to a non-problem (it was demoed with Firefox which has dutifully cooperated with our shit for decades). But it’s interesting :)
bestorworse · 5h ago
I want that as well, but I don't think it's practical to do that on the Linux desktop ecosystem. Too slow, too much politics. The gist of it is done by Android though, but that required extensive re-engineering of the user space.
I believe this is part of what [Spectrum OS](https://spectrum-os.org/) is ultimately trying to do. That said, while it’s being actively developed, it’s not a trivial effort and is nowhere near “download the iso and daily drive it”.
freedomben · 5h ago
I would love the capabilities you describe, but I don't think it's fair to call flatpak "mostly theater." Yes plenty of flatpak apps require you to broaden their perms to the point where the sandbox starts to feel pretty weak, and there is plenty more to do on the system, but I think it's a good step forward.
AlienRobot · 5h ago
Then it's never going to happen.
Linux desktop is a huge mountain of "why this basic obvious stuff just doesn't work?"
I mean just stop to consider this. It's 2025. You are still not guaranteed to be able to close an application by moving the mouse all the way to the top right and clicking, because sometimes the X button has a margin at the top. This is insane to me. This is like such a basic thing that I have no idea how do you even manage to get it wrong.
If Linux can't even get the X button right, do you seriously expect anything else to ever get fixed?
pstuart · 5h ago
That's a desktop issue, not a linux issue.
AlienRobot · 5h ago
I don't remember installing "desktop" on my computer.
pstuart · 2h ago
A lack of awareness does not determine whether something is true or not.
While Linux, like everything else, is not perfect, it is technically just the kernel, and the version of linux you installed was called a "distribution", and they normally package one or more varieties of GUIs (Graphical User Interface), commonly known as a "Desktop Environment".
You may want to file a bug report for their respective project, or if you're up to it, fix the problem yourself instead of just complaining about it.
dangus · 1h ago
Linux distributions have dozens of choices of desktop environments. You did choose a desktop to install you just didn’t read the basic information about your choice.
Frankly, if you don’t know this basic fact about Linux you aren’t a reliable source of opinion on whether the Linux desktop is a “huge mountain of obvious stuff that doesn’t work.”
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.
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.
But Flatpak does not do this. It consists of runtimes that usually contain the most of what applications needed, and are updated separately from the application itself.
Who are you and how can we trade places?
A few ships with "installers", which are mostly just bash scripts with the tgz embedded.
Simple enough.
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.
This is the norm under Flatpak + pipewire for single application captures. For full screen captures, Niri supports blanking specific windows from appearing in captures.
An app wanted permission to my photos. In addition to the normal "Allow" and "Deny" options, I was also given the option to allow a subset of photos. I chose that option, and was given the normal photos UI, as if I was selecting a set of photos to share or delete. I guess in the back-end, iOS constructed a new photos library consisting of just the ones I selected.
It was cool! And it's good to see things at least one of the things you describe is being shown to a large number of folks. Hopefully that'll drive momentum to wider adoption.
It is what I had thought too (you could also provide a filter, or the video and/or audio output of another program, or other stuff), and I have also seen others with similar ideas than that as well. (It also does not know whether or not you even have a camera or microphone; this way, you can use a program that expects a camera even if you do not have it.)
Although it could be made with Linux and existing systems, my idea was to redesign the entire operating system and computer to support this in order to work better. There is some issues which are not handled by the existing systems, including some fingerprinting, and date/time, and some others.
> 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.
This would be insufficient for many uses, e.g. if a file name is specified by command-line arguments or by configuration files, or if the program does care about other files with a similar name (which SQLite does, so many programs that use SQLite also will). (I had thought of how a sandbox library could be made to support some of these things could be made on Linux, although I had never actually designed or implemented it.)
> 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.
Yes, I agree, it is also a good idea. But, screen recording will also be video input, which the camera also is, so it might work in a similar way.
> I think the pieces to do this are mostly there already (portals, Pipewire, namespaces)
I also think there is problems with the ways some of these things are working. One is that the system will use ambient authority (which is one reason why I had suggested to make up a new operating system instead), and some of the protocols expect use of Unicode and do not support other character sets so well, and the existing sandboxing also does not work very well for user-specified commands to use with popen (many of my own programs do use user-specified commands with popen).
You've described exactly what flatpak is doing? I'm curious what gaps you see with its approach in particular.
Risking getting down voted but I don't want to repeat myself: https://news.ycombinator.com/item?id=43255985
Linux desktop is a huge mountain of "why this basic obvious stuff just doesn't work?"
I mean just stop to consider this. It's 2025. You are still not guaranteed to be able to close an application by moving the mouse all the way to the top right and clicking, because sometimes the X button has a margin at the top. This is insane to me. This is like such a basic thing that I have no idea how do you even manage to get it wrong.
If Linux can't even get the X button right, do you seriously expect anything else to ever get fixed?
While Linux, like everything else, is not perfect, it is technically just the kernel, and the version of linux you installed was called a "distribution", and they normally package one or more varieties of GUIs (Graphical User Interface), commonly known as a "Desktop Environment".
Here is a list for your edification: https://en.wikipedia.org/wiki/Desktop_environment
You may want to file a bug report for their respective project, or if you're up to it, fix the problem yourself instead of just complaining about it.
Frankly, if you don’t know this basic fact about Linux you aren’t a reliable source of opinion on whether the Linux desktop is a “huge mountain of obvious stuff that doesn’t work.”