Replies: 10 comments
-
|
I think this makes sense. It's certainly reasonable to expect a screenshot tool to be run once before you can start using it. My main concern is what it might mean if we extend the same logic to other portals, and what might happen if an app needs multiple permissions. The experience of launching an app for the first time and being bombarded with permission dialogs is not fun. |
Beta Was this translation helpful? Give feedback.
-
That's true. However, I personally do not see a big difference of being bombarded before or after the application window shows up. On Android they handle this in a combined permission dialog, but I guess this is difficult without explicit permission management. MacOS uses implicit management. How are thoses cases handled there? So far, I've only seen single-permission-dialogs there, and I never felt like being bombarded by many of them... Maybe this is not a common problem in practise? |
Beta Was this translation helpful? Give feedback.
-
|
Are there any updates to this? Still have no working screenshot application… 😕 … |
Beta Was this translation helpful? Give feedback.
-
|
The most future proof way of handling it is to have a new Flatpak portal where the application uses a single API which takes a list of what portal permissions it wants permanently, such as "I want screenshotting and global hotkeys", and the portal pops up on first launch and asks the user to confirm. With pre-enabled checkboxes for each requested permission (since most apps won't work without them). Exactly like on Android. After saving permissions, the application should be able to trigger a portal API to open up the same dialog again. This is so that the application can offer a settings button to trigger the permissions dialog for easy access. Lastly, the Desktop Environment's settings panel should have a way to manage all saved per-application permissions. Just like it already does with per-application notification settings currently. This would bring Linux Flatpaks one step closer to a safe, convenient new application ecosystem that one day gives us the Year of the Linux Desktop. |
Beta Was this translation helpful? Give feedback.
-
|
There is no way to go with "on/off" permission being by default set to "on". The thing is the user should set the permission they wants, thus avoiding things like "Done" or "Next, Next, Next, Done" (as there are permissions where we select what to give to the app). Permissions that are requested when needed are preferred over permissions set at app startup because the first ones are contextualized and all permissions are not necessarily needed. However, maybe some are candidates to be set at startup. See #1148.
Prefer open a specific discussion about this by explaining why this should be like this.
GNOME has this. If your desktop environment does not have it, you can request this on their issue tracker as xdg-desktop-portal does not provide that. |
Beta Was this translation helpful? Give feedback.
-
Absolutely not. Applications don't request these things "for fun". They request it because it's necessary for the actual running of the application whatsoever. Example: Screenshot tools such as Flameshot cannot take screenshots without having that right permanently granted to it. They should be on by default. Exactly like all other Flatpak permissions. Remember that Flatpak manifests already request a ton of permissions permanently, and we silently and invisibly accept ALL of them when we hit Install on the Flatpak itself. How many people open a manifest file to look through all the lines and see that it requests The number one priority should be to make the applications work, and to be convenient for people who know why they need the application and can read before accepting the permissions prompt. Not saving the "Next next next" people from themselves. In fact, I'd say that having the necessary permissions on by default will actually save the "Next next next" people from themselves, because if it's off by default, they will get a non-functioning application (no screenshot permissions) and will complain to the developer or Flathub because they were too lazy to read a short dialog question. Wasting developer time and energy. It would still be up to the flathub guardians to approve Flatpaks and make sure they do have reasonable default permissions. That work is already ongoing and is doing a great job making sure that permissions aren't overstepping their boundaries. :)
The idea there is that if someone initially declined a necessary permission, the application can detect that it's missing the permission (such as Screenshot permission), and will be able to display a warning to the user. Flameshot for example could show a dialog box, saying "Sorry, Flameshot cannot capture any screenshots until it has the necessary permissions. Do you want to open the settings to change this now? Yes/No". Hitting Yes would trigger the API to open the same permissions dialog again, showing the current state of the user's last-saved choices, where they can then fix the problem. Without such an API, the work of application developers would be much harder. They'd have to guide people to per-Desktop Environment ways of changing permissions, or tell users to erase all I don't see any way that applications could misuse such an API. Developers in general care about the quality of their applications and would only trigger the permission request API when necessary. If an application decides to spam that dialog on every startup, they either have a really good reason for it (it won't function at all without permissions), or the application is awfully designed - and then people simply won't use it. In general, I think the permission should be modeled after how convenient these things are on Android and macOS. You get an alert that some permissions are needed, and you accept them or decline them (and in that case you don't use the application). Oh by the way, it would have been nice to deal with these kind of permissions directly during the installation step (at the same time that you auto-accept all the permissions requested by the Flatpak manifest), since that would keep the "permissions flow" all in one place... but that wouldn't work with the myriad of natively installed applications. These kinds of "permanent permission requests" would therefore have to be an API and a Desktop Environment settings concern, where people can tweak things afterwards. Since permission portals are needed even for native (non-sandboxed) Wayland applications. There definitely needs to be a new, bigger discussion about which kind of permissions should be permanently saved, and how Desktop Environments should uniquely identify each application and provide a way to tweak the permissions later. For inspiration, here's the permissions that macOS and Android lets a user set permanently: |
Beta Was this translation helpful? Give feedback.
-
|
You are not the first to ask this due to a lack of understanding of the current system. The system mainly consists of an app requesting permission when it needs it and, if possible, the user selecting what to give to the app in order to limit access. An app must ideally request permission so that it appears as part of its workflow. Examples are the file chooser portal and the screencast portal. Note that this can help some users know if the request is legitimate. For a dialog asking for all permissions, permissions are not "on" by default because we worry that over time users will no longer read it and stupidly accept the permissions. The goal is for the user to correctly define the permissions they want/agree with and have a chance to identify whether the request is legitimate. And, as noted, not all permissions are "on/off" types. Additionally, asking at startup could hinder the shopping experience, at least in app stores. If we need it for certain permissions, it is something to see per permission and will probably be rare. An API that allows apps to ask the user for permission again is not a good idea because it would be a way for the app to acquire a specific permission. However, the problem you pointed out - that denying a dichotomous permission prevents from using the app even though we installed it to use it - is completely valid and correct. Note that for the screenshot portal, the "on/off" permission came later and in response to people getting tired of always having to "Share" the screenshot. This problem can certainly be solved by asking the user if they want to allow the app to take screenshots all the time or be prompted every time to share a screenshot (i.e. show interactive mode). This also has the benefit of the user deciding what permission they want instead of the app deciding they should grant permission to always take a screenshot. This can be explored for other portals by opening a discussion indicating which portals you think should adopt a permission system for an app to be usable. Finally, if you want certain permissions to be configured at app start-up, please comment #1148 instead by explaining why for a given case. |
Beta Was this translation helpful? Give feedback.
This comment has been minimized.
This comment has been minimized.
-
|
Is the situation really that bad? I thought the GNOME desktop was easy to use and still very flexible... |
Beta Was this translation helpful? Give feedback.
-
|
I don't think I can convert this to a discussion myself but it should be one. |
Beta Was this translation helpful? Give feedback.
-
Some applications like flameshot want to take screenshots when they get launched and don't have a surface, yet to avoid having UI in the way of whatever is supposed to get captured. This is a problem for the screenshot portal which might require the user to grant permission and can't associate this permission dialog with a surface.
It would be good if there was a way for the app to ask the user to grant permission to take screenshots without taking a screenshot. This permission dialog could be in a settings app or something more in the style of Android.
Beta Was this translation helpful? Give feedback.
All reactions