** Following Stephen's recommendation would allow the creation of very special permissions that are specifically relevant to B2G, for proper enforcement at the Linux Kernel level.
= {{:App/Security/Permissions Definitions and Presentation =}}
This section discusses the actual permissions to be enforced, how and what should be presented to the user, including the management, and the implications at the application level (if permissions are or are not granted)
== Scope ==
===Permission Types===
#For privacy-related permissions, the user must always be asked, unless they have overridden
#Permission values:
##Deny
##Prompt (default to remember)
##Prompt (default not to remember)
##Allow
#List of Permissions: TBD
(''comment: these permission types are not really a summary, and as such should be moved to a suitable section'')
===Process for granting permissions===
#By default all Web Apps have the no special permissions, the same as any other web page.
#A Web App requests permissions in the manifest when submitting to a store (an application may only be granted permissions that it requests in the manifest)
#An App Store can grant permissions to a Web App during the install process (but not necessarily all of the requested permissions
#The user’s default permission policy is applied to the requested permissions (see permissions management) and requested permissions are updated
#The user is informed of the permissions during installation, and can modify them if desired, or choose to trust the defaults set by the App Store.
Note: If sensitive permissions are requested, certain security requirements may be placed on the application.
(''comment: this section appears to be in discussion or proposal form, not a summary form. as such it should be moved to a suitable section'')
=== Types of Runnables ===
The scope of the permissions model is limited to Open Web Apps, which are applications written web technologies (HTML, JS, CSS).
These are the only applications which are installed on B2G, "the web is the platform", there are no user-installable native apps.
There are multiple layers of applications underneath these web apps, which make up the B2G OS, but these are beyond the scope of the permissions model. It is noted however that the permissions model might influence the design of lower layers: for example, ideally Web Apps of differing permission levels would be sandboxed to limit the impact of memory corruption vulnerabilities. For further detail on the underlying B2G architecture see: [[B2G/Architecture]]
== Requirements ==
=== Management / granting of API permissions to WebApps ===
# User should be able to view / control / modify permissions granted to WebApps
# WebApps should fail gracefully if not all permissions granted
# User should have control over APIs with privacy implications
# User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)
# Apps must not request permission to do something or use a function that it has not declared that it needs to do. ('''TBD: If an app attempts to execute a function which the user has not authorised, what action should be taken? terminate the app? remove it? report it?''')
discussion links:
# https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE
===Management of Permissions===
#A user can modify the permissions granted to a Web App at any time including granting or revoking privileges
#Permissions can be granted per application, or set globally in the Default Permission Policy (see below)
#Users need to be guided on the consequence of changing permissions, and protected from making choices which are insecure or which could disable their device (e.g. removing the permissions setting capability from the permissions web app)
#Permissions can be modified either through a permission manager application, or set through contextual actions (e.g. response to security prompts including "remember me" checkboxes or through behavior in some cases, e.g. user ignores a prompt five times in a minute, don't prompt again for an hour)
===Default Permission Policy===
Each B2G device has a default permissions policy which takes precedence over the app store. This is expected to contain rules for a subset of permissions.Its purpose is:
*for device manufacturers to set safe default limits for permissions
*for users to decide on global limits for permissions
For example, a default setting for location might be that even apps, which are granted access to location, must always ask the user. This could modify this policy to be more strict, and globally deny applications from accessing location information.
A user should be warned before they override the Default Permission Policy in an unsafe way.
=== Required Application Permissions ===
This section lists the actual permissions that are required to be enforced (at the Operating System Level)
* Full-screen mode
* Phone Access
** Emergency Services
** Ordinary calls
** Premium Rate numbers (?)
* SMS
* GPS
* EMEI Number
== Proposals ==
=== Permissions manager ===
* User can deny permissions at install time
* User can always go to manager to see what permissions an app has been granted
* User can modify permissions through the manager
* Certain APIs are defined as "sensitive"
** Sensitive APIs will request "capabilities" e.g. access USB, access wifi
* Levels of access for capabilities
** Allow
** Prompt (default to remember)
** Prompt (default to not remember)
** Deny
*** There were concerns that the levels should only be Allow/Deny
* Contractual enforcement of permissions
** WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs
** Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions
* WebApps may be granted default permissions
** e.g. access to storage, access to change context menu
* capabilities may be restricted based on technical restrictions of the site
** e.g. strict-transport security, EV-certificate
= Standard web security =
