On Mar 15, 2012, at 12:16 PM, lkcl luke wrote: > Some time ago, Paul wrote this: > >> How do domains which install themselves as Web Apps fit into this model? Is >> there perhaps a default lower set of permissions that websites can install >> themselves with - basically the same types as websites, except that with >> apps permissions might be able t get "prompt to remember" instead of just >> "prompt"?) > > paul, hi, > > what do you mean "domains which install themselves as Web Apps?"
Pages which call navigator.mozApps.install(<their own URL>) rather than be installed from a trusted store. I believe that the idea is that they just won't be a trusted store, so they won't get sensitive permissions. Response from a previous email was: >Such store's generally won't be trusted. So those stores will work >just fine, however they won't be able to install apps which need SMS > privileges. I.e. this wouldn't be for internal phone apps (gaia-esque) but for more web page style apps, that want the installed app user experience, but don't need sensitive permissions and so don't need to go through a store. Or that is how I understood it. I'll make a note on this in the wiki. > > are you envisaging, perhaps, that a Gaia Application (which is merely > source code) be made available from, instead of the local filesystem, > off of a remote one? > > because if so, i have an idea that has some... eeenteresting implications. > > the idea is very simple: you don't complicate B2G by forcing it to > understand loading of Gaia apps from other sources, you use something > which is well-known called "mount points" and "networked filesystems" > :) > > so, you get an app (which is of course signed, and of course has a > permission-set in it). > > the permission-set is necessarily complex, because it not only mounts > a networked filesystem (nfs, HTTP, andrewfs, whatever) but also has to > offer up an explanation as to why in hell it's doing this. > > (all of these permissions can easily be covered by SE/Linux btw) > > now, what's _really_ neat about the use of the debian packaging system > to do this is that you *don't* need to arse about: you can just do > "apt-get install nfs-client" or "apt-get install fuse" along with > another package that does the mounting etc. etc. > > you could even have a package which does cacheing (for off-line > situations) of the remote filesystem and it's *not* your problem (i.e. > it's not a B2G coding problem). > > > the question is, however: why on earth would you a) want to do > something like this b) want to _allow_ something like this? > > technically it's cool; technically it's a variation on the "google > chrome OS" theme, so technically yes it's kinda neat *if* you think > that google chrome technically stands a snowball in hell's chance of > success. > > but it makes me nervous because if you're offline and there's no > cache, you're hosed; secondly, the users reaaalllly have to trust that > remote site; thirdly unlike the debian packaging system which does not > require secure transfer of the package (containing the app) because > it's digitally-signed securely, if you download apps over the network > you now HAVE to use SSL, authentication etc. because otherwise you > expose users to man-in-the-middle attacks etc. etc. > > overall, it's absolutely absolutely fricking cool to have dynamic > domain-grade loading of B2G/Gaia apps, but to be really honest, if you > want "dynamic apps" then just for goodness sake demand that people > upgrade the app. > > upgrading the app will achieve exactly the same effect, but will force > the developers to go through a proper formal review process. > > if you allow dynamic apps you just allowed them to bypass all the > security. that's baaaad :) > > l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
