For portal, a case is generally targeted, and UI is made such that the user understands the request.

Here, what you are proposing allows apps to request any path or file without providing understanding to the user. Also, it will not help apps. If a cautious user does not understand the request, then they cannot use the useful feature.

For case 1, that’s having a portal that requests access to app launchers. The access is selective (i.e. the user can choose which app launchers to give). Restrictions like not launching an app with custom command may apply.

For case 2, one solution is the same as for case 1, but requires the other app to expose its launchers in .desktop files. Another solution is to have the app requesting this file (so, no static permission here), but then the locations will be presented to the user (however this solution is not the best, because the user may not know what this file is about). Another one is to request access to game libraries, and the user will have to select all of them (there is a discussion on a library portal).

Correction for case 2, the "another solution": The user is selecting the file to open, then the app can request the locations. This is the fileset request (from my neighboring files proposals). However, in the UI for this, I wanted to say something like "project" file to provide a hint to users about what this portal is about.

Here, what you are proposing allows apps to request any path or file without providing understanding to the user.

The Portal is pretty clear: It ask the user to access a given path. Why should this a problem to understand?

For case 1, that’s having a portal that requests access to app launchers.

That' correct. A Portal would be better in this case. This is just an example to illustrate a use case.

but requires the other app to expose its launchers in .desktop files.

Steam does not create .desktop files. Only when the user requests it. Also .desktop files are for launching applications. It would not make sense to create .desktop file for save data of a game or for Proton, which the the Desktop should not directly launch.

Another one is to request access to game libraries

There is currently no portal for this, only a discussion. This portal would make the libraries portal mostly obsolete.

The user is selecting the file to open

Why should the user be forces to select a file for which the app already knows the exact path.

The Portal is pretty clear: It ask the user to access a given path. Why should this a problem to understand?

The problem is the path. With your proposal, you are giving apps the power to ask for anything. So what happens if the app asks for access to a path that the user doesn't know what it is or what feature it serves? What will the user do? If they choose "allow" because "the app asks for it", they are giving something without knowing what it is. If they deny because they don't understand, and it turns out to be useful for the app and the user, they will not be able to take advantage of the app feature (they can change the permission, but that would be like denying anything and then changing the permission once they know what the path is for).

There is currently no portal for this, only a discussion. This portal would make the libraries portal mostly obsolete.

No. The Library Portal does not allow an app to request access to specific locations. It allows the user to select multiple locations representing a library. In my vision for this portal, it would allow an app to request access to a specific type of location (e.g., a music library). The user would have to select these as well. An exception is made for xdg user directories: the user can select a known directory directly in the interface (but the app does not request access to it).

Furthermore, it is not pleasant in terms of user experience to present the user one by one each location to allow or deny access to (although this gives the user the power to not give all locations; however, we may find it reasonable to request access to all locations on the basis that these locations come from a single file that the user opened).

Why should the user be forces to select a file for which the app already knows the exact path.

Again, the understanding of the request. Also, the fact that users select the file proves (somewhat) that they know what they are doing.

In any case, be aware that there is no portal that is a solution for covering multiple different cases. Portals are designed based on a case or group of cases with similarities and for which we know exactly what "object" they want to access. This object is as precise as possible and is directly understood by the user.

On the one hand, we should be pragmatic and add portals that applications require to function.

On the other hand, the portals have been very careful to avoid confusing yes/no allow/deny dialogs thus far. Tying permissions to concrete user action (e.g. drag and drop, open file chooser) has been a core design tenant, and this has worked out very well thus far. I'm afraid I don't see any plausible path to square your proposal with our existing security model, where permission request dialogs are expected to be thoughtfully designed and not ask the user confusing questions. If we add this portal, or any similar portal, we'll just train application developers to create unlimited requests, and train users to always accept any request. So I suggest we reject this.

Let's focus on your use cases instead:

Apps can use this portal if they need filesystem access only for a specific feature. For example, if an app provides a feature that requires it to see all installed apps on the system, it can now request access to /usr/share/applications only when needed.

