My understanding is that there will be multiple app stores. But code signing has another benefit: reducing systemic risk.
This assume code signing and sane key management, but lets say there's a very popular app with significant privileges. To compromise a large number of people, you'd need to: a) compromise the site hosting the app b) compromise the key signing the app (assuming you require app updates to be signed with the same key) c) compromise or trigger the update mechanism for the app d) wait for updates to trickle out This is a tedious process that slows down exploitation, and that's no fun. If app authentication relies only on SSL, then you just need to pop a web server (which isn't hard, really). Everyone using the app gets owned simultaneously. Lucas. On 3/11/2012 6:11 PM, David Barrera wrote: >> how do you prevent this from happening? jim has described the >> problem space, very very well. it turns out that there already exists >> a near-perfect solution to that problem (debian packaging). SSL is >> like... waayyyy down at the bottom of the infrastructure that is >> *used* by those solutions. > SSL works well for authentication and as Jonas points out, it is well > understood by developers and the community. If B2G apps will *only* be > distributed through a single store, then SSL can provide the > authentication you need without the overhead of a signing/verifying > infrastructure. If there is going to be more than one app store, or > developers can distribute apps on their own, then I think it is > sensible to think about digital signatures. > >> l. >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
