Changes

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