===Same Origin Policy===
Same origin policy should not be enforced for certified apps or privileged apps, since each app has its own cookie store. The app would have to declare its intent to bypass same-origin policy.
==Application Lifecycle==
This section describes the format, installation and updates process for applications.
===Format for 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 privileged app store.
Privileged and certified apps will be accessed via a unique scheme (app://). The domain will correspond to the source of the app. For example, if an app is from "mozilla.org" the corresponding URI for the app would be "app://mozilla.org".
===Privileged Application Review Guidelines===
We need a set of guidelines that define an acceptable level of security and privacy review for 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
*Any interfaces between privileged app content and unprivileged external content have appropriate mitigations to prevent elevation of privilege attacks
=== Updates ===
A lot of the update model is still being defined. Requirements are being collected here at [[Gaia/System/Updates]]
=== 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]]
== Application Sandboxing ==
