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.

** They use a minimum CSP policy in all pages in the app. This to ensure that the app doesn't get hacked using XSS attacks. I.e. we want to ensure that only the app developer's code runs, and not an attacker's code. Obviously this will never be perfect, but it will hopefully help a lot.

** The resources in a trusted app should use a different "cookie jar" than resources from the developer's website. This so that the trusted app can rely that the data it stores in cookies, indexedDB, etc isn't compromised.

I.e. this is to further make it possible to hack a trusted app by hacking the developer's website and overwriting data which the trusted app relies on to make it behave in ways it otherwise wouldn't.

** 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.

We came up with this solution since we wanted to avoid "packaging" apps into some sort of archive (like zip) and delivering it through the store. W3C widget specs and Chrome apps use this solution.

As Brian Smith has pointed out, signing HTTP responses isn't trivial. There's a significant risk that proxies will change headers on the way between the server and the user's browser. There even some risk that proxies will change the contents of the response bodies themselves. During normal browsing this isn't a big deal. But when the responses are signed it means that the response is completely rejected, leading to a very bad user experience. The only way to really prevent this is to always use https to