Confirm
717
edits
Changes
→Permissions and privileges
Note that privileged and certified apps have their own unique origin via the app:// scheme.
==Permissions and privileges== ===Permission prompting mechanisms===UX is currently developing detailed mockups that will be ready to ready to review shortly. The overall flow will be:* All permissions prompts are at runtime, at the time of the corresponding API request* User can review permissions which may be requested at install time via a pulldown, but cannot set them* Implicit permissions for each application type are not visible or user controllable (classified as low-risk)* Permissions for high risk APIs are prompted for at runtime with a corresponding rationale (data usage intention) for the request* Permissions that could compromise This sections describes the system are available only to certified apps and therefore never prompted for * Full details of implicit vs explicit permissions permission model for each WebAPI are available here: https://wiki.mozillaapplications.org/WebAPI
=== Extended permissions ===
}
}
=== Privileged-app-only Permissions ===
Some permissions are sensitive enough that we don't want to just hand them to any app. For example a permission which enables pages to read or modify pictures from the users picture folder is very sensitive. For such an API we in addition to requiring the app to enumerate the permission in the app manifest, require that the app is a "Privileged App". See details about this in the section for Privileged Apps below.
=== Prompting Permission Prompts ===
Just because a permission is enumerated in the manifest doesn't mean that an app will be automatically granted that permission at time of installation. For many APIs, like the wifi-information API, enumerating the permission in the manifest simply means that the app can attempt to use it. When used, the user will be prompted and asked if it's ok to grant the permission to the app. During this prompt, the description provided in the manifest will be displayed to the user. However it will be displayed in such a way that it is clear that the description comes from the app developer, and not from B2G itself.
The overall flow will be:
* All permissions prompts are at runtime, at the time of the corresponding API request
* User may be able to review permissions which may be requested at install time via a pulldown, but cannot set them
* Implicit permissions for each application type are not visible or user controllable (classified as low-risk)
* Permissions for high risk APIs are prompted for at runtime with a corresponding rationale (data usage intention) for the request
* Permissions that could compromise the system are available only to certified apps and therefore never prompted for
* Full details of implicit vs explicit permissions for each WebAPI are available here: https://wiki.mozilla.org/WebAPI
=== Implicit access ===
Not all permissions will result in the user getting prompted when the permission is first used. In some cases it's very hard to describe to the user what granting the permission means.
In this situation we can't rely on the user to make the security decision. Instead we will have to rely on a technical code-review of the app before it is published in a store to ensure that the app doesn't do anything it shouldn't with the extended permission. See the "Trusted Privileged apps" section below above for how this works.
In this situation access is granted implicitly at install time.
