Security/B2G/PermissionReview/New permission model: Difference between revisions

Security/B2G/PermissionReview/New permission model (view source)

Revision as of 05:43, 1 June 2015

93 bytes added , 1 June 2015

fixed formatting

Ptheriault

canmove, Confirmed users

1,220

edits

@@ Line 29: / Line 29: @@
 |}
-Web Permissions
+=== Web Permissions ===
 “Permissions” are defined are the permissions available to all content. The characteristics of web permissions are:
-generally granted by the user at first use, usually through prompting
+* generally granted by the user at first use, usually through prompting
-Are NOT required to be declared in an application manifest (declaring these permissions will be allowed to provide backwards compatibility).
+* Are NOT required to be declared in an application manifest (declaring these permissions will be allowed to provide backwards compatibility).
-permissions are generally granted via prompt at runtime, upon first API call.
+* permissions are generally granted via prompt at runtime, upon first API call.
-some permissions require additional UX for risk mitigation (e.g. storage & alarms need a way for the user to manage them - i.e. managed disk usage, review/delete alarms
+* some permissions require additional UX for risk mitigation (e.g. storage & alarms need a way for the user to manage them - i.e. managed disk usage, review/delete alarms
-provide a way for users to see apps which consume large amounts of storage
+** provide a way for users to see apps which consume large amounts of storage
-provide a way for users to see when alarms are set, mitigate the risk of web pages waking you up on the middle of the night, or showing ads repeated with alarms
+** provide a way for users to see when alarms are set, mitigate the risk of web pages waking you up on the middle of the night, or showing ads repeated with alarms
-Privileged Permissions
+=== Privileged Permissions ===
 Privileged permissions are an additional set of permissions which signed content can request, after going marketplace review. Because privileged content is no longer installed, this limits what is safe to expose.
-“Privileged Permissions” are:
+Privileged Permissions are:
-restricted to signed FxOS content
+* restricted to signed FxOS content
-must be declared in manifest
+* declared in manifest
-permissions are no longer granted at install (no install process)
+* permissions are no longer granted at install (no install process)
-granted by prompt after the app content first loaded (assuming app signature verification passes)
+* granted by prompt after the app content first loaded (assuming app signature verification passes)
-Certified Permissions
+=== Certified Permissions ===
 All other permissions are certified. Certified permissions will now be available to installed add-on content. However not all certified permissions are safe to expose. We will need to come up with marketplace policy for granting permissions on a per-app basis.
 “Certified Permissions” are:
-Available to “installed” content only (i.e addons)
+* Available to “installed” content only (i.e addons)
-Controlled by marketplace policy rather than
+* Access to certain APIs may be limited to partner apps only (TBD)
-Open Issues
-Existing privileged permissions are too dangerous
+=== Open Issues ===
-data APIs need to be made more safe (one wrong click and you lose all your photos?)
+* Existing privileged permissions are too dangerous
-network APIs are implicit (not prompted). We need to make these APIs safer, or figure out a stronger review process to mitigate risk of abuse
+* data APIs need to be made more safe (one wrong click and you lose all your photos?)
-Certified permissions will need to be regulated by marketplace,not all permissions will be grantable to 3rd parties. Need to determine policy for  which permissions will be allowed and under what circumstances.
+* network APIs are implicit (not prompted). We need to make these APIs safer, or figure out a stronger review process to mitigate risk of abuse
-Can we trust marketplace to be enforcer of what apps can get permissions? Where will we track the permissions matrix (PermissionsTable.jsm is the source of truth for permissions mappings at the moment, where will it be in the future)?
+* Certified permissions will need to be regulated by marketplace,not all permissions will be grantable to 3rd parties. Need to determine policy for  which permissions will be allowed and under what circumstances.
-Are there still any APIs that have to run in system app/parent process (embed-webapps, open-remote-window)? How can we enforce this?
+* Can we trust marketplace to be enforcer of what apps can get permissions? Where will we track the permissions matrix (PermissionsTable.jsm is the source of truth for permissions mappings at the moment, where will it be in the future)?
-ISSUE: Many APIs are currently restricted by App type rather than a permission. This includes (not complete list):
+* Are there still any APIs that have to run in system app/parent process (embed-webapps, open-remote-window)? How can we enforce this?
-DOM APIs guarded by [AvailableIn=CertifiedApps] in WebIDL (with no permission check)
+* ISSUE: Many APIs are currently restricted by App type rather than a permission. This includes (not complete list):
-Inter-app communication API
+** DOM APIs guarded by [AvailableIn=CertifiedApps] in WebIDL (with no permission check)
-Datastores API
+** Inter-app communication API
-navigator.mozResendAllNotifications
+** Datastores API
-Issue: Privileged permissions granted by user are revocable. If we keep current model, users could revoke permissions from Gaia apps, breaking them. (See below for more details)
+** navigator.mozResendAllNotifications
+* Issue: Privileged permissions granted by user are revocable. If we keep current model, users could revoke permissions from Gaia apps, breaking them. (See below for more details)