I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.
The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.
If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb
The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.
When I install something using dnf for example it installs near-instantaneously! Makes me wonder wtf Gnome Software does in the background to make installs so slow :P
It also just seems sooooo slow. I also drop to the terminal for these tasks 100% of the time - including search. I’ll Google for software, and then dnf search to find the specific package if it’s offered.
> The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing.
The current mockups[1] for a UI refresh of GNOME Software have the “Sandboxed” badge and the permission details replaced by a context tile giving an overall “Safe”, “Potentially Unsafe”, or “Unsafe” rating, with additional indications and a safety dialog giving the full information. The ratings are determined from the permissions as well as license, whether the runtime is no longer supported, and whether the source is known.
Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.
Easy, show a pop-up informing the user that the application tried to access so and so file, and if this was intentional, please click allow and try again.
When the sandbox works as it should, the application has no idea that so and so file even exists.
The flatpak portals are trusted system components, that work outside the sandbox and can present some choosers, where the user picks what will eventually become accessible inside sandbox, if the user agrees (whether files via file choosers, microphones, cameras, desktop sharing, whatever). The sandboxed processes talks to the these portal via IPC (dbus, normally).
The thing is, that outside of standard gtk3 and qt5 apps, nothing else uses portals yet (and gtk3 with qt5 do that at framework level, so it's transparent for the apps). You cannot sandbox random electron app, for example, and expect that it will work just like it worked when it was installed via deb or rpm. And with files, it is just not single files (document apps are relatively easy), but imagine opening project file inside IDE or playlist inside media player: the project or playlist was picked by the user and can be opened by the app, but it contains references to other files, potentially hundreds of them. Can you imagine asking the user to confirm opening each and every one of the hundreds of files?
And then there were people complaining that their locally installed SDKs cannot be used from sandboxed IDEs. Sigh, that's kind of the point...
As an counterargument, see all the comments to this article.
Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).
Very similar. Either complaining about non problems, or complaining about some default they can change, or suggesting solutions that are over-complicated and simultaneously inadequate anyway.
Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".
Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.
> The problem is that every desktop program must be rewritten to support this idea
No, and expecting that to work is obviously ridiculous. This type of problem needs to be solved in a way which requires no changes at all from developers, or it will almost certainly go nowhere.
The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.