Apps/Security

Open Web Apps Security and Privacy Model

Note: Please do not edit this page. Share your ideas in dev-webapps@lists.mozilla.org or Apps/Security/Discussion instead.

Introduction

The open web application security and privacy model spans a wide variety of use cases, from typical web content to system-critical applications. As such, a one-size-fits-all security model won't work. Instead we need a range of options that balance out the flexibility and common design patterns for web applications while mitigating the additional risks that come with exposing sensitive APIs. Additionally, providing users as-necessary insight into app use of their data helps them make more informed risk/reward decisions as they install apps and grant permissions.

Discussion and Resources

Previous Apps/Security discussion page: Apps/Security/Discussion

List of webAPIs and corresponding security discussions: WebAPI

Foundational principles

• Maintain core strengths and flexibility of the web
• Protect the security and privacy of the user
• Protect the device from poorly written & malicious applications
• With additional privileges come additional responsibilities for the developer and app store
• User choice and control - treat the user with respect and present them with choices that allow them to make informed decisions. See our privacy operating principles [1], specifically "Real Choices."

Definitions

Explicitly granted permissions

Permissions that need to be enumerated in the manifest and require user consent at "time of use" to enable, whether via a prompt or an in-content user mediated UI. The user can also inspect and modify the explicit permissions for any app via the permissions manager. When the user is prompted for explicit permissions, they need to be informed what is requested, why it's requested, and how the app will use data obtained through this permission.

Implicitly granted permissions

Permissions which are enumerated in the manifest and granted to that type of application without requiring any user interaction. The user may be able to inspect, but not modify, the implicit permissions that an app requests via the permissions manager.

Data Usage Intention

Apps can make a commitment to users about their intended uses of data collected through a given API (for which the user is grants a permission). This is a short string that reflects to users what risk might surface by granting an app permission to use the given API. Users can leverage this Usage Intention to decide whether the value provided by the app is worth the risk or not. Usage Intentions are attached to permissions as an annotation of not only why the permission is needed, but what the app will do with the data.

Types of applications

There are 3 types of installed application. In additional, many webAPIs are also exposed to regular web content, so that category is included here for context.

Normal web content

Not a type of application per our definition of installed apps, but part of the WebAPI security continuum and so discussed here.

• No app store involved
• No manifest or installation experience
• No restrictions on origin or transport (i.e. HTTPS not required)
• All explicit permissions are requested at runtime, not persisted by default
• Most permissions requested via web intents

Installed web application

Unauthenticated applications provide a manifest, and can optionally be obtained through an app store.

• No restrictions on transport but limited to one app per origin (though an app may load assets and code from other origins).
• Installation experience with permissions being opt-in at install and runtime, limited to permissions enumerated in the manifest.
• No app store code reviews as they serve no purpose (app can change anytime without user or reviewer consent).
• No SSL indicators, so trust is limited only to content user is willing to share with any website, and maximum privileges are likewise limited to what is available to normal web content.
• All explicit permissions are requested at runtime, showing user the app's data usage intentions, not persisted by default.
• Most permissions requested via web intents
• Same origin enforced

Installed privileged application

Authenticated application approved by an app store. Equivalent in functionality and security to apps on other mobile platforms.

• App is comprised of an explicit list of assets.
• App is approved by app store after a code review or some equivalent risk management process.
• App store signs the app manifest which contains the list of assets and their corresponding hashes.
• At install app assets are verified & remain stored locally in package.
• Require a Content Security Policy to mitigate content injection attacks and maintain application integrity.
• All explicit permissions are requested at runtime, showing user the app's data usage intentions, and persisted by default.
• User can monitor permission state and change app permissions via consistent permission notification UI
• Privileges granted are limited to explicit list of application assets; we must enforce security boundaries between privileged code and any unprivileged content that the app may also load.
• No same-origin restrictions for app content; same origin still enforced for non-app content.

Certified application

This category is reserved for apps that require approval by carrier or OEM due to risk of device corruption or risk to critical functionality. These include apps such as the system settings app, default dialer (to ensure emergency services are always accessible), core radio and power management, etc. Not intended for 3rd party applications. Similar to Privileged apps, except:

• All permissions are implicit.
• User cannot modify permissions (as it could break the device; ex. disable settings permission for the settings app)
• Approval of certified apps is limited to explicit list of authorized app stores.
• Require a strict Content Security Policy of "default-src 'self'"
• Not a common application type; reserved only for critical applications

