I think the idea is the opposite: to make it easy and common. Not saying its risk-free. :)
In other news, we have started a feature page for the B2G app security model. The idea is to work through the current list of open issues in a (somewhat) structured process and capture the resulting decisions and logic here: https://wiki.mozilla.org/B2G_App_Security_Model The current wiki page (https://wiki.mozilla.org/Apps/Security) is still very relevant; its more of a freeform way of capturing ideas, issue and discussions that will then feed into the design on the feature page. The current feature page is just a bare start, and not everything will fit in there. You will note a link to a threat model, for example. The next steps are to validate requirements, and determine the open issues. Please comment upon those here and either Paul or I will update the page accordingly. >From there we'll burn down the open issues list into a functional design. Lucas. On 3/14/2012 6:34 PM, lkcl luke wrote: > On Thu, Mar 15, 2012 at 1:24 AM, Lucas Adamski <[email protected]> wrote: >> I'm interpreting this idea as something much 'worse' than that. I'm >> suggesting that the most common B2G app would live >> on a server with no particular signed package. They would be dynamically >> fetched and locally cached. This is fraught >> with problems, some security and some simply usability/reliability (i.e. how >> to ensure the >> completeness/freshness/integrity of the local app cache). > yes. absolutely fine. i strongly suggest that you make it really > really difficult for people (from a UI perspective) to do this sort of > thing. > > 1) go to a dialog which is right at the bottom and says "enable > untrusted apps". > 2) then force them to go through a process of "enabling untrusted > networked apps" > 3) then warn them of the consequences. > 4) then refuse to allow the untrusted app to even run. > 5) then force them to go to the *permissions* page saying "enable > permissions for untrusted apps" > 6) then force them to "enable permissions for networked apps" > 7) _then_ force them to go through an extra "this is an untrusted app > from a network. do you really want to grant this?" on *every* > permission. > > or some-such. > > if they don't _like_ that, then what will happen is that someone > *else* will write a replacement for the permissions application which > takes *away* all of that - and installs an application which just goes > "yes yes yes". > > at which point, it's not your problem. > > actually if you wanted a "step 0" you could actually make it an app - > which is on the equivalent of "debian unstable" - which enables all > that functionality 1-7 above, so it's not even *possible* to > (normally) bypass the security unless you really really actually > actively want it. > > step -1 would of course involve adding to /etc/apt/sources.list [or > equivalent] that line which has the "debian unstable" thing in it, > which makes it even _more_ difficult :) > > or... you just ignore all that, let them do what they like, and it all > goes to hell in a handbasket very quickly he he. > > l. > > >> Lucas. >> >> On 3/14/2012 5:12 PM, lkcl luke wrote: >>> On Thu, Mar 15, 2012 at 12:05 AM, Lucas Adamski <[email protected]> >>> wrote: >>>> In fairness, its worth considering that a better overall user experience >>>> could be obtained by having apps dynamically web >>>> hosted without an explicit update process, because >>>> a) it maximizes the community that can participate in building really >>>> great apps (without having to figure out code >>>> signing, versioning, Debian package management, etc) >>> yes - and likewise any debian user knows that if they go download the >>> source code of an app and compile/install it themselves, they are "on >>> their own". >>> >>> hmmm, that's a good point. it would be a good idea to have the >>> concept of /usr and /usr/local within B2G to recognise this. >>> >>> so... "...../gaia/usr" for pre-vetted "official" and "stable" stuff, >>> but "...../gaia/usr/local/" for stuff that people want to put on there >>> and do development. >>> >>> the problem comes of course when people start doing that en-masse, >>> but that's their problem: they just "voided the warranty" anyway. >>> so.... don't make it too easy, would be my advice! :) force them to >>> get root access or something, make it part of the developer >>> documentation and bury it deep. only the patient and the intelligent >>> would find it :) >>> >>> l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
