Portal Identification and Manipulation

[Mikenux]

What are Portal Awareness and Manipulation?

Portal identification is the ability to identify the portals used by apps. Portal manipulation is the ability to modify portal permissions.

Portal identification is useful for stores to display portal information to the user, while portal manipulation is useful for administration tools (container systems, server tools, or parental controls) to manipulate portal permissions.

The relevant issues (portal manipulation) are:

• Allow setting default permissions system-wide #471
• [Feature Request] Allow pre-populating permissions for apps that want to access portal APIs #759

Requirements

For Portal Identification

• The app specifies the portal requests it intends to use in its manifest.
• Portal request information includes the portals (name or interface name), methods, and options to use. This information is to be determined for each portal and may be adapted to simplify writing for developers. Examples:
  • Screenshot Portal. The app specifies "screenshot" followed by "interactive=no" or "automatic" for permission to automatically take screenshots. To offer users the choice, it uses "screenshot" followed by "interactive=yes" or "options."
  • Audio Portal (does not yet exist). The app must specify each type of device it wants to access. Example: to access input sources and multiple output sources: audio, capture, output.
  • File Chooser Portal. The app indicates whether it does not need to write to files or whether it intends to write to files with permission (this does not currently exist). An app that does not need write access: file-chooser, read-only. An app that requests permission to write: file-chooser, write-request. An app that needs write access, but cannot manage write access: file-chooser, write.
• This portal information must be understood by the container system and xdg-desktop-portal.
• xdg-desktop-portal must check the manifest when an app makes a request. It blocks any request not specified in the manifest. Instead, the container system could write the necessary permission tables; xdg-desktop-portal would then deny any request for which no permission table exists.

For Portal Manipulation

• A permission to block the use of a portal must be created and understood by the container system, portals, and apps. Apps must receive an appropriate response to handle the absence of a portal window. This specific permission must be determined for each portal. For example, the file chooser can be blocked and the app receives the response that no files are returned.
• The container system must be able to write and modify portal permissions, including blocking, after reading an app's manifest. Changing permissions can be done per app and with global overrides to be applied when apps are installed. Global overrides can be set for all apps, for specific apps, and for specific groups of apps (e.g., collections, repositories). As mentioned above, the container system could itself create the necessary permission tables from an app's manifest; however, it must not be able to create a permission table for a portal not specified in the manifest and must handle updates.
• A suitable API must be available for administration tools to modify permission tables. No API to delete a permission table.

Compatibility

Be careful about compatibility. This new system is intended for newer versions of a container system and portals. Previous versions of these must still be able to handle manifest information.

[Mikenux]

Updates Thread

[Mikenux]

Update 1 - See first edit (Jun 30):

• A little more detail on permission changes.

[Mikenux]

Update 2 - See second edit (Jul 17):

• Added a section on compatibility.