Installation Experience

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 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

Data Usage Intentions

The data usage intentions (provided by apps as a rationale for a permission) can serve many purposes to help users with choice and control over their data.

On the Hook

Apps that make promises via usage intentions have essentially provided assurance to the user that their data will be used in a certain way. If it turns out the app developers use the data for another purpose (say actually recording Stashy photos and posting them on a public twitter feed), users have a clear way to explain how the app is operating deceptively.

Pre-Validation with Privacy Policies

Many apps will have a privacy policy. An app store has the opportunity to pre-screen apps based on the usage intentions in their manifest and the privacy policy they provide. So long as the two are consistent, users have a commitment from the app about what it intends to do with their data. Apps that are not consistent or vague can be rejected from an app store.

Auditing

To provide a "trail of activity", B2G or other app runtime could additionally maintain a capability-access log for each app that keeps track of requests for capabilities and the usage intentions over time. That way a curious user could analyze the log to see how often an app used a permission, why it used it, and perhaps help illustrate abuse of their consent.

Resolved Questions

Network access

Network access is assumed as an implicit permission for all apps (as it seems strange to prevent access to something all web content normally has). However the issue of network consumption has been raised as a valid concern.

Its not clear this is an issue for the security model to solve however, and would be better solved via an explicit consumption API that can help the user manage and limit resource utilization. Considered out of scope for the security model in general.

Background Apps

Apps running in the background may trigger permission requests. Since app requests should be in context of the user's interaction with the app, we should suppress any permission requests for non-foreground apps. It is up the developer to properly surface permissions requests while the app is interacting with the user.

Background Services

Services need to be certified apps as they have no way of surfacing permission requests to users since they have no UI. This means we should minimize the set of use cases that absolutely require true services.

Power User

Power users should be able to override the default trust roots to allow them to install arbitrary apps as privileged or certified. This is highly dangerous and should include a correspondingly strong disclaimer.

Same Origin Policy

Same origin policy should not be enforced for certified apps or privileged apps, since each app has its own cookie store.

Cookie & Password management

Cookies and passwords are stored per app.

Format for privileged and certified apps

We need an application delivery mechanism that provides assurances on app integrity and authenticity, and also allows for well-defined application & privilege scope enforcement so integrity can be maintained at runtime.

Apps will be packaged within a zip file format, along with the OWA manifest and a signature. This package will be provided to the app store for the review, which will then sign it upon approval. Upon installation, the client will verify that the signature is valid and chains to a privileged app store.

Privileged and certified apps will be accessed via a unique scheme (app://). The domain will correspond to the source of the app. For example, if an app is from "mozilla.org" the corresponding URI for the app would be "app://mozilla.org".

Open questions

Application Scope

Foundational assumption was that there was only one app per domain. This is because an origin is effectively the only security boundary in the browser, and determining the security implications of allowing apps with different permissions on the same domain is a time consuming exercise for the 1.0 timeframe.

Note that privileged and certified apps have their own unique origin via the app:// scheme.

Privileged Application Review Guidelines

We need a set of guidelines that define an acceptable level of security and privacy review for privileged applications. This should include:

• Ensuring that requested permissions are used for the purposes stated (in the permission rationale)
• Use of implicit permissions is appropriate
• Any interfaces between privileged app content and unprivileged external content have appropriate mitigations to prevent elevation of privilege attacks

Out of scope for 1.0

Magic button

This is a proposal to used a privileged button that grants access to certain APIs (camera, for example). This button would be located in the app's UI but rendered by the OS. It would have a consistent look & feel, and could not by styled, overlaid or obscured by the app.

Clicking this button would implicitly enable access to the camera. Clicking this button again (or providing a separate stop button) would turn off access again.

This is out of scope for 1.0. We do not have the time to fully understand the design and implementation issues with this approach, but it has a lot of merit and we will investigate it further for a subsequent release.

USB, Bluetooth, and NFC access

… for 3rd party apps. These have not been identified as priority use cases for 1.0 and require substantial research. We will support these in a subsequent release.

Certified apps as a 3rd party use case

We may someday have use cases that require certified 3rd party apps, but at this time all 3rd party apps that have been identified can be effectively implemented as privileged apps from a security and UX standpoint. We have no plans to support 3rd party apps as certified apps.