At this point I'm just raising possibilities. If we go with something close to option b), then we have to figure out how to deal with a set of threats not really present in other app stores. It doesn't preclude us from doing so, but we might for example have to require a relatively strict CSP policy for apps to reduce the risk of MITM attacks for example, or CA pinning.
I don't know of any way to mitigate the risk of server compromise without code signing, though. Short of having a two tier system (more privilege for "installed" apps, less for "remote" apps), but I'd really like to avoid that. Lucas. On 3/14/2012 2:50 PM, Fabrice Desré wrote: > Lucas, > > Are you considering signing the html/js/css/other-content from apps? > > I can understand the nice properties that would give us, but that looks > extremely impractical in real life. Web sites > change all the time, which is not the case of native apps distributed from a > store. > > Fabrice > > On 03/14/2012 02:35 PM, Lucas Adamski wrote: >> 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. > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
