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

Apertis: https://phabricator.apertis.org/T3515Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Emanuele Aina <emanuele.aina@collabora.co.uk>
Differential Revision: https://phabricator.apertis.org/D6384

docs/permissions.md

@@ -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
+feature.
+
+#### 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:
 [mq_overview(7)]: https://manpages.debian.org/mq_overview(7)
 [NSBluetoothPeripheralUsageDescription]: https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW20
 [NSSupportsAutomaticTermination]: https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW13
+[Permissions on-demand]: https://savvyapps.com/blog/how-to-create-better-user-permission-requests-in-ios-apps
 [svipc(7)]: https://manpages.debian.org/svipc(7)
 [The Flatpak security model, part 3]: https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/
 [UIBackgroundFields]: https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW22