Changes

Jump to: navigation, search

Apps/Security

45 bytes removed, 22:15, 8 May 2012
Open Web Apps Security Model
=Open Web Apps Security Model=
{{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 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.
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 appsResolved Questions=====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://myapp). See [[Apps/Security/Distribution]] for ideas. 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.
 
===Application Scope===
Foundational assumption was that there was only one app per domain. This is because an origin is effectively the only security boundary in the browser, and determining the security implications of allowing apps with different permissions on the same domain is a time consuming exercise for the 1.0 timeframe.
===Background Apps===
===Same Origin Policy===
Same origin policy should not be enforced for certified apps or trusted apps, assuming that since each app has its own cookie store (see next question).
===Cookie & Password management===
Are cookie Cookies and password stores passwords are stored per app or . ==Open questions=====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://myapp). See [[Apps/Security/Distribution]] for ideas. 3) We should not invent Yet Another Installer Package ===Application Scope===Foundational assumption was that there was only one app per device?domain. This is because an origin is effectively the only security boundary in the browser, and determining the security implications of allowing apps with different permissions on the same domain is a time consuming exercise for the 1.0 timeframe.
Confirm
717
edits

Navigation menu