Canmove, confirm
1,220
edits
Changes
m
== Summary ==
===Core Principles===
#User control: Users control what application permissions an application has at all times (pre, during and post installation).
#Secure by default: A user who chooses to accept the default permissions recommended by a store must be secure by default
#Least Privilege: Applications must be granted the minimum privileges necessary to function
#Minimize Permissions: APIs should be designed in such a way to provide the most functionality without the need to be granted permissions
===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.
===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.
===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
===Trust Model===
#The user is the root source of trust for permissions settings.
#B2G devices will be shipped with a root Trusted Store which has the power to set the permissions defaults for an Web App.
#The user can choose to override these permissions (either granting or revoking privileges), but by default the permissions should be safe for the user, and represent the minimum permissions the application needs to run.
=== Security Requirements for Critical App Deployment ===
Still under heavy discussion. (Trusted Stores, Code Signing etc)
*Which permissions will be classed as sensitive
*What will the minimum bar be
** Trusted App Host?
** Code Signing?
** Both? Something Else?
*Will there even be a separate set of requirements, or will threats be mitigated by App Store processes instead?
no edit summary
* Track the status of [[B2G_App_Security_Model/Threat_Model]]
* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]
== Summary ==
===Core Principles===
#User control: Users control what application permissions an application has at all times (pre, during and post installation).
#Secure by default: A user who chooses to accept the default permissions recommended by a store must be secure by default
#Least Privilege: Applications must be granted the minimum privileges necessary to function
#Minimize Permissions: APIs should be designed in such a way to provide the most functionality without the need to be granted permissions
===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.
===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.
===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
===Trust Model===
#The user is the root source of trust for permissions settings.
#B2G devices will be shipped with a root Trusted Store which has the power to set the permissions defaults for an Web App.
#The user can choose to override these permissions (either granting or revoking privileges), but by default the permissions should be safe for the user, and represent the minimum permissions the application needs to run.
=== Security Requirements for Critical App Deployment ===
Still under heavy discussion. (Trusted Stores, Code Signing etc)
*Which permissions will be classed as sensitive
*What will the minimum bar be
** Trusted App Host?
** Code Signing?
** Both? Something Else?
*Will there even be a separate set of requirements, or will threats be mitigated by App Store processes instead?
== Definitions ==
* '''WebApp''' - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content
# Permissions should be enforced regardless of version of B2G installed
== Proposals ==
