Confirm
717
edits
Changes
→Permissions and privileges
* 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
=== Extended permissions ===
Applications can be granted additional privileges on top of the ones granted to normal websites. By default an application has no permissions on top of the ones normal webpages have. In order to get additional permissions, the first step is for the app to enumerate the additional permissions it wants in the application manifest.
For each additional permission that an app wants, the manifest has to explicitly enumerate that permission along with a human-readable description of why the app wants access to that permission. This description will be surfaced at various points in the UI, and is also used when the app is reviewed.
An example of a fragment of a manifest:
permissions: {
browser: {
description: "To enable showing web pages";
};
"wifi-information": {
description: "To alert you about unencrypted wifi networks in your area";
}
}
=== 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 ===
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.
=== 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 apps" section below for how this works.
In this situation access is granted implicitly at install time.
''Open question'': Should we enable users looking at the list of prompted and implicit permissions at the time of installation?
=== <code>access</code> property ===
For some APIs there is an additional "access" property which allows specifying if the app wants read, write or create access. This looks like:
permissions: {
contacts: {
description: "To find friends to send your awesome high-scores to.";
access: "readwrite";
};
}
Valid values for the access property are:
* "readonly": Ability to read data and be notified about changes to data. No ability to write data at all.
* "createonly": Ability to create new data. Not read, modify any existing data.
* "readcreate": Ability to read existing data as well as create new data. No ability to modify existing data.
* "readwrite": Full ability to read and modify any data.
In the above, deleting existing data counts as modifying it.
These access levels aren't surfaced to the user at all. They are only there as a level of protection and to help during the code review of the app to determine what they need to look for while reviewing an app. So for example in an app which is requesting "createonly" access to the Contacts API doesn't have to be reviewed to see if it is doing anything unexpected with read contacts information (such as save it to the server without first asking the user), since the app can't ever read contact information.
But even for an app which requests "readwrite" access to the Contacts API, as soon as the app performs a reading or writing operation B2G will prompt the user about permitting access, and if the user grants access, full read and write access will be granted. There is no need for additional prompts assuming that the user checks the "remember this decision" checkbox.
''Open Question'': We could surface in the prompt which of the above four types are being requested. It wouldn't increase the number of prompts that we have, but it would mean having to deal with what happens if the access changes for example from "readonly" to "readcreate" during an update.
===Data Usage Intentions===
