Commit a8a8babe authored by Simon McVittie's avatar Simon McVittie

Add use cases for (not) granting permission at time of use

Apertis: Simon McVittie's avatarSimon McVittie <>
Reviewed-by: Emanuele Aina's avatarEmanuele Aina <>
Differential Revision:
parent eb50088f
......@@ -362,6 +362,52 @@ actions.
[iOS] does not appear to provide this functionality to third-party app-bundles.
### Granting permission on first use
The author of a hotel booking app-bundle includes a feature to locate nearby
hotels by using the Apertis geolocation API. Because
[users are more likely to grant permission to carry out privacy-sensitive
actions if they can understand why it is needed][Permissions on-demand],
the app author does not want the Apertis system to prompt for access
to the geolocation feature until the user actively uses that particular
#### Not granting permission on first use
Conversely, an automotive vendor wishes to minimize driver distraction in
order to maximize safety. When the same hotel booking app-bundle attempts
to use geolocation while the vehicle is in motion, the platform vendor
might want the Apertis system to **not** prompt for access to the
geolocation feature, contrary to the wishes of the app author. Instead,
the user should be given the opportunity to enable geolocation at a time
when it is safe to do so, either during app-bundle installation or as a
configuration/maintenance operation while the vehicle is stationary at
a later time.
Note that those two use cases have contradictory expectations: this is a
user experience trade-off for which there is no single correct answer.
#### In other systems
[iOS] prompts for permission to carry out each privileged operation at
the time of first use.
[Flatpak] mostly does the same, but with some pragmatic exceptions:
lower-level permissions, such as access to direct rendering devices for
3D games or direct access to the host filesystem, are implemented in a
way that precludes that model. These are set up at installation time, and
can be overridden by user configuration. When a Flatpak app is launched,
it is given the level of access that was appropriate at launch time.
[Android] 6.0 and later has the same behaviour as iOS.
Older Android versions configured all permissions at installation time,
with a simple UX: the user must either accept all required permissions,
or abort installation of the app. Some permissions, notably access to
shared storage (the real or emulated SD card), were implemented in a way
that precluded runtime changes: app processes with access to shared storage
ran with one or more additional Unix group IDs, granting them DAC permission
to the appropriate areas of the filesystem.
### Tightening control
Suppose that Apertis version 1 allows all app-bundles to query the vehicle
......@@ -1088,6 +1134,7 @@ Usage descriptions not corresponding to a use-case in this document include:
[Permissions on-demand]:
[The Flatpak security model, part 3]:
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment