Confirm
717
edits
Changes
no edit summary
*Same origin enforced
===Installed trusted privileged 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.
*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
*Privileges granted are limited to explicit list of application assets; we must enforce security boundaries between trusted privileged code and any untrusted unprivileged content that the app may also load.
*No same-origin restrictions for app content; same origin still enforced for non-app content.
===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 Privileged apps, except:
*All permissions are implicit.
*User cannot modify permissions (as it could break the device; ex. disable settings permission for the settings app)
===Power User===
Power users should be able to override the default trust roots to allow them to install arbitrary apps as trusted privileged or certified. This is highly dangerous and should include a correspondingly strong disclaimer.
===Same Origin Policy===
Same origin policy should not be enforced for certified apps or trusted privileged apps, since each app has its own cookie store.
===Cookie & Password management===
Cookies and passwords are stored per app.
===Format for trusted 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.
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 trusted privileged app store.
==Open questions==
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 trusted privileged and certified apps have their own unique origin via the app:// scheme.
===Trusted Privileged Application Review Guidelines===We need a set of guidelines that define an acceptable level of security and privacy review for trusted privileged applications. This should include:
*Ensuring that requested permissions are used for the purposes stated (in the permission rationale)
*Use of implicit permissions is appropriate
… 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===
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 trusted privileged apps from a security and UX standpoint. We have no plans to support 3rd party apps as certified apps.