If the application needs direct access to /usr/share/applications, then it's just not sandboxed. Might as well use a static permission?

The path is not known in advance. Take, for example, an app that works with Steam games. Steam allows storing games in different locations. You need to read the file ~/.steam/steam/config/libraryfolders.vdf to get a list of all locations where Steam saves games. An app that wants to work with your Steam games could read this file (with a --filesystem permission for ~/.steam/steam) and then request access to all locations.

That's just not ever going to work. Apps do require some changes when being packaged as a Flatpak. This is one of them. Accessing ~/.stream is unacceptable. The config file should simply move to Steam's xdg-config dir so that Steam always has permission to read it. Trying to share config between Flatpak vs. non-Flatpak Steam is a fool's errand. Then Steam can use file choosers to request the user select directories where games might be stored. Selecting the directory once is enough; that provides permission to access it forevermore. Do this once before adding the directory to the config file; if the directory is already specified and Steam doesn't have permission to access it, try opening a file chooser one level above it to give the user a chance to grant poermission.

Globally:

• Launching apps / games: Portal to access launchers and launching them.
• Accessing libraries of others apps: If going with a library portal, maybe a request to access libraries given to a specific app might be added. Folders added via this portal could be automatically tagged in the permission store with their library type. However, this will only work with folders added this way. Also, that’s not possible if the library has been created by the app in its own space.

For game saves, only the file chooser can be used, the user selecting the relevant folder. That said, this isn’t easy if they are in the hidden folders (.var/...). Logically, unless an app has a good reason to do so, its libraries shouldn’t be in their space, but in user space.

I agree with @mcatanzaro. This doesn't look like a direction that we should go towards. I will close the PR in a few days if there are no objections.

So what happens if the app asks for access to a path that the user doesn't know what it is or what feature it serves?

If you don't know, why a permission is needed you can always reject.

they will not be able to take advantage of the app feature

That's the same with every feature.
If I want to record my screen with OBS and deny the request of OBS to access the Screen, I will not be able to take advantage of the screen recording feature.

No. The Library Portal does not allow an app to request access to specific locations.

So it's a completely different portal.

to avoid confusing yes/no allow/deny dialogs

There are multiple examples of such dialog in xdg-desktop-portal.

not ask the user confusing questions

Why is requesting access to a path a confusing question?

train application developers to create unlimited requests

What would be the alternative? Use the file chooser portal and tell the user tom select this specific path? Or tell the user to open add a static permission to the Flatpak?

train users to always accept any request

That's always the problem with permissions. In the end, it's the choice of the user if they want to grant a permission or not.

If the application needs direct access to /usr/share/applications, then it's just not sandboxed.

Why it's not sandboxed? The purpose of a sandbox is, that Apps just have the permissions they need to work and nothing else.
If a App needs to access /usr/share/applications then that's a correct permission.

Might as well use a static permission?

As already written in the starting post, the goal here is to avoid static permissions, is the access is only needed for a specific feature.
A example for this is jsSimpelAutostart which allows editing autostart entries.
It also have a feature to add programs from the menu to the autostart. So it only needs permission to access /usr/share/applications when the user wants to use this specific feature.

This new portal would allows to request the path only when it's needed which allows Apps to ship with less static permissions by default.

I try to give a better example than Steam, as it is not really understood:
There are Apps which need a list of all Installed Flatpsks (e.g Flatseal or jdFlatpakSnapshot).
By default Flatpak has 2 installations: /var/lib/flatpakand ~/.local/share/flatpak. So the get a list of all installed Flatpaks, Apps need access to those directories.
However, Users can add custom installations.
Apps packaged as Flatpaks are not able to support custom installations, as there is no way to give a static permission, as the custom installation is not known in advance.

This new Portal would allow Apps to read /etc/flatpak/installations.d and ask for permission to access the installation.

Portal to access launchers and launching them

This is also a Portal I want, but keep in mind that I just presented a example.

I've already explained why and I'm tired of giving the same explanations over and over again.

That said, given the way GNOME and Red Hat are acting again, this is no longer my problem.