Lucas - On Background Apps and just to be explicit. If we assume that Background apps always have a UI component that shows up in the home screen, then can we state that when a background component needs a permission that hasn't been granted that the UI component will be opened and the prompt occur there? If we allow Background only apps, I'm not sure where the permission prompt will occur. Actually, we may want to explicitly state that if an app that is not the currently viewed app and needs permissions that it the app needing the permission is made the currently viewed app. -Jim Straus
On May 1, 2012, at 11:23 PM, Lucas Adamski wrote: > Please reply-to dev-webapps. > > There's been much discussion lately of the different types of applications > and so I figured this would be a good time to > summarize the current state of discussion. From a security perspective, > there are 3.5 types of applications. Confused > yet? Excellent! > > ==Types of applications== > > 1a) Normal web content. Not a type of application per our definition of > installed apps, but part of the WebAPI security > continuum and so should be discussed here. > *No app store involved. > *No manifest or installation experience. > *No restrictions on origin or transport (i.e. HTTPS not required). > *All explicit permissions are granted at runtime, not persisted by default. > > 1b) Installed untrusted applications: 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). > *Installation experience with permissions being opt-in at install and > runtime, limited to permissions enumerated in the > manifest. > *No app store code reviews as they'd 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 granted at runtime, not persisted by default. > > 2) Installed trusted application: Authenticated application approved by an > app store, with an explicit list of assets > that comprise the app. > *App is reviewed and approved by app store. > *App store signs the app manifest which contains a list of assets and their > corresponding hashes. > *App assets are verified & stored locally in appcache. > *Require a CSP policy of "script-src: 'self'; object-src: 'self'; style-src: > 'self'" to mitigate content injection > attacks and maintain application integrity. > *Explicit permission grants are persisted by default. > > 3) Certified application: 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. > *All permissions are implicit. > *User cannot modify/disable permissions. > *Approval of certified apps is limited to explicit list of authorized app > stores. > > ==Open questions for trusted apps== > > Permission prompting mechanisms. This is currently being led by UX and we > will have a detailed proposal to discuss shortly. > *Prompt for security permissions at runtime only, or install-time & runtime? > **Should permissions be visible or in a pulldown at install? > **Initial permission prompt at install or first launch? > **Check/uncheck permissions at install? > *Provide a permission rationale as approved by app store? Yes. > *Concerns that many apps could require a lot of runtime security prompts, > resulting in a bad UX and ineffective security > model. One possible mitigation is to split permissions into Recommended > (opt-out) and Optional (opt-in) for trusted > apps, as approved by app store, and reviewed/accepted by user at install > time. So Camera API might be Recommended for a > camera app, but not for a cookbook app. Geolocation could be Recommended for > a GPS navigation app, but not a Camera app. > *Magic button: Use implicit consent via normal user interactions when > possible, but we don't have the time to fully > evaluate the technical and use-case risks specific to the magic button > approach for 1.0. So we should rely on implicit > UI and web intents for untrusted content and apps, and assume most trusted > apps will want permission decisions to be > persisted. > > ==Open questions for trusted & certified apps== > > Need to decide on a package format that provides assurances on app integrity > and authenticity, and also allows for > well-defined scope (domain) enforcement so integrity can be maintained at > runtime > *We could extend appcache manifest to include hashes, and the app store would > sign the whole thing (add magic crypto > dust here). This would allow app assets to still live on website, but have > many of the benefits of code signing. This > has issues with defining a clear application scope (i.e. what does a CSP > policy of 'self' mean.. we'd need to get > creative and invent a new domain) > *Use existing code/widget package format. We get the benefit of a > well-tested format, and the developer doesn't have to > pay for domain registration, hosting, SSL certs, etc. We also get a > well-defined domain for each app (ex. jar://myapp) > *Inventing our own Yet Another Installer Package seems like a waste of time, > so lets not. > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
