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-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
