Apps/PackagingProposal: Difference between revisions

* They are reviewed in some form. I.e. a trusted party has indicated some level of trust in the application. In the initial version of B2G we've had as a requirement that the store should review the actual app contents. In future releases I'd also like to support stores indicating trust in the app developer rather than the app itself, but this isn't slated for the initial B2G release.

* They are signed. This is needed in order to verify that the app actually contains the reviewed content. It also protects against someone hacking the webserver which the app is served from.

* The resources in a trusted app should not be "same origin" with any resources other than ones from the same trusted app. I.e. if a trusted app creates an <iframe> pointing to the developer's website, javascript running

inside the iframe shouldn't be able to reach out and touch the objects in the trusted app. This is since otherwise it would obviously be significantly easier to hack a trusted app by hacking any websites that it opens in <iframe>s.

Our initial thoughts for how to implement these requirements were that trusted apps should use largely the same delivery mechanism as normal apps. I.e. they should live as normal files on the developer's web server. The resources would then be cached using the normal app cache. The signatures for the reviewed files would be gotten from the store at the time of installation as well as any time the app is updated.

When looking at the proposed solution this way it seems like we have come up with something that is the worst of both worlds. App developers are forced to create apps which consist of static resources and every time they want to publish a new version they have to contact all stores that they want to sell their app through. This feels a lot like a packaged app, the only difference is that the resources live as separate files on the developers server rather than as a zip file in the store. Yet app developers have to serve their apps through SSL and deal with coordinating publishing through multiple stores. This is non-webby, a pain to publish through and potentially expensive.

Hence we have changed the plan to instead base trusted apps on a "packaged" solution. The idea will be that to publish a trusted app the developer will create a zip archive which contains the app manifest as well as all resources needed for the app. The app can then be sent to all stores which the developer wants to publish the app trough. These stores can then review the app and sign the package. At installation time the signed package is downloaded by the B2G from the store and the package is verified against the signature.

One obvious question once you go with a packaged solution is what URLs the packaged resources will be available through. My initial thought was to keep things as webby as possible and to make the resources in the package available as normal http or https URLs. The goal was that packaged apps would behave as much as possible as non-packaged apps. This would mean that in a trusted app a page that was part of the app would have URL https://developer.com/myapp.html, and a page which was part of the developer's website would have the URL https://developer.com/index.html. Yet the two pages would use different cookies, and any same-origin checks would have to say that the two pages are different. This is to satisfy the last two requirements in the bullet list at the beginning of this email. This is certainly implementable, however it seems very confusing for developers.

In order to keep applications isolated from each other (except through explicit APIs like WebActivities) the app:// protocol always maps to loading from the package that the load is initiated from. Consider a user which has a facebook app and a google maps app installed. Whenever the facebook app loads an app:// URL, we always look in the package which contains the facebook app. If the resource isn't found there we return a 404 error. I.e. we never even look at the google maps package, even the facebook app tries to load something like app://google.com/map.html, the result is simply a 404. This also means that it's not a problem to install two apps from google which both contains the same app:// google.com/library.js URL. Each app would simply load the library.js file from its own package.

There are still lots of parts that we need to figure out. First of all we need to define an exact format for the package. There are lots of formats out there for signed packages, .jar which is commonly used by java, .xpi which Firefox uses for addons, .crx used by Chrome, etc. We can either pick an existing one, or design a new one. I'll explicitly declare it off topic for this thread to come up with the specific format. Please start separate threads about that.

We also need to come up with an update mechanism. One solution would be to every now and then check the URL which we used to download the original package to see if a new version is available. Another solution would be to send a single request to the store enumerating all apps which we want to check for updates for. That would allow for less traffic in the common case of no apps needing any updates, but might be more complex to implement and could have privacy implications. Again, this is off topic for this thread, please start separate threads if you want to discuss this topic.

All in all this definitely means that trusted apps won't be as webby as normal apps. However as long as we have the requirements around signing by the store, an enforced CSP policy and a separate cookie jar, trusted apps simply won't be very webby. Whether we zip the files up in an package and deliver them the store for signing, or we deliver them through the store through http, is a relatively small difference which only affects the deployment of the app, not the development.

In the long run I definitely want to make trusted apps more "webby". Both by changing our trusted apps work, and also by giving the web more capabilities so that they can meet somewhere in the middle. But I think the above proposal is a good way to start by doing something secure which will give us experience and help us develop something better in the future.