Changes

Jump to: navigation, search

Apps/Security

46 bytes added, 22:50, 8 May 2012
no edit summary
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 storeafter a code review or some equivalent risk management process.
*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.
*Full details of implicit vs explicit permissions for each WebAPI are available here: https://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.
==Resolved Questions==
===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.
 
==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.
Confirm
717
edits

Navigation menu