ok, apologies for asking this / chipping in. here's an assessment, from an "outsider's" perspective [one with software engineering experience and 10+ years of being a lead developer of free software projects].
* this is a _massively_ complex area with far-reaching implications for not only the success of the whole B2G project but also for the codebase required to make it a success. * the discussions so far qualify as informal "functional analysis". * there's been no mention of a "requirements specification". * there's no mention been made of a wiki page in which everything is being collated. as a lead developer of free software projects i absolutely insist that people collate "static information" into wiki pages, regardless of its source (irc, mailing list, private discussion) _and_ that they reguarly refer to that wiki page as the authoritative source. if they don't do that, i pitch in to the conversation, recording in some cases verbatim the relevant sections of the posted message onto the wiki. * there is however a single mention of a bugreport, instigated by jonas. if i was actively employed and paid to work B2G by the mozilla foundation i would informally chip in and help in this way, but i am not being so paid so i will not be doing so until such time as payment _is_ received. so it is down to you. why am i mentioning this at all? because linux on smartphones is something that is of particular interest to me, and after having seen the messy consequences for free software of android i'd rather it didn't happen again. so. you can see that this is a complex area, given the length of the write-up by jonas, and also the length of the reply that i sent. security isn't something you can add in "after the fact" - it has to be designed in *from the ground up*. can i respectfully suggest that you begin by creating a wiki page and that someone takes responsibility for ensuring that everyone refers to it or that the mozilla foundation pays someone to specifically pay attention to this rather important area? i would recommend beginning with the 3 points a) b) and c) (reminder below) which can be utilised as the top-level headings for the Functional Analysis, and you can then move forward by linking to the various discussions from there, as well as moving on once the issues and implications are fully understood to the Requirements Specification. for example: in mentioning the debian project, the successful digital-signing of source code of the application works *only* if the source code of the app is actually available. with that in mind, are there plans to: * make damn sure that apps only *ever* are in source code form (e.g. javascript)? * allow any other programming languages into the mix? (python a la pyjamas-desktop or a la pyxpcomext)? * add this "assembly-level" thing which google chrome has added? this latter will have serious consequences for security. arbitrary code execution with access to the NPAPI through XPCOM at the assembly level would be both fun _and_ scarey! but if that is planned some time in the future, you simply can't have "random apps" being downloaded and expect them to be secure. if such a strategy (execution of assembly code) is OUTRIGHT BANNED and will NEVER BE CONSIDERED, then and only then can the security model be dramatically simplified. basically what i'm saying is that you a) need to think about these things b) need to document them for input and review c) need to _tell_ people where they can go to review things d) need to make it easy for them to review it. the implications are too big to just walk into this blind. l. copy of points a b and c you've got several issues to cover: a) the distribution of applications, and ensuring that the chances of rogue apps entering the market are reduced in the first place b) the management and granting of permissions for access within apps to certain APIs c) the *enforcement* of permissions on the actual physical devices _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
