To aid the discussion of controls vs threats, I have drafted an initial list of threats with associated controls here: https://wiki.mozilla.org/B2G_App_Security_Model/Threat_Model
I have tried to include all threats/controls raised in the thread so far, but I have no doubt missed or misinterpreted some, so please feel free to contribute to this page. At the moment it is very high level, in line with the debate, but I expect to evolve to being more specific and quantified once we get closer to a design for the permissions model. My own two cents on the "Gaia" apps - I am not sure if Gaia apps is the right term for the security discussion. My understanding is that most of the apps that were included in the Gaia project are not critical system applications (games, camera, image gallery, clock etc). But it did include some that are definitely critical (dialer, sms, browser,settings app) and some which are in between the two. But the name is besides the point. Personally I don't think one set of security requirements is going to fit all of the Web Apps that will be installed on all B2G instances. I'm not sure if using the term Gaia/non-gaia apps is the best distinction, but I do think we need a different level of requirements for angry birds, than we have for critical system Web Apps. And I think this control needs to be beyond HSTS and trust in app stores to control their developers/infrastructure, due to the threats outlined in the linked page above. On Mar 17, 2012, at 4:49 AM, Justin Lebar wrote: >> Yes, clearly OWA was not designed with Gaia apps in mind. To be blunt, my >> opinion at this point is that a model with no code authentication or >> controls on importing code over plaintext channels, is insufficient for a >> privileged application like Gaia. It would leave Gaia apps open to the most >> trivial MITM attacks. >> Lucas. > > I understand the bit about code authentication. If the web server > gets hacked, we're screwed. > > But surely well-functioning Gaia code would only load code over HTTPS, > so I don't understand where this MITM attack comes from. > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
