User talk:Ptheriault

Introduction

Motivation

Currently all web functionality is provided in an untrusted model. Any API function that is to be made available to web content must be designed in such a way that it cannot be abused by potentially untrusted content, which often means limiting the flexibility or features of an API. A permissions model is required to define the requirements needed to trust web content with more powerful functionality and also to define the process for granting and managing permissions to use this functionality.

Instead of treating all content as untrusted, web apps can become trusted by virtue of being installed from trusted marketplaces.

Definitions

• Untrusted Web App: This type of Web App is essentially a bookmark, with slightly elevated privileges granted by default. No extra permissions can be granted to this type of Web App, and it can be installed from anywhere.
• Trusted Web App: The majority of Web Apps will be trusted Web Apps installed from a trusted marketplace. This level of Web App is the equivalent of Apps for other mobile platforms. Permissions are granted to these Web Apps at install time, but can be modified by the user as part of the install process (or at any time later while the App is still installed).
• Certified Web App: These Web Apps are highly trusted Web Apps which likely ship with the device, or could be attained through a very limited number of stores (e.g. only the carrier or the Mozilla). Permissions for certified Apps cannot be modified, as they are necessary for the function of the device.

Principles

In designing this permissions model, the following principles have been followed:

• User control of permissions: The user must be empowered to control the permissions granted to Web Apps
• Protected from bad choices: Protect users from granting dangerous permissions or revoking essential ones.
• Secure by default: Users must also be secure by default – if they choose not to manage permissions, and rely solely on marketplace for permission recommendations, their device must still be secure.
• Security decisions made at appropriate times: timing plays an important role is security decisions – a user may be comfortable sharing certain information at one time, but not at others. In other cases, the user may want to grant a permission to an application forever, and not bothered by repeated prompts.
• Least privilege: applications should only be granted the permissions they need to perform the task they are developed for.
• Strength of permission correlates to risk : The more powerful an API is, and thus the higher risk associated with it, the stronger process for granting this permission must be

Challenges

• Avoid dialogue fatigue: over prompting users is a bad user experience, and leads to insecure behavior. Security decisions need to be timely, but avoid overly burdening users with security decisions.
• Simple model so users clearly understand implications of granting permissions. Too many permissions and the model is too complicated, too few and the user is no longer in control (apps have either all or nothing access, and granularity is not appropriate)
• Avoid forcing users to grant permissions as a pre-requisite for app installation: UI for granting permissions should not allow websites to bludgeon the users into granting permissions (this behavior should lead to the user not wanting to use the application)

Web App Security Categories

Web Apps fall into three security categories: Installed, Trusted and Certified Web Apps.

Untrusted Web Apps

An Installed Web App is one that is installed from anywhere – the user has chosen to trust this page as a Web App, but no additional security requirements are placed on the Web App provider. As such, the only limited additional features are available Installed Web Apps, and they cannot be granted specific permissions, beyond a basic few that allow for a better user experience without increasing risk. User experience: “bookmark to desktop/homescreen” style experience distinct from Web App experience. No installation dialog. Permissions: Granted very basic permissions to allow for a more “App-like” experience. No additional permissions can be granted beyond what is available to a regular web page. Installation: Any marketplace , or web apps can self install from their own website. Security Requirements: None. All APIs provided to this level of application must be implemented defensively to protect user even if this content turns out to be malicious

Trusted Web Apps

A Trusted Web App is one that is installed from a trusted marketplace. The marketplace has a contract with the web app provider, and certain security requirements must be in place for these applications. User experience: App like installation experience (visit a store, install an App). Permissions: Permissions levels set at install time. Any permission that is to available to a trusted Web App must be granted prior to launch. Use of an API feature may still require user consent at runtime, depending on the level of permission set. Installation: Installation from a Trusted Marketplace Security Requirements: TBD. Enough to mitigate risks of APIs associated with this permission level.

Certified Web Apps

Certified Web Apps will most likely ship with the devices themselves or be installed through a very limited number of stores (maybe only the carrier, or possibly the Mozilla store) User experience: The user would rarely if ever install a certified app. Installation would be similar to Trusted App case expect that permissions can not be modified. Permissions: Permissions levels set at install time and can not be modified to protect the user. Installation: Installation from a Marketplace which is Trusted by the device to install certified Web Apps Security Requirements: Very strict requirements. Completely offline apps, with code authentication and integrity controls.

Permissions

Permission Types

How permissions are implemented vs. how they are conveyed to the user? Maybe group permissions by Application roles ? List of permissions:

• Browser
• Camera
• Etc…

Permission Levels

[unsure about this section, but even if permissions are binary, I think we need to support these four user experiences]

The are four levels of permission which can been granted, either allow, prompt on first use, prompt always or deny.

• Allow: Always allow this permission to the application. A notification may be provided to the user that the permission is in use, but explicit user permission is not required.
• Prompt on first use: This Web App has been registered to require this permission, however the user must be prompted before granted access to this permission. The platform can provide a mechanism to remember this decision, in which case the permission is elevated
• Prompt Always: This Web App has been registered to require this permission, however the user must always be prompted before granted access to this permission.

Granting Permissions

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 is informed of the permissions during installation, and can modify them if desired, or choose to trust the defaults set by the App Store. If the App is a certified App, then the permissions can not be modified by the user. Permissions Granted by Marketplaces In order to gain permissions, an application must be installed from a trusted marketplace. The process for a Web App to gain permissions is as follows:

1. Web App specifies the permissions it would like in its manifest file
2. Manifest added to a marketplace
3. And then?????

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)

Trust Model

Trusted Model

1. The user is the root source of trust for permissions settings. 2. B2G devices will be shipped with a root Trusted Store (or several) which has the power to set the permissions defaults for an Web App. 3. The user can choose to override store permissions (either granting or revoking privileges), but the store permissions should be safe for the user, and represent the minimum permissions the application needs to run. 4. The store can also entrust other stores with the power to grant permissions (possibly a subset of permissions, or not privileged permissions)

Certified Model

1. The marketplace is the root source of trust for permissions settings. 2. B2G devices will be shipped with a root Certified Store (or several)

Trust Model Questions

Is there way for a user to add a Trusted store? (In a sense the answer is always yes, but how difficult will it be from a scale from jail breaking to through to a UI provided mechanism) This is out-of-scope of for the permissions model though, and relates more to the business model of partners.

Future Goals

Requirements Out of Scope for Version 1.0 Ability for users to add trusted application stores Ability for the user to add arbitrary permissions to an application Ability for the user to install trusted application directly from application providers