But just like for websites today, a webpage which contains an <iframe> pointing to a different origin can't reach into that iframe and modify or touch the objects there. And like with normal websites, permissions are separated by origin, meaning that just because a permission is granted to an app, doesn't mean that any <iframe>s that that app opens has access to the same permissions.
== Delivery mechanisms ==
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.
This doesn't change the fact that hosted apps, like all apps, are subject to the application sandbox described above.
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 ===
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.
Unlike a hosted app, packaged apps doesn't have an obvious URL that their resources can be loaded from. The way to refer to a resource in a packaged app is by using the <code>app:</code> protocol. The format for a <code>app:</code> URL is as follows
<code>app://identifier/path/within/zipfile/file.html</code>
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 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.
Relative links within <code>app:</code> works just like relative links within <code>http:</code>. Simply using a URL like <img src="/images/picture.jpg"> will load the image named "images/picture.jpg" in the zip package. You can also use markup like <a href="foo/bar.html"> to refer to a page relative the current page.
''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.
More information about why we developed a packaged apps solution is available here: [[Apps/PackagingProposal]]
== Privileged apps ==
