Difference between revisions of "Permission Service"

From WebOS-Ports
Jump to: navigation, search
(Rationale, Service, DB, Best Practice)
 
(added System UI)
Line 1: Line 1:
'''Rationale'''
+
== 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.
  
  
'''Service'''
+
== Service ==
 
A new service would manage all 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.
 
A new service would manage all 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).
Line 12: Line 12:
  
  
'''Database'''
+
== 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
Line 18: Line 18:
 
* privilege (what the permisson is for, such as location),  
 
* privilege (what the permisson is for, such as location),  
 
* client app/service ID
 
* client app/service ID
* value: typically true/false. If needed, it could have numerical values (for example, quota or string constants, but that would require additional API)
+
* value: typically true/false. If needed, it could have numerical values (for example, quota or string constants) but that would require additional API.
  
  
'''Best Practice Use'''
+
== 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.
 +
The pane would list all permissions, and which are granted.
 +
The user could grant or revoke permissions.
 +
 
 +
 
 +
== Best Practice Use ==
 
Best practice to to ask in a context where the relationship between the permission and the user’s goal is clear; *not* at install time.
 
Best practice to 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 trigger the system dialog.)
+
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.)

Revision as of 06:25, 9 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.


Service

A new service would manage all 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

  • the service that would actually do the thing, such as geolocation
  • privilege (what the permisson is for, such as location),
  • client app/service ID
  • value: typically true/false. If needed, it could have numerical values (for example, quota or string constants) but that would require additional API.


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. The pane would list all permissions, and which are granted. The user could grant or revoke permissions.


Best Practice Use

Best practice to 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.)