Confirmed users
716
edits
Apps/SecurityDetails: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 113: | Line 113: | ||
''Open Question'': We could surface in the prompt which of the above four types are being requested. It wouldn't increase the number of prompts that we have, but it would mean having to deal with what happens if the access changes for example from "readonly" to "readcreate" during an update. | ''Open Question'': We could surface in the prompt which of the above four types are being requested. It wouldn't increase the number of prompts that we have, but it would mean having to deal with what happens if the access changes for example from "readonly" to "readcreate" during an update. | ||
== | == Delivery mechanisms == | ||
B2G will support two formats for distributing apps. | B2G will support two formats for distributing apps, "hosted" and "packaged". Hosted apps work much like websites do today in that the resources for the app are located on a webserver and loaded through http. These can be cached for faster startup, but they still generally are delivered a lot like a normal website. | ||
Packaged apps are delivered as a .zip file which contains the resources that the app consists of. | |||
Generally speaking, it's entirely up to the app developer to choose between hosted or packaged apps. There are no differences as far as capabilities goes. | |||
However, there are some APIs that are only available to "Privileged Apps", which currently requires the app to be packaged due to signing requirements. See section below for Privileged apps. | |||
=== Hosted apps === | |||
A hosted app consists solely of an [http://mozilla.github.com/webapps-spec/ application manifest] file on the developer's web server. Often the manifest will also point to an appcache manifest which allows an app to be cashed for faster startup and to enable offline usage, but otherwise doesn't affect the app at all. | |||
From a security point of view, hosted apps work very much like normal websites. When a hosted app is loaded, the URL of the loaded pages are the normal URLs that those pages have on their web server. So to link to a specific page or resource in the app, the same URL is used as when linking to that page or URL on the website. | From a security point of view, hosted apps work very much like normal websites. When a hosted app is loaded, the URL of the loaded pages are the normal URLs that those pages have on their web server. So to link to a specific page or resource in the app, the same URL is used as when linking to that page or URL on the website. | ||
| Line 123: | Line 133: | ||
In order to secure that an app really wants to be installed as a web app we have to ensure that it's not possible to trick a website into hosting an application manifest. This is done by requiring that the manifest is served with a specific mime-type, "application/x-web-app-manifest+json". This restriction is relaxed when the manifest app, and thus the app manifest, is same-origin with the page that requested the app to be installed. | In order to secure that an app really wants to be installed as a web app we have to ensure that it's not possible to trick a website into hosting an application manifest. This is done by requiring that the manifest is served with a specific mime-type, "application/x-web-app-manifest+json". This restriction is relaxed when the manifest app, and thus the app manifest, is same-origin with the page that requested the app to be installed. | ||
== Packaged apps == | === Packaged apps === | ||
The second distribution format that B2G will support is packaged apps. A packaged app consists of a normal zip file which contains both the manifest and the application resources. When a packaged app is installed, the zip file is downloaded and the manifest is read from a well-known location inside the zip file. | The second distribution format that B2G will support is packaged apps. A packaged app consists of a normal zip file which contains both the manifest and the application resources. When a packaged app is installed, the zip file is downloaded and the manifest is read from a well-known location inside the zip file. | ||
| Line 145: | Line 155: | ||
== Privileged apps == | == Privileged apps == | ||
signed | As mentioned in the "Extended privileges" section, 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. | ||
CSP policy | |||
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. | |||
=== App Review === | |||
=== App Signing === | |||
=== Default CSP policy === | |||
== permission manager == | == permission manager == | ||