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 69: | Line 69: | ||
} | } | ||
} | } | ||
=== Prigileged-app-only permissions === | |||
Some permissions are sensitive enough that we don't want to just hand them to any app. For example a permission which enables pages to read or modify pictures from the users picture folder is very sensitive. For such an API we in addition to requiring the app to enumerate the permission in the app manifest, require that the app is a "Privileged App". See details about this in the section for Privileged Apps below. | |||
=== Prompting === | === Prompting === | ||
Just because a permission is enumerated in the manifest doesn't mean that an app will be automatically granted that permission at time of installation. For many APIs, like the wifi-information API, enumerating the permission in the manifest simply means that the app can attempt to use it. When used, the user will be prompted and asked if it's ok to grant the permission to the app. During this prompt, the description provided in the manifest will be displayed to the user. However it will be displayed in such a way that it is clear that the description comes from the app developer, and not from B2G itself. | |||
=== Implicit access === | === Implicit access === | ||
| Line 129: | Line 133: | ||
The <code>identifier</code> is a uuid generated at install time. This identifier will remain constant as long as the app is installed. (Eventually the identifier might become the ''home domain'' of the app, but we don't have such a concept yet). | The <code>identifier</code> is a uuid generated at install time. This identifier will remain constant as long as the app is installed. (Eventually the identifier might become the ''home domain'' of the app, but we don't have such a concept yet). | ||
Whenever a resource is loaded using the <code>app:</code> protocol, this will only allow loading | Whenever a resource is loaded using the <code>app:</code> protocol, this will only allow loading resources from the zip file associated with the current app. I.e. if you specify an <code>identifier</code> for another app, it will behave exactly as if you specify an invalid identifier or an identifier for an app which isn't installed. | ||
''Open question'': We probably need to allow linking to an app:// page. However we could forbid putting an app:// page in an <iframe>. Other than by other app:// pages of course. | |||
One important thing to note about this is that the app protocol doesn't have a concept of a domain. In other words, packaged apps aren't same-origin with any "normal" websites. This is because we don't know the home domain of the developers or the app. We only know which store was used to install the app. | |||
A result of this is that any time XMLHttpRequest is used to read data from a website, it's considered a cross-origin read and so the website has to support CORS. Eventually we'll want to enable packaged apps having a home domain, but that's not yet supported. | |||
Just like with hosted apps, we want to make sure that a hosting website can't be tricked into hosting a app package. The risk is fairly low even if that could happen since even if the user got an app installed, as mentioned above, that app won't be same-origin with the website that the package came from. However to be safe we still apply the same security restrictions as for hosted apps. I.e. the package has to be served with a specific MIME type, or has to be same-origin with the page installing the package. | |||
== Privileged apps == | == Privileged apps == | ||
signed | |||
CSP policy | CSP policy | ||
has to go through review | has to go through review | ||