Difference between revisions of "Permission Service"
DougReeder (talk | contribs) (Rationale, Service, DB, Best Practice) |
m (→Best Practice Use: correct typo) |
||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == Rationale == | |
Permissions in webOS were fragmented. Some were granted via the app manifest, others at run time. There was no mechanism for a user to revoke them. | Permissions in webOS were fragmented. Some were granted via the app manifest, others at run time. There was no mechanism for a user to revoke them. | ||
| + | Users tend not to pay attention to permissions granted at installation time. | ||
| + | == Implicit Permissions == | ||
| + | Some actions don't need to interact with the Permission service. Any app can invoke the People Picker, but the app will only get info about the one contact the user selects (or no contacts if the user cancels). | ||
| − | + | == Service == | |
| − | A new service would manage | + | A new service would manage app permissions. A service like geolocation could query the permission service, which would check the DB. If the permission had been previously granted, the permission service would immediately return that. If previously denied, immediately return that. |
If no permission value was stored, the permissions service would put up a system popup asking whether to grant the permission once, always, never, or just close (the dialog). | If no permission value was stored, the permissions service would put up a system popup asking whether to grant the permission once, always, never, or just close (the dialog). | ||
* once: return true, nothing stored in DB | * once: return true, nothing stored in DB | ||
| Line 11: | Line 14: | ||
* close: return false, nothing stored in DB | * close: return false, nothing stored in DB | ||
| − | + | == Database == | |
| − | |||
The system permissions database would be managed solely by the permissions service. | The system permissions database would be managed solely by the permissions service. | ||
This would be a kind in DB8 with fields for | This would be a kind in DB8 with fields for | ||
| − | * the service that would actually do the thing, such as geolocation | + | * grantor: [string] ID of the service that would actually do the thing, such as geolocation |
| − | * privilege | + | * privilege: [string, upper-case, snake-case] what the permission is for, such as "LOCATION", "READ", "CREATE", "DELETE", or "MODIFY" |
| − | * client app/service | + | * privilege_desc: [object] localized descriptions of the privilege, for example {en: "know your location", de: "wissen Ihren Standort"} |
| − | * | + | * client: ID of the requesting app/service |
| + | * type: "BOOLEAN"; an integer range represented by an array with two elements; or an enumeration represented by an object with localization strings, for example {READ: {en: "Read", de: "Lesen"}, WRITE: {en: "Write", de: "Schrieben"}} | ||
| + | * value: according to the type above, either a boolean, number or string | ||
| + | |||
| + | == System UI == | ||
| + | In addition to the system popups mentioned above, there should be a pane for each app, evoked from the Launcher via a tap-and-hold or double-tap. | ||
| + | It might be a system popup, or something else. | ||
| + | The pane would list app title, vendor, vendor URL and app version. | ||
| + | The pane would list all permissions, and which are granted. | ||
| + | The user could grant or revoke permissions, or set the value of enumerated or numeric permissions. | ||
| + | Deleting an app might also be done from this pane. | ||
| − | + | == Best Practice Use == | |
| − | Best practice | + | Best practice is to ask in a context where the relationship between the permission and the user’s goal is clear; *not* at install time. |
| − | For example, in Serene Notes running in a web browser, when the user first enables the application preference “Tag new notes with location”, it makes a call to geolocation and the browser opens a permissions dialog. (Serene Notes doesn't actually *need* location at that point in time, but that | + | For example, in Serene Notes running in a web browser, when the user first enables the application preference “Tag new notes with location”, it makes a call to geolocation and the browser opens a permissions dialog. (Serene Notes doesn't actually *need* location at that point in time, but that triggers the system dialog.) |
Latest revision as of 19:43, 11 November 2015
Rationale
Permissions in webOS were fragmented. Some were granted via the app manifest, others at run time. There was no mechanism for a user to revoke them. Users tend not to pay attention to permissions granted at installation time.
Implicit Permissions
Some actions don't need to interact with the Permission service. Any app can invoke the People Picker, but the app will only get info about the one contact the user selects (or no contacts if the user cancels).
Service
A new service would manage app permissions. A service like geolocation could query the permission service, which would check the DB. If the permission had been previously granted, the permission service would immediately return that. If previously denied, immediately return that. If no permission value was stored, the permissions service would put up a system popup asking whether to grant the permission once, always, never, or just close (the dialog).
- once: return true, nothing stored in DB
- always: return true, store true in DB
- never: return false, store false in DB
- close: return false, nothing stored in DB
Database
The system permissions database would be managed solely by the permissions service. This would be a kind in DB8 with fields for
- grantor: [string] ID of the service that would actually do the thing, such as geolocation
- privilege: [string, upper-case, snake-case] what the permission is for, such as "LOCATION", "READ", "CREATE", "DELETE", or "MODIFY"
- privilege_desc: [object] localized descriptions of the privilege, for example {en: "know your location", de: "wissen Ihren Standort"}
- client: ID of the requesting app/service
- type: "BOOLEAN"; an integer range represented by an array with two elements; or an enumeration represented by an object with localization strings, for example {READ: {en: "Read", de: "Lesen"}, WRITE: {en: "Write", de: "Schrieben"}}
- value: according to the type above, either a boolean, number or string
System UI
In addition to the system popups mentioned above, there should be a pane for each app, evoked from the Launcher via a tap-and-hold or double-tap. It might be a system popup, or something else. The pane would list app title, vendor, vendor URL and app version. The pane would list all permissions, and which are granted. The user could grant or revoke permissions, or set the value of enumerated or numeric permissions.
Deleting an app might also be done from this pane.
Best Practice Use
Best practice is to ask in a context where the relationship between the permission and the user’s goal is clear; *not* at install time. For example, in Serene Notes running in a web browser, when the user first enables the application preference “Tag new notes with location”, it makes a call to geolocation and the browser opens a permissions dialog. (Serene Notes doesn't actually *need* location at that point in time, but that triggers the system dialog.)