Hi all, Since we introduced packaged apps, there has been a lot of concern that they are very different from the web. And rightfully so. The current incarnation of packaged apps require an installation step, they result in pages that don't have real URLs and while they use zip, they are effectively non-standard.
However packages also solve some quite important problems. The main problem that they solve for us is signing. While technically it's possible to sign files without using packaging, it is more complex and error prone to do compared to signing a package. It would be great if we could get rid of the need for signing. However for now they solve very important problems for us. For some APIs they are the only ways to secure what could be argued are legacy features, like TCPSocket, UDPSocket and System XHR (I.e. raw HTTP). Ideally everyone would move to using WebSocket, WebRTC and CORS, but we're likely many years away from that. For other APIs, like DeviceStorage, we still need signatures as an extra layer of security so that we're simply not relying on the user to understand that answering "yes" to a security dialog might cause all your pictures to be deleted and held for money. Signatures also provide something that the web is in big need of. An additional security layer so that simply hacking a webserver isn't the only thing needed by an attacker that wants to steal all your application data, as well as any personal data that the user has granted the application access to. However if we can enable developers to sign their own applications, rather than having to have them signed by the marketplace, then that would still mean that developers could roll out updates as quickly as web developers do today. I.e. no need to wait for review from a marketplace. Additionally packages bring other advantages. The W3C TAG is currently working on creating a standardized packaging format for the web. They are doing this for at least a couple of reasons. First of all pages currently provides some performance benefits since it reduces the number of http roundtrips needed. People today do all sorts of crazy hacks to inline resources into each other, including inlining CSS and JS into HTML files, sprite image files together into larger images, base64 encode and inline images into HTML and JS, etc. All of this to reduce the number of http requests, while working around the fact that the web currently doesn't enable bundling multiple files into one in a simple uniform way. Second, having to juggle multiple files can be a big annoyance. Anyone who has created a HTML slide deck knows how annoying it is to then send that slide deck to someone. You are forced to either do inlining hacks like the ones described above, or to zip all dependencies into a single file and then ask the person you are sending the deck to to unpack them. Compare this to sending a keynote or powerpoint file to anyone who can then simply double-click the file to watch it. The same problem occurs if you are writing a JS library which has dependencies on other libraries, or which for other reasons are spread out over multiple JS files. Or possibly which has dependencies on JSON files or image files. Right now you have to either compile the files into a single file, which is hard to do in a generic way, or you have to manage multiple separate files and pay the performance cost that's involved. Hopefully SPDY and HTTP/2 will solve many of the performance issues mentioned here. It should dramatically lower the cost of making multiple requests to the server. Though it will take time for those to get adoption. And it still leaves us with the extra cost that's involved with managing multiple files. And it's not clear that it will have a 100% overlap with the performance issues that packages help with (though really, they should help with most). So in short, packages still are useful for: * Additional security through signatures * Managing dependent resources * Possibly some performance issues So the question is, how can we make sure that packages have all the benefits that normal webpages have today. I propose that we do the following: 1. Create a new package format. The format should support streaming and support adding metadata, like headers, to individual resources. It likely also needs to support metadata for the package itself. 2. Add CSP syntax similar to "self" but which means "in the same package" rather than "from the same origin". 3. Add a new URL syntax for referring to resources within a package. One candidate is http://server.com/url/to/myapp.webpackage!//images/pic.jpg. I.e. the "!//" signals boundary between the URL sent to the server to fetch the package, and the path within the package to get a resource. But we need to check that this is web compatible. 4. Define metadata which can be added to the package for "this is a privileged app" and/or "this package is signed" This way, a user can simply browse to pages within a packaged app, just like you can to pages within a hosted app. To the user there would be absolutely no difference, other than that the URL would contain "!//". To the developer the main difference would be that you only upload a single file to the server rather than multiple files. And of course that you need to sign the package and use an appropriate CSP policy if you want the app to use privileged APIs. There's still lots of details here to hammer out. Like finding a web compatible syntax for URLs to resources within apps. And what's the performance of browsing to a signed app where we need to verify the signature. And how do we delegate the ability to sign apps to developers, i.e. how do we make the marketplace vouch for a developer rather than an app. Another problem, which isn't packaging specific but that is still important, is how do we give a browsed-to app additional permissions over what webpages have. Currently permissions are created by the installation code, but that won't work for browsed-to privileged apps. But by seeing that the user has browsed to a package which is flagged with "this is a privileged app", we can run the extra steps of verifying signatures and loading the application manifest inside the package and grant the appropriate permissions requested there while the user is using the app. And what's the origin of a privileged app. If they get the same origin as the server that they were loaded from, that would mean that any page on that server could simply <iframe> the packaged app, then inject a <script> tag into the <iframe> which would cause the script to run with privileged access. Anyhow, this is intended to be a starting point of discussion. And a way to ease people's mind that we aren't breaking the web without working on a plan to unbreak it as well as improve it. But this is a complex subject and I can promise we won't be able to solve all problems that we'd like to. Security tends to be that way. But I think that we have a decent start of a plan for how to make things significantly better. Additionally we need to figure out what timeline we can do what on. Not only will finding the proper solutions here take a while, a lot of this stuff needs to be standardized which means that it'll take quite some time before we can rely on cross-platform solutions. But we should figure out what we can build for now and ship in FirefoxOS. But this email is long enough as it is :) / Jonas _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
