On Wed, Mar 14, 2012 at 6:30 PM, Justin Lebar <[email protected]> wrote: > On Wed, Mar 14, 2012 at 2:16 PM, Lucas Adamski <[email protected]> wrote: >> P.S. If that sounds a lot like a Feature Page, that's probably because it >> wouldn't be a bad starting point. >> Lucas. > > IME, developers have been traditionally hesitant to design using > feature pages, because there's no means for collaboration and > discussion in a feature page, save mediawiki talk pages, which nobody > uses (and for good reason).
tough. make it work. this is too important and fundamental an area to mess about with. if this was just a lovely bit of GUI code being developed, i would not care one bit how it was developed. you would not be hearing from me, and i would not be spending my personal time and money writing a single word. ... but it's not: it's *security* being discussed. and that means that you need to follow best Software Engineering practices [as applicable and relevant in a free software collaborative context]. if people don't "want" to make it work (time, whatever), then you - mozilla foundation dash B2G team members - compensate accordingly. allocate at least one person who has the time and inclination to follow in near-real-time to keep it up-to-date and to prompt everyone to continuously refer to relevant sections. yes by all means use the mailing list if that works best for you personally but the online document *MUST* be the "authoritative" document that is both living and also reflects as close as possible and as soon as practical the input from all contributors. and begins with informal discussion, morphs into a "functional analysis", from which "requirements specification" is written, and _then_ you start coding. > We're currently exploring an idea, collaborating, discussing, > debating. ... around a vast number of technical areas that cover (at the very least): * app distribution * kernel security * OS security * application security * network security of app distribution (evaluation thereof) * network security of apps once they're _running_ (evaluation thereof) * digital signing of apps * public key management * authentication * mirroring * UI design for permissions * app security APIs * developer documentation for app security design in other words there is a need to cover quite literally everything from how the app is written, right through its distribution, to minimising the security risks of untrusted apps, to enforcing permissions once running, to presenting the user with meaningful choices that impress upon them the importance of their decisions. as you can see from the above *small* list (which could potentially be used as the basis for the headings of the security wiki page), this project is very ambitious, very large, and it is absolutely critical to get it right. > All of this is IMO poorly suited to Mozilla's feature page system. well... tough. find something that works, or you _make_ it work. this is too important. there's far too much for people to cover here. so, may i respectfully suggest some rules? that: a) people take the time to refer to the wiki as the authoritative document b) people write "i've updated the wiki, area xyz, reasoning was as follows, please help review" c) if someone _doesn't_ refer to the wiki, that someone take responsibility to refer them to it. d) if someone makes a valuable contribution but _doesn't_ put it on the wiki, that someone take responsibility to gently prod them to do it or if they don't respond or are too busy, or it's easier, just do it for them (and of course say "i've updated the wiki"). l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
