It’s deprecated because it has been replaced by GtkFileDialog, which always goes through the portal, instead of requiring opting into a specific API.
Yes, that’s a problem. See above.
What clash?
That’s outrageous. You want humans to check applications to ensure… what, verify that they are not malicious? Verify that they do not contain memory safety vulnerabilities? This is wildly unrealistic, sorry.
Unsandboxed applications (including nearly all distro-packaged applications) are dangerous and users deserve to be warned. We should respect users and make our applications safer by working to mitigate damage as far as possible when our applications are compromised, rather than assuming it won’t happen.
Strong language, when you agree with me.
Here’s a conundrum:
Computer person: "Mr Shakespeare, we want to protect your important data from bad actors (sorry). Where do you keep your plays?
Will: “In /home/will/Documents/Plays”
Computer person: “OK, we’ll use restrict the word processing application to /home/will/Documents/Plays.”
Will: “Look, I’m not a computer person, but won’t that give the bad guy access to the directory which matters most to me?”
Computer person: “Errr…”
I can’t speak for all distributions, but in Fedora, the general answer is: absolutely. That is part of what packaging something for the distro means. It’s not perfect, and of course any app that accesses untrusted files or networks can be subverted. But basically, we have norms and expectations for software packaged for Fedora Linux, and these are much stricter than those for Flathub.
This isn’t meant to be a knock — Flathub has more of a “let’s get stuff available!” priority, as well as “direct from the developer to you, with no middle layer”. These have their own virtues.
I agree with the goal of getting all apps to have strict sandboxing, and am in favor of preferring Flatpak (including prioritizing them over rpms in Fedora Workstation). I feel like “unsafe” seems a little too strong at this point given the current reality (most apps on most desktop OSes have wide latitude!) — personally, I’d prefer a neutral “not sandboxed” for both, and to turn up the heat on both formats a little more gradually (as we have a greater number of Flatpaked apps in Fedora, and have more with meaningful sandboxing so 90 of the distro isn’t flashing warnings.
Most Fedora desktop packages are updated by a script. 
Of course humans do some stuff too, but realistically there’s no chance we would notice if an upstream released a malicious update, not until somebody gets hurt and reports a problem. Distros work because we trust upstreams not to be intentionally malicious, and that has historically worked out fine.
(FWIW, my proposed terminology for replacing “unsafe” is “privileged,” which is basically the same as “not sandboxed.”)
It’s a lot more hand-done than I’d like, actually — kind of the opposite problem. But generally, yes: there is not code review with every update. Something malicious could slip in. There are a lot of areas where we could do better. (And, again — I definitely believe that Flatpak-all-the-things! is part of our path to doing that.)
But, you’re also not going to run into the situation where, say, you are looking for a tool that presents a nice graphical tree of hardware on your system with details, and you find something that describes itself in a way that seems useful, and so you install it, and then click “open” but nothing happens, so you click a few more times and still nothing, so you look closely — and discover that the screenshot is a misrepresentation and it’s really a tool that collects identifying details about your system and uploads them to a public website (while displaying nothing).
It works on the desktop, I’ll build the Flatpak and check that.
I can see that would be a way of doing it, but the output file would not be accessible. The user would then have to use the file chooser to select that. Completely unworkable.
Well it’s totally up to you, of course, but on the surface, putting up a Save dialog immediately after the user hits the “go” button, and letting them confirm the output name doesn’t seem that awful to me. I mean, you should be able to prepopulate the dialog with your preferred name, so it will really just be one extra click for the user.
And of course you’d only need to do it for the one-and-done files mode of your app, not the batch directory mode of your app.
It might be a “good enough” workaround until Portal to open file and neighbouring files · Issue #463 · flatpak/xdg-desktop-portal · GitHub is fixed (at which point you could go back to the old way if you wanted).
or i guess live with the flag. i guess there’s pluses and minuses to both options.
1 Like
This may select several input files (which is explained to the user), and produce a multiple of that number of output files (which the user is warned about), so not really practical.
I haven’t finished reading that, but it might be the long-term answer.
Yes, users may assume similar standards between OSs, so may think “unsafe” is, by comparison, a very strong warning.
Yes, or if possible a more common phrase that most users will understand.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.