Install-time & Startup Permissions

[GeorgesStavracas]

This is a follow up from a discussion in Matrix. The subject of the discussion is when and how apps should request permissions they use.

Problems

1. Some apps know ahead of time that they'll need certain permissions. Is it worth preemptively requesting these permissions on behalf of the app at install time? Say, for example, the app store showing a permission granting dialog.
2. Apps might want to request multiple permissions. Currently, the only way to do that is to request each permission individually. In all known portal implementations, this means multiple dialogs presented sequentially. This interaction likely leads to people mindlessly granting permissions!

Constraints

• Not all permissions can be granted ahead of time. For example, screencasting only allows restoring previously created sessions.
• Some permissions might need extra data to them. For example, the permission to run in background may also include the ability to launch the app at startup time.

Concrete Cases

Case 1: Liveblast

Liveblast is a streaming app that requires access to camera, microphone, and screencast. These are accessed during the app's startup. To avoid carpet-bombing people with permission requests right on startup, it shows an onboarding dialog where each permission is granted individually and explicitly:

Case 2: Flameshot

Flameshot is a cross-platform app that has a rather unique behaviour, which may come as a surprise to many people that aren't already familiar with how it works. When you launch the Flatpak app, nothing visible happens - the Flameshot daemon starts, but no visual indicator is shown. People have to either launch it from the command line ($ org.flameshot.Flameshot gui), or
right click the icon and launch one of its specific actions.

The main point of Flameshot is that it does not show a window while it is taking a screenshot. This behaviour evidently serves a purpose - the app cannot modify the contents of the screenshot by presenting a window.

This behaviour is problematic right now because, as a convenience and security measure, GNOME rejects permission requests from apps without a visible and focused window.

Relevant Art

Android

Android provides a way for apps to request permissions at install time:

Android merges multiple requests in a paginated dialog:

iOS

TODO

[snwh]

In both these cases (either at install time or startup) apps asking for multiple permissions at once time seems to be an eventual need. From my point of view on the design side, two big things need to be avoided when going down that route:

1. Successive dialogs spawning for multiple permissions.
2. People just clicking "accept all" on a dialog that groups permissions.

As far as I am aware, applications on iOS simply spawn one dialog after another for each permission, this does have the upside that users will engage with each permission request however the downside is that as an interaction dealing with multiple dialogs one-after-the-other isn't super ideal.

The Android examples above show 2 cases where multiple permissions are grouped. The drawback of grouping (especially as in the Snapchat example) is that the Accept action is pretty prominent and there is next to no disclosure of the permissions needs leading to people just hitting accept, which isn't great for security and user awareness of what each permission allows.

The paginated dialog, is probably the most interesting approach here since it requires people to engage with each permission before moving onto the next, but this is not an existing UI pattern (at least on GNOME).

A solution here I think needs to consider balancing disclosure (what permission and why) and not requiring too many interactions to process that information.

[Mikenux]

The problem with the paginated dialog is that if it is based on allow/deny permissions, then there is a risk that users will successively click Allow.

At least for devices (maybe also screens for screencasting), a setup experience where we select devices (one device category per page) and then click "Next" might be better. More clicks, but better and familiar in my opinion, as apps tend to have device source selectors in their interfaces (selecting audio and video sources, selecting which camera and microphone to use) . Note that in a chat case, the camera and microphone selection could be on the same page (maybe users prefer to select a webcam but a different microphone than the webcam).

[allanday]

I feel like I need an overview of this problem space. It would be cool to have a table of all the portals, with examples of when each one might be used and a note on when the best time to ask the user would be. The latest GNOME mockups might be a useful reference.

[snwh]

This portals demo is helpful here: https://flathub.org/apps/com.belmoussaoui.ashpd.demo

[allanday]

I've done that quick review of the portals and their use cases. It seems to me that it's a bit of a mixed bag with regards to when we should present a permission dialog:

1. Examples of portals which only ever make sense to ask at the point of use, on a one time basis:
   • Setting a wallpaper from an image viewer
   • Opening a file in a text editor
   • Sharing the screen with a video conferencing app
2. Examples of portals where asking permission at install time or on first run always makes more sense:
   • Flameshot being able to take screenshots
   • Barrier having access to input devices
3. Examples of portals where it we could show the permission dialog on first run or when the feature is used for the first time:
   • A sync app having permanent access to its own directory
   • When changing the directory that a photo manager app has permanent access to
   • A maps, camera, weather, or messaging app asking for access to location

For 3 we could make all those portals always ask on first run or install time, and accept that in some cases it's sub-optimal. One risk here is that the purpose of the permission could be unclear (like a messaging app wanting your location for a "share my location" feature).

Another thing that I discovered from my quick review is that most apps realistically only have 1 or 2 permissions. The main examples of apps with many permissions are messaging clients and camera apps.

[Mikenux]

A sync app having permanent access to its own directory

Could you tell what "own directory" means? As far as I know we are adding files or directories to sync, so what is this directory?

[Mikenux]

Ok, I forgot that there is the directory to see the synced files/folders in the file manager.

[jadahl]

Is it worth preemptively requesting these permissions on behalf of the app at install time?

I don't think this is achievable without handling the exact same permission granting the first time the app is run due to the fact that apps might be installed on a system level by e.g. a sysadmin, and/or pre-installed by the operating system. In these two cases any install time querying means the user has no chance to deal with these permissions themselves.