Confirm
717
edits
Changes
no edit summary
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 Overview of 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.
*Not a common application type; reserved only for critical applications
==Installation Experience=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. ==Permissions and privileges==
===Permission prompting mechanisms===
* 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.
===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 or equivalent workflow.
===Same Origin Policy===
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.
==Application Lifecycle==This section describes the format, installation and updates process for applications. ===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.
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".
==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)
*Any interfaces between privileged app content and unprivileged external content have appropriate mitigations to prevent elevation of privilege attacks
=== Updates === A lot of the update model is still being defined. Requirements are being collected here at [[Gaia/System/Updates]] == Application sandboxing Sandboxing ==
=== Data stored per app ===
''Open question'': Should we enable users looking at the list of prompted and implicit permissions at the time of installation?
=== <code>access</code> property ===
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.
== permission manager ==
