Changes

Jump to: navigation, search

Apps/Security

1,216 bytes added, 20:28, 29 June 2012
Open Web Apps Security Model: started adding privacy (data usage intentions) to the model
=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==
*Protect the device from poorly written & malicious applications
*With additional privileges come additional responsibilities for the developer and app store
*User consent choice and control - treat the user with respect and present them with choices they can that allow them to make informed decisions about. See our privacy operating principles [http://blog.mozilla.org/privacy/2011/01/12/mozillas-privacy-data-operating-principles/], 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==
*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
*At install app assets are verified & stored locally in appcache.
*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 trusted code and any untrusted content that the app may also load.
*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
Canmove, confirm
1,537
edits

Navigation menu