Originally posted by Danny3
View Post
Prompts are taking longer because there are more moving parts to coordinate and they wanted to prioritize getting a critical mass of packages that Just Work™ at least as well as the older packages without the ability to sandbox things.
(That's why a lot of Flatpak packages grant overly broad permissions. They want to get past that chicken-and-egg problem by making a good first impression of the packages' usability, you can always use Flatseal to tighten the permissions, and they lock down the default permissions later as the patches to make the prompting work better get upstreamed.)
That's also why you haven't seen any prompts. Because the goal is to make it so you don't notice anything different if possible... things are just more secure.
A good example of that is the file chooser portal. GTK and Qt have been retrofitted so that, if an application is using GtkFileChooserNative or QFileDialog without Option::DontUseNativeDialog, then GTK or Qt will transparently hand off to the XDG Portal system.
If you've found something where Flatseal says it has no filesystem permissions but the Open/Save dialogs still show the entire filesystem, that's what's going on:
- The application asks for an Open/Save dialog using the same GTK/Qt API as always
- GTK or Qt detects that it should use portals and makes a D-Bus call to the file chooser portal
- The privileged code outside the sandbox (provided by xdg-desktop-portal-kde) displays the standard KDE open/save dialog
- When you click OK, xdg-desktop-portal-kde mounts what you picked into the sandbox before replying to the D-Bus call with the path you picked.
- The application inside the sandbox never even notices there's any sandboxing going.
Adding prompts for audio and video access is going to be handled by Pipewire, which is like PulseAudio but for both audio and video... and the current state of things is so primitive (let the application open /dev/video0 directly if it wants camera access) that the same CUSE-based "proxy access to the old API like osspd did for OSS APIs" code that is needed for implementing backwards compatibility in Pipewire is also the code they'd have to write for a temporary hack for the current solution.
Originally posted by Danny3
View Post
Originally posted by Danny3
View Post
(I've mentioned that I'd like to see Flatpak gain the ability to grant access to the public Internet while denying access to stuff that's obviously part of the local LAN.)
Locking down network access in more fine-grained ways is lagging behind some of the other things which are more relevant to protecting you from bad actors who don't respond to the passing of laws like the GDPR. (i.e. They're prioritizing catching up with stuff that's already a solved problem on Android.)
Originally posted by Danny3
View Post
In the browser, if the new API's not ready, websites just can't do it.
Same reason Android and iOS are much better at sandboxing applications than Windows, Linux, and macOS. They didn't have an ecosystem of legacy applications to avoid breaking when they did it. (And retaining compatibility with legacy applications is why the progression of "near-monopoly desktop platform" went "MS-DOS → Win3.1x → Win9x → WinXP → ...". Backwards compatibility is a huge competitive advantage and Microsoft knows it.)
Originally posted by Danny3
View Post
xdg-desktop-portal-kde is the component that's responsible for providing KDE-native GUIs for the desktop-agnostic undercarriage responsible for those sorts of prompts. ("XDG Portals" is the name of the system that's being retrofitted as a counterpart to Android's Intents system.)
Comment