Changes

The intent of this page is to provide some background for how security works in B2G and Desktop/Android OpenWebApps. The target audience for this page is (at least for now) primarily people working on implementing B2G and the Open Webapps runtimes. Over time we should improve the pieces that affect web developers such that they can be used as developer documentation.

=Open Web Apps Security and Privacy Model=

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.

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

List of webAPIs and corresponding security discussions: [[WebAPI]]

*Maintain core strengths and flexibility of the web

*Protect the security and privacy of the user

*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 [http://blog.mozilla.org/privacy/2011/01/12/mozillas-privacy-data-operating-principles/], specifically "Real Choices."

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.

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.

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.

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.

Not a type of application per our definition of installed apps, but part of the WebAPI security

continuum and so discussed here.

*Most permissions requested via web intents

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

*Same origin enforced

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 contained in a zip package.

*No same-origin restrictions for app content; same origin still enforced for non-app content.

Some permissions are sensitive enough that we don't want just any webapp to get access to it. For example, the DeviceStorage API lets a website delete all the pictures in the user's "pictures folder". The API implementation does ask the user for permission before doing this, however we don't feel that it is enough protection for the user if the only thing standing behind the user and 10 years of lost pictures is a simple "do you want to allow this" dialog.

* The app will use a [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html CSP] policy to harden the app itself against bugs which would allow an attacker to inject code into the app. This will also make reviewing the app easier.

The CSP policy applied to all privileged and certified apps is:

There is no way for privileged apps to relax this policy. However we may in the future add the ability for packaged apps to define their own CSP policies, in which case that would allow apps to apply more restrictive policies. However such policies would be merged with the above policy which means that it still wouldn't allow the app to relax the policy.

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:

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

*Not a common application type; reserved only for critical applications

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.

This sections describes the permission model for applications.

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.

}

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.

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.

* Full details of implicit vs explicit permissions for each WebAPI are available here: https://wiki.mozilla.org/WebAPI

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.

''Open question'': Should we enable users looking at the list of prompted and implicit permissions at the time of installation?

For some APIs there is an additional "access" property which allows specifying if the app wants read, write or create access. This looks like:

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

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.

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.

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.

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.

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.

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.

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 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 or equivalent workflow.

Same origin policy should not be enforced for certified apps or privileged apps, since each app has its own cookie store. The app would have to declare its intent to bypass same-origin policy.

Each application runs in as a separate sandbox, meaning that all data stored by an application is separate from all data stored by another application. This includes things like cookie data, localStorage data, indexedDB data and site permissions.

A result of this is that if the user logs in to, for example, facebook while using App A, this in no way affects App Bs ability to interact with the users account on facebook. The login cookie that facebook sets when the user logs in using App A is only available in App A. If App B open an <iframe> to facebook, the cookie wouldn't be there and so when App B opens facebook, it receives the facebook login page rather than the users account.

This means that apps can't open other apps by using iframes. If App A creates an iframe with the src set to the URL of App B, this won't actually open App B in the iframe. It will simply open the website located at that URL. It will not use any of App B's cookies and so it will behave no different than as if App B wasn't installed on the user's device.

The same thing happens if the top-level frame of App A is navigated to a URL for App B. We always know for a given frame which app is opened in it, and so when attempting to load the App B URL in the App A frame, this will behave exactly like the two situations described above. I.e. in no way will App B's resources, like cookies or other local data, be used.

There are both benefits and downsides to this approach. The downside is that if the user interacts with the same website through several apps, he/she will have to log in in every app. Likewise, if a website wants to store data locally, and the user interacts with this website in several apps, the data will end up getting duplicated in each app which could be a problem if it's a large amount of data.

There are also good privacy benefits. The user can safely install the PoliticalPartyPlus app without having to worry that MegaCorpEmployeeApp will be able to detect that the app was installed or what data it has created.

And just like website data is sandboxed per app, so are permission grants. If App A loads a page from http://maps.google.com and that page requests to use geolocation and the user says "yes, and remember this decision for all times", this only means that http://maps.google.com has access to geolocation within App A. If App B then opens http://maps.google.com, that page won't have access to geolocation unless the user grants that permission again.

</pre>

As has been discussed above, an app can always contain content from multiple domains. This is exactly like how a website today can create an <iframe> pointing to a different domain.

But just like for websites today, a webpage which contains an <iframe> pointing to a different origin can't reach into that iframe and modify or touch the objects there. And like with normal websites, permissions are separated by origin, meaning that just because a permission is granted to an app, doesn't mean that any <iframe>s that that app opens has access to the same permissions.

appid/browserContent flag in B2G

separate profiles on desktop/android

This section describes the format, installation and updates process for applications.

B2G will support two formats for distributing apps, "hosted" and "packaged". Hosted apps work much like websites do today in that the resources for the app are located on a webserver and loaded through http. These can be cached for faster startup, but they still generally are delivered a lot like a normal website.

However, there are some APIs that are only available to "Privileged Apps", which currently requires the app to be packaged due to signing requirements. See section below for Privileged apps.

A hosted app consists solely of an [http://mozilla.github.com/webapps-spec/ application manifest] file on the developer's web server. Often the manifest will also point to an appcache manifest which allows an app to be cashed for faster startup and to enable offline usage, but otherwise doesn't affect the app at all.

In order to secure that an app really wants to be installed as a web app we have to ensure that it's not possible to trick a website into hosting an application manifest. This is done by requiring that the manifest is served with a specific mime-type, "application/x-web-app-manifest+json". This restriction is relaxed when the manifest app, and thus the app manifest, is same-origin with the page that requested the app to be installed.

The second distribution format that B2G will support is packaged apps. A packaged app consists of a normal zip file which contains both the manifest and the application resources. When a packaged app is installed, the zip file is downloaded and the manifest is read from a well-known location inside the zip file.

More information about why we developed a packaged apps solution is available here: [[Apps/PackagingProposal]]

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.

Privileged and certified apps will be accessed via a unique scheme (app://). The domain will correspond to the app id.

''Definition of the signing format goes here. Brian Smith is working on this.''

A lot of the update model is still being defined. Requirements are being collected here at [[Gaia/System/Updates]]

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)

Since the OpenWebApps API allows any website to become a store, only stores approved by B2G will be allowed to install Privileged apps. Our goal is that multiple stores will become approved for installing privileged app, but given how much responsibility is put on the store, we need to ensure that we put agreements in place to protect users before approving a store for being allowed to install privileged apps.

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.

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.

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

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.