canmove, Confirmed users
1,537
edits
Apps/Security: Difference between revisions
→Installation Experience: reasons why we should implement the usage intentions
Ptheriault (talk | contribs) |
(→Installation Experience: reasons why we should implement the usage intentions) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Open Web Apps Security 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.}} | {{note|Please do not edit this page. Share your ideas in dev-webapps@lists.mozilla.org or [[Apps/Security/Discussion]] instead.}} | ||
==Introduction== | ==Introduction== | ||
The open web application security 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. | 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== | ==Discussion and Resources== | ||
| Line 15: | Line 15: | ||
*Protect the device from poorly written & malicious applications | *Protect the device from poorly written & malicious applications | ||
*With additional privileges come additional responsibilities for the developer and app store | *With additional privileges come additional responsibilities for the developer and app store | ||
*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." | ||
==Definitions== | ==Definitions== | ||
===Explicitly granted permissions=== | ===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. | 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=== | ===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. | 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== | ==Types of applications== | ||
| Line 42: | Line 45: | ||
*No app store code reviews as they serve no purpose (app can change anytime without user or reviewer consent). | *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. | *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, not persisted by default. | *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 | *Most permissions requested via web intents | ||
*Same origin enforced | *Same origin enforced | ||
| Line 53: | Line 56: | ||
*At install app assets are verified & stored locally in appcache. | *At install app assets are verified & stored locally in appcache. | ||
*Require a Content Security Policy to mitigate content injection attacks and maintain application integrity. | *Require a Content Security Policy to mitigate content injection attacks and maintain application integrity. | ||
*All explicit permissions are requested at runtime, and persisted by default. | *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 | *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. | *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. | ||
| Line 72: | Line 75: | ||
===Permission prompting mechanisms=== | ===Permission prompting mechanisms=== | ||
UX is currently developing detailed mockups that will be ready to ready to review shortly. The overall flow will be: | 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 | * 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 | * 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) | * 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 for the request | * 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 | * 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 | * Full details of implicit vs explicit permissions for each WebAPI are available here: https://wiki.mozilla.org/WebAPI | ||
==Use of 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== | ==Resolved Questions== | ||
===Network access=== | ===Network access=== | ||