Confirm
717
edits
Changes
→Installed privileged application
*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.
====Why create a "privileged" application type?====
Some permissions are sensitive enough that we don't want just any webapp to get access to it. For example, the DeviceStorage API lets a website delete all the pictures in the user's "pictures folder". The API implementation does ask the user for permission before doing this, however we don't feel that it is enough protection for the user if the only thing standing behind the user and 10 years of lost pictures is a simple "do you want to allow this" dialog.
There are also some APIs that are too hard to explain to the user what consequences approving a certain permission would have, such as raw TCP socket access. For these we can't rely on users making well informed choices and so we need an alternative solution.
To support this we are also supporting a security model where the store takes on the responsibility of ensuring that an app won't behave maliciously with the permissions that it is granted. So for example the store takes on the responsibility of ensuring that an app won't use TCP sockets to scan for data on internal networks and save it on the developers website. And the store makes sure that an app won't delete all the user's pictures even if the user says ok to granting the app permission to use the DeviceStorage API. At least not without making it abundantly clear to the user that that is what will happen, and gives the user plenty of room for error.
Several mechanisms are used to enable to store to do this:
* The app will have to be reviewed by the store. Including reviewing all of the code that makes up the app.
* The app will be signed by the store to ensure that hacking the store website doesn't allow a hacker to install arbitrary content on users devices.
* The app will use a CSP policy to harden the app itself against bugs which would allow an attacker to inject code into the app. This will also make reviewing the app easier.
==== Default CSP policy ====
The CSP policy applied to all trusted apps is:
<code>default-src *; script-src 'self'; object-src 'none'; style-src 'self'</code>
This puts the following restrictions on pages in privileged apps:
* Scripts can only be loaded from the package.
* Scripts can not use data:-URIs
* Inline scripts can not be used
* eval() can not be used. Neither can eval-like functions like setTimeout or "new Function". setTimeout can still be used as long as the first argument is a Function object rather than a string.
* onXXX attributes can't be used in the markup of pages. You can still write javascript code like <code>myelement.onXXX = someFunction;</code> as long as you don't assign onXXX to a string, but rather to a Function object.
* <object>, <embed> and <applet> are fully disabled. In other words, plugins won't work at all. Including flash.
* CSS can only be loaded from the package. Inline CSS is however allowed.
This does not restrict any of the following:
* <code><iframe>s</code> can still point to any URL.
* Images can still be loaded from anywhere. Including when loaded using an <code><img></code> element, when using CSS background images or when using other types of CSS images.
* Media (audio and video) can still be loaded from anywhere.
* Network connections can still be opened anywhere using data-centric APIs like <code>XMLHttpRequest</code> or <code>WebSocket</code>.
There is no way for privileged apps to relax this policy. However we may in the future add the ability for packaged apps to define their own CSP policies, in which case that would allow apps to apply more restrictive policies. However such policies would be merged with the above policy which means that it still wouldn't allow the app to relax the policy.
===Certified application===
