= Boot 2 Gecko App Open Web Apps Security Model Discussion =This page is for capturing information about the B2G/OWA security discussion. {{note|<b>This is not a design document and should not be considered authoritative at this time</b>}}{{note|<b>This page has been subdivided into sections that have their own page but have been [http://en.wikipedia.org/wiki/Wikipedia:Transclusion transcluded]. If it is easier (less intimidating), each section may be edited as its own page.</b>}}
There are four separate areas where {{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 work is requiredmodel spans a wide variety of use cases, from typical web content to system-critical applications. Each area is separate but interAs such, a one-size-fits-relatedall security model won't work. Each is '''required''' Instead we need a range of options that balance out the flexibility and cannot be ignoredcommon design patterns for web applications while mitigating the additional risks that come with exposing sensitive APIs.
* [[Apps/Security/Distribution|'''Secure Application Distribution''']]. A level of trust must be established between all four parties: B2G developers, Application developers, users ==Discussion and stores.Resources==* [[Previous Apps/Security/Enforcement|'''Application Permissions Enforcement''']]. This can '''only''' be done at the Operating System (kernel) level.* [[Apps/Security/Permissions|'''Definition, management and presentation of the permissions to be enforced''']]. Examples include "app can access the IMEI number" and "app can make phone calls".* discussion page: [[Apps/Security/StandardWebSecurity|'''Standard web security'''Discussion]]. This is what is normally considered to be "the web" (XSS in AJAX etc.) and it still has a role to play in B2G.
Additional reading List of webAPIs and linkscorresponding security discussions:* Track the status of [[B2G_App_Security_Model]]* Track the status of [[B2G_App_Security_Model/Threat_ModelWebAPI]]* [https://developer.mozilla.org/en/OpenWebApps OWA developer page]
__TOC__==Foundational principles==*Maintain core strengths and flexibility of the web*Protect the security and privacy of the user*Protect the device from poorly written & malicious applications *With additional privileges come additional responsibilities for the developer and app store*User consent and control - treat the user with respect and present them with choices they can make informed decisions about
{{==Types of applications==There are 3 types of installed application. In additional, many webAPIs are also exposed to regular web content, so that category is included here for context. ===Normal web content===Not a type of application per our definition of installed apps, but part of the WebAPI securitycontinuum and so 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 requested at runtime, not persisted by default*Most permissions requested via web intents ===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 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, not persisted by default.*Most permissions requested via web intents ===Installed trusted application===Authenticated application approved by an app store. Equivalent in functionality and security to apps on other mobile platforms.*App is comprised of an explicit list of assets.*App is code reviewed and approved by app store.*App store signs the app manifest which contains the list of assets and their corresponding hashes. *At install app assets are verified & stored locally in appcache.*Require a Content Security Policy of "script-src:Apps/Security/Definitions}}'self'; object-src: 'self'; style-src: 'self'" to mitigate content injection attacks and maintain application integrity.*All explicit permissions are requested at runtime, and persisted by default.*User can monitor permission state and change app permissions via consistent permission notification UI*Privileges granted are limited to list of application assets; that means we need to put those into a domain separate from their original origin. ===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. Not intended for 3rd party applications. Similar to Trusted apps, except:Apps/*All permissions are implicit.*User cannot modify permissions (as it could break the device; ex. disable settings permission for the settings app)*Approval of certified apps is limited to explicit list of authorized app stores.*Require a strict Content Security/Bugs}}Policy of "default-src 'self'"*Not a common application type; reserved only for critical applications ==Installation Experience== ===Permission prompting mechanisms==={{UX is currently developing detailed mockups that will be ready to ready to review shortly. The overall flow will be:Apps/Security/Summary}}{{:Apps/Security/Distribution}}*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){{:Apps/Security/Enforcement}}*Permissions for high risk APIs are prompted for at runtime with a corresponding rationale for the request{{:Apps/Security/*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:Apps/Security/StandardWebSecurity}}wiki.mozilla.org/WebAPI ==Out of scope for 1.0=={{===Magic button===This is a proposal to used a privileged button that grants access to certain APIs (camera, for example). This button would be located in the app's UI but rendered by the OS. It would have a consistent look & feel, and could not by styled, overlaid or obscured by the app. Clicking this button would implicitly enable access to the camera. Clicking this button again (or providing a separate stop button) would turn off access again. This is out of scope for 1.0. We do not have the time to fully understand the design and implementation issues with this approach, but it has a lot of merit and we will investigate it further for a subsequent release.===USB, Bluetooth, and NFC access===… for 3rd party apps. These have not been identified as priority use cases for 1.0 and require substantial research. We will support these in a subsequent release.===Certified apps as a 3rd party use case===Its possible we could someday have use cases that require certified 3rd party apps, but at this time all 3rd party apps that have been identified can be effectively implemented as trusted apps from a security and UX standpoint. We have no plans to support 3rd party apps as certified apps. ==Open questions for trusted & certified apps=====Format for trusted and certified apps===Need to determine 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 1) 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. need a separate app domain from the origin domain) 2) 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:Apps/Security/Other}}myapp) 3) We should not invent Yet Another Installer Package ===Network access===Network access is assumed as an implicit permission for all apps (as it seems strange to prevent access to something all web content normally has). However the issue of network consumption has been raised as a valid concern. Its not clear this is an issue for the security model to solve however, and would be better solved via an explicit consumption API that can help the user manage and limit resource utilization. Considered out of scope for the security model in general.
