Confirmed users
717
edits
Apps/Security: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 49: | Line 49: | ||
*Same origin enforced | *Same origin enforced | ||
===Installed | ===Installed privileged application=== | ||
Authenticated application approved by an app store. Equivalent in functionality and security to apps on other mobile platforms. | 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 comprised of an explicit list of assets. | ||
| Line 58: | Line 58: | ||
*All explicit permissions are requested at runtime, showing user the app's data usage intentions, and persisted by default. | *All explicit permissions are requested at runtime, showing user the app's data usage intentions, and persisted by default. | ||
*User can monitor permission state and change app permissions via consistent permission notification UI | *User can monitor permission state and change app permissions via consistent permission notification UI | ||
*Privileges granted are limited to explicit list of application assets; we must enforce security boundaries between | *Privileges granted are limited to explicit list of application assets; we must enforce security boundaries between privileged code and any unprivileged content that the app may also load. | ||
*No same-origin restrictions for app content; same origin still enforced for non-app content. | *No same-origin restrictions for app content; same origin still enforced for non-app content. | ||
===Certified application=== | ===Certified application=== | ||
This category is reserved for apps that require approval by carrier or OEM due to risk of | 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 | 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 Privileged apps, except: | ||
*All permissions are implicit. | *All permissions are implicit. | ||
*User cannot modify permissions (as it could break the device; ex. disable settings permission for the settings app) | *User cannot modify permissions (as it could break the device; ex. disable settings permission for the settings app) | ||
| Line 106: | Line 106: | ||
===Power User=== | ===Power User=== | ||
Power users should be able to override the default trust roots to allow them to install arbitrary apps as | Power users should be able to override the default trust roots to allow them to install arbitrary apps as privileged or certified. This is highly dangerous and should include a correspondingly strong disclaimer. | ||
===Same Origin Policy=== | ===Same Origin Policy=== | ||
Same origin policy should not be enforced for certified apps or | Same origin policy should not be enforced for certified apps or privileged apps, since each app has its own cookie store. | ||
===Cookie & Password management=== | ===Cookie & Password management=== | ||
Cookies and passwords are stored per app. | Cookies and passwords are stored per app. | ||
===Format for | ===Format for privileged and certified apps=== | ||
We need an application delivery mechanism that provides assurances on app integrity and authenticity, and also allows for well-defined application & privilege scope enforcement so integrity can be maintained at runtime. | We need an application delivery mechanism that provides assurances on app integrity and authenticity, and also allows for well-defined application & privilege scope enforcement so integrity can be maintained at runtime. | ||
Apps will be packaged within a zip file format, along with the OWA manifest and a signature. This package will be provided to the app store for the review, which will then sign it upon approval. Upon installation, the client will verify that the signature is valid and chains to a | Apps will be packaged within a zip file format, along with the OWA manifest and a signature. This package will be provided to the app store for the review, which will then sign it upon approval. Upon installation, the client will verify that the signature is valid and chains to a privileged app store. | ||
Privileged and certified apps will be accessed via a unique scheme (app://). The domain will correspond to the source of the app. For example, if an app is from "mozilla.org" the corresponding URI for the app would be "app://mozilla.org". | |||
==Open questions== | ==Open questions== | ||
| Line 125: | Line 125: | ||
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. | 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. | ||
Note that | Note that privileged and certified apps have their own unique origin via the app:// scheme. | ||
=== | ===Privileged Application Review Guidelines=== | ||
We need a set of guidelines that define an acceptable level of security and privacy review for | We need a set of guidelines that define an acceptable level of security and privacy review for privileged applications. This should include: | ||
*Ensuring that requested permissions are used for the purposes stated (in the permission rationale) | *Ensuring that requested permissions are used for the purposes stated (in the permission rationale) | ||
*Use of implicit permissions is appropriate | *Use of implicit permissions is appropriate | ||
| Line 143: | Line 143: | ||
… 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. | … 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=== | ===Certified apps as a 3rd party use case=== | ||
We may 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 | We may 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 privileged apps from a security and UX standpoint. We have no plans to support 3rd party apps as certified apps. | ||