On 19 Jun 2014, at 6:28 am, Ehsan Akhgari <[email protected]> wrote:
> Thanks for writing this up, Jonas! > > Here are a couple of questions: > > 1. If we only allow access to privileged APIs to resources that are served > from the "package" source through CSP, would the concern about injecting > inline scripts from the same origin into the code running inside the package > remain? Yeh I was thinking that too. But then we also need to consider DOM access too I think? Consider a gallery app hosted in this manner: scripts from the same origin my be prevented from executing code in the packaged context and using device-storage directly to read photos (for example), but they could just access the photos loaded in the DOM couldn’t they? > > 2. How well do packages play with HTTP/2? One side effect of using packages > that you need to download all of the code for the application in order to > verify the signature (assuming that we won't have per resource signatures), > but HTTP/2 would allow you to only download the resources needed for the > current document in a minimum number of HTTP transactions. It's not > immediately obvious to me how we can reconcile these two models… > > Cheers, > Ehsan > > On 2014-06-18, 2:28 PM, Jonas Sicking wrote: >> 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 >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
