You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today most of the portals require user interaction to grant permissions for an app to access the resources on the system. This security model makes sense when the user is present on the machine and can allow/deny whatever resources they deem appropriate but this is less than ideal for the case when the user is not directly present on the machine e.g. I am working on adding support in Chrome Remote Desktop (CRD) to access wayland based host using the screencast/remote desktop portals, however, this works well when only when the user is solicing remote support and is present on their machine to interact with the dialogs. This approach doesn't work when, say, I am trying to login to my own machine remotely using CRD.
In this FR, I am requesting a security framework for programmatically granting permissions to privileged processes that try to access the portal APIs. I believe this is somewhat supported for flatpak applications using the manifest file for the applications but would not work for non-flatpak applications that invoke desktop-neutral APIs e.g. screencast/remote desktop portal APIs. It will be nice to have a mechanism to configure permissions per process/app about which portal APIs can be called by them without having a dialog appear on the screen. These permissions can potentially be configured by privileged users/groups on the system and potentially be backed by the permissions store. A variation of this idea is implemented here where the user has to select streams once and remember them for future. I propose to build further on this approach and have a promptless access to portal APIs where feasible as well as by generalizing this by building a framework that works for all the portal APIs, we can be better future proof e.g. when these clipboard APIs are implemented, we should only have to do little configuration to support programmatic access to such APIs.
Furthermore, here is a related discourse with GNOME contributors where @jadahl mentioned that a separate API might be more suitable for such use cases. I agree that might be a possible (and only?) solution under certain constraints but just wanted to get a feel of what the xdg-desktop-portal community thinks of such use cases.
The text was updated successfully, but these errors were encountered:
Today most of the portals require user interaction to grant permissions for an app to access the resources on the system. This security model makes sense when the user is present on the machine and can allow/deny whatever resources they deem appropriate but this is less than ideal for the case when the user is not directly present on the machine e.g. I am working on adding support in Chrome Remote Desktop (CRD) to access wayland based host using the screencast/remote desktop portals, however, this works well when only when the user is solicing remote support and is present on their machine to interact with the dialogs. This approach doesn't work when, say, I am trying to login to my own machine remotely using CRD.
In this FR, I am requesting a security framework for programmatically granting permissions to privileged processes that try to access the portal APIs. I believe this is somewhat supported for flatpak applications using the manifest file for the applications but would not work for non-flatpak applications that invoke desktop-neutral APIs e.g. screencast/remote desktop portal APIs. It will be nice to have a mechanism to configure permissions per process/app about which portal APIs can be called by them without having a dialog appear on the screen. These permissions can potentially be configured by privileged users/groups on the system and potentially be backed by the permissions store. A variation of this idea is implemented here where the user has to select streams once and remember them for future. I propose to build further on this approach and have a promptless access to portal APIs where feasible as well as by generalizing this by building a framework that works for all the portal APIs, we can be better future proof e.g. when these clipboard APIs are implemented, we should only have to do little configuration to support programmatic access to such APIs.
Furthermore, here is a related discourse with GNOME contributors where @jadahl mentioned that a separate API might be more suitable for such use cases. I agree that might be a possible (and only?) solution under certain constraints but just wanted to get a feel of what the xdg-desktop-portal community thinks of such use cases.
The text was updated successfully, but these errors were encountered: