I've had a read over the wiki page and there's certainly a lot of information to take in and I think there's lots still to discuss.
Here are some of my (slightly naive) questions and opinions on what's been written so far... == Distribution/management of WebApps == "A telco can decide which stores to implicitly trust on their devices" - what does this mean? == App instance/version == Number 2 sounds closest to what I see a web app as. * A web site which hosts an app manifest which provides a name, description, icons and lists permissions the app may ask for * Once "installed", the app's origin (or list of origins, or subset of an origin defined by a path mask in the manifest) is granted certain additional permissions by the user (or can ask for them at first use) and resources are downloaded and cached as specified by an app cache manifest, if provided. These cached resources will not be removed from the cache without user's consent. * When the appcache manifest is updated on the server, new versions of resources may be downloaded and cached locally. == Types of runnables == 0) None of the items listed here (drivers, cli tools, browser engine or plugins) should be handled by Open Web Apps, but rather a separate process. Out of scope. 1) Web apps should never be "packaged" in the sense of a bunch of assets zipped up into one file and downloaded, they should always be hosted with a every resource having a persistent, unique URL. Otherwise they're not "web" apps, they're just apps. 2) All web apps should be non-local web apps, but with the ability to cache resources locally. 3) Non-installed web apps are essentially web sites viewed through a browser app, or bookmarks. 4) Gaia apps will still use the Open Web Apps system and Gaia apps will be in the Mozilla Marketplace, we will just pre-populate the appcache and installed manifests at the time of shipping a device. == Trusted store with permissions delegation == Surely there should be no central authority for permissions requests other than the user? Yes, listing requested permissions in the manifest seems sensible, although not essential if permissions requests are not made up-front at install time. Still useful for information purposes for the user though. Why would a root store be able to grant permissions on behalf of the user or delegate that right? Why does the store have anything to do with what permissions a user wants to give to an app? Is this because of regulatory restrictions on dialer and homescreen apps? Surely an app from any store (or self-hosted) can ask for any permission, it's up the user to decide whether to grant it. Self-hosted apps should not need the intervention of a store for a user to grant them permissions. == FLASK == Huh? This doesn't sound like the web. == Debian Keyring (Package Management) for distribution of apps == I love Debian, and apt. But their place is on the dekstop or server to install native applications and their dependencies - not web apps. Web apps should be hosted, not packaged. How do you sign code that's constantly changing? Sometimes when web apps are updated there are different versions of resources on different nodes of a cluster behind a load balancer, or different versions of the app are rolled out to subsets of users at a time. How can you sign code in this environment? I trust this origin to do these things, sometimes I want proof they really are who they say they are, and sometimes I want them to ask me before they do something. Isn't that enough? == Permissions manager == Users should definitlely be able to view the permissions which have been given to which apps and change those permissions at any time. == Other == SSL shouldn't be mandatory for all apps, but maybe for apps which request certain sensitve permissions. "It's just a stopwatch, why does it need encrypting?!" You should be able to self-host an app and have a direct relationship with the user, without the involvement of a third party (store). -- Ben Francis http://tola.me.uk _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
