On Thu, Mar 15, 2012 at 10:45 PM, Ben Francis <[email protected]> wrote: > 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.
he he - yeah it's a monster area this. > Here are some of my (slightly naive) questions and opinions on what's been > written so far... eyy, new eyes are always valuable. > == Distribution/management of WebApps == > > "A telco can decide which stores to implicitly trust on their devices" - > what does this mean? i've updated https://wiki.mozilla.org/Apps/Security#Distribution_.2F_management_of_WebApps to provide an analogy which helps illustrate. > == App instance/version == > > Number 2 sounds closest to what I see a web app as. yes.... yet... conceptually, think "what if that https:// link was to a web app and the file extension of that web app was '.deb' or '.ipk' or '.rpm' "? it's an https link, right? therefore it's a "web app"? :) > * A web site which hosts an app manifest which provides a name, > description, icons and lists permissions the app may ask for all of these things can be covered by .deb or .rpm (not sure about .ipk it's a bit simplified) > * 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. /var/lib/dpkg/ etc.... > * When the appcache manifest is updated on the server, new versions of > resources may be downloaded and cached locally. apt-get update followed by apt-get upgrade :) you see how simple that is? and, importantly, how little code/infrastructure needs to be written in order to meet - and exceed - the requirements? > == 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. why is it "out of scope"? how should the B2G application (B2G the executable) be packaged and upgraded? what about the linux kernel, and other support infrastructure? whose problem is it to define the security and secure distribution of all those components? this is a serious question (one that i meant to raise given the misleading nature of the name picked for the wiki page, which implies that the discussion's scope must specifically be limited and restricted to "app" security *only* when in fact it's critical to consider the whole deal) > 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. ok... so if that's allowed, then as that adobe AIR security document explains, you now need to create a separate security context which restricts what that code can get access to. however that's not to say that there is not room for *both* types - "apps" and "web apps" as you've distinguished them - is there? the fact that they could both be written as JS/HTML (and python if i had my way... *sigh*...) doesn't actually have anything to do with it. (convenient link to the AIR intro) https://www.adobe.com/devnet/air/articles/introduction_to_air_security.html so, that means needing a glossary which explains the difference. and a security model devised and discussed which covers each. but... you know what? now that i think about it, i _really_ don't see the difference between "app" and "web app" as you've defined it, if you create a new URI type such as "apt://{packagename}" or "yum://{packagename}". think about that for a minute. if you define the concept of "remote web app" to be "a dynamically downloadable gaia app", you still have to do security vetting, you still have to cache it locally, you still have to present the user with the opportunity to vet its permissions... so in my mind, there's no difference between "remote web app" as you've defined it and "just an app" as you've defined it, once you've created that uri type "apt://" or "yum://". you see what i'm saying? plus, yeah, crucially, some apps may require upgrades of other functionality (dependencies) - how would a "remote web app" keep everything up-to-date if it's not hooked into a proper dependency management system? > 2) All web apps should be non-local web apps, but with the ability to cache > resources locally. _should_ be is a strong word, ben :) > == Trusted store with permissions delegation == > > Surely there should be no central authority for permissions requests other > than the user? ah - yes. but are the users technically competent to evaluate the safety of the code? no, they're not. they haven't got time. so whilst the word "permissions" is the wrong word to use, the concepts in this section are still kinda sound. > 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? yes i did wonder about that one. i believe this whole section may have confused various concepts together, using the word "permissions" to refer to delegated trust that is inherent in digital certificates. ultimately this is about trust. in the absence of time and technical ability of the user to do a full code audit, can the user *trust* that the code executed on their system is safe? someone else makes a declaration, "i believe this is safe" and then digitally signs the code. private/public key signing can be delegated, if you put the right infrastructure in place. > == FLASK == > > Huh? This doesn't sound like the web. yeah, i know. AIR security does not "sound like the web". android's security model "does not sound like the web". you still have to have it. > == 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. that's... i'm not going to judge your opinion, ben. > Web apps should be hosted, not packaged. the only difference between "hosted" and "packaged" is a matter of the uri (or file extension type). > How do you sign code that's constantly changing? you don't: it means it hasn't been audited. thus it should not be trusted. thus it should not be allowed through the "normal" channels. my opinion is: if you _really_ want "constantly changing" code, then all bets are off. btw, somewhere buried in the looong list, only 48 hours ago (!) the idea of bypassing the packaging system (and the security system) was discussed: the idea was proposed to allow intelligent people to install stuff in the B2G-conceptual-equivalent of "/usr/local" > 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? exactly. > 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? yes... but the devil is in the details :) > == 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?!" i believe you're confusing the difference between a need for secrecy and a need for validation. > 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). yes. the analogous equivalent is that of e.g. debian-multimedia.org which mr marillat happily maintains. another example: i worked with phil hands on a small project, we actually set up a debian-formatted repository for that purpose. that repository was "self-hosted". it meant adding a line "deb http://hands.com/~phil/debian main" or something like that to the /etc/apt/sources.list. (as that was almost 4 years ago now, before the apt-keyring stuff, we didn't create a separate keyring package like mr marillat has) but if that's "too complicated", another way to allow the "self-host" concept is to allow ".deb" or ".rpm" to be easily downloaded and installed. that will still end up going through the security review and permissions process. beyond that, if even _that_ is "too complicated" for people to "self host", then you always have the B2G-conceptual-equivalent of /usr/local as a fallback. l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
