[foobar33333]

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.

[Iolaum]

> This brings you to the same state as traditional package managers with little security

Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

[foobar33333]

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.

[tored]

Gnome Software is pretty much unusable for installing software.

I use it to find software and read reviews, but never install. I always use the terminal for that.

1. Gnome Software does not tell what the package name is for deb, flatpaks, snaps etc

2. Gnome Software does not say what type of package it is (deb, flatpak, snap etc) except when it’s multiple choice.

3. No overview of dependencies.

4. No information what is happening during install.

5. Buggy installation, common case, click on Install, nothing happens, click on Install again and get warning “hey it is already installing you fool!"

Not everyone is comfortable to use the terminal, fixing Gnome Software should be a high priority for distros.

[uneekname]

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

[gbrown]

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.

[antimba]

> 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.

[1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...

[syrrim]

That's what he's saying

[lambda_obrien]

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.

[vetinari]

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

[ziftface]

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.

[vetinari]

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...

[Shared404]

Perhaps make it an optional setting?

"Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.

[vetinari]

It is... you can add/remove any paths you like. The default errs into what users are used to.

See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.

[Shared404]

Makes sense. I use flatpaks only very lightly, I apologize for not checking before opening my mouth :)

[vetinari]

Opening the mouth is fine, nobody has fallen from the sky fully learned about everything ;).

If you learned something that is interesting or useful to you, then great.

[tjoff]

Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.

[vetinari]

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).

[tjoff]

Imho not nearly the same thing.

[vetinari]

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".

[fragileone]

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.

[epr]

> 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.