On Mon, Jun 23, 2014 at 6:01 AM, Gervase Markham <[email protected]> wrote: >> 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. > > Maybe this is a stupid idea but: should we make it part of the standard > that packages be nestable?
We should yes. But... > I.e. I could have foo.package which contained > an app, but also contained bar.package which was a set of subresources, > perhaps those that needed certain permissions. So the user could load > and start using foo.app, and we could check the signature on bar.app in > the background but only when a resource in it was referenced and loaded > would there be permissions-related UI. > > http://server.com/url/to/foo.webpackage!//subapps/bar.webpackage!//index.html > > Outer and inner apps would share the same origin and be able to > reference one another's files. ... we should not do this. Mixing trusted and untrusted code in such a way that they can directly call each other is RealHard to do. In gecko we have done this for a long time since we allow trusted chrome code to call and interact with untrusted webpage code. We've had about well over a decade of security problems with this and it's only just now starting to get a handle on it. To do this has required lots of C++ hacking to create various security wrappers which enforce certain constraints which would have been next to impossible to implement correctly in JS. And the only reason we are able to do it even in C++ is by using deep hooks into the JS engine as well as relying on the fact that the trusted and the untrusted code runs as separate origins. To enable webpages to do anything similar would require us to expose a bunch of new wrapper APIs and other functionality which so far is very Gecko specific. And it still would rely on developers to stay on wander through a minefield of ways of messing up. So this is not something I'm particularly eager to do. Potentially it's something we'll do one day, but not now. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
