On Sun, Mar 11, 2012 at 6:51 PM, Jim Straus <[email protected]> wrote: > Hello Jonas - > The problem I'm trying to solve is knowing that the app I think I'm getting > is the app that I'm getting. SSL doesn't do anything to solve this, it just > protects the privacy on the wire, not what is actually going through it. If > a store wants to assign elevated permissions of any sort, I want assurance > that the app they are providing the elevated permissions to is the app that > I'm getting. It does't matter if the store is validating the app by hand > inspecting code, doing some automated inspection, contractual obligations, > the word of the developer, whatever. If they are asserting that the > application is to be trusted with any elevated permissions, I don't want to > get something else. Code signing doesn't tell me what an app does, just that > it is the app hasn't been modified. Either through a developer changing > their application, a hacker breaking into a site, or anything else. If the > developer does want to update their app, I want to the store to re-assert > that the new app should be able allowed to have whatever permissions it is > granting, not just the developer doing it unilaterally. I suspect that > stores will compete partially on price and breadth of offerings, but also on > their assurances that the apps they are providing are safe. > Actually, in thinking about it, I think that stores that sell apps that come > from a third party server are more secure, not less as a hacker would have to > obtain the ability to sign an app and also break into the third party server > to affect a change. And they would have to hack into another server to > affect a second app. If a store hosts everything themselves, hacking that > single server and getting the ability to sign apps would expose lots of apps > to being hacked. > Black listing based on scheme/host/port is probably not sufficient for an > organization that distributes more than one application. This was raised in > a different discussion related to web apps in general. But even if it was, > we may want to blacklist a particular version of an application, not the > application in general. The signature provides a mechanism for this. > I agree that removing permissions for some application infractions might be > a good idea. The actual semantics of what the black list can do to to a > particular app can be discussed and enumerated. But there will definitely be > apps that we want to completely disable (eg. if we find an app is hijacking > information, I don't want it running at all.)
I have to admit I've lost track of what it is that you're actually asking for. "knowing that the app I think I'm getting is the app that I'm getting" depends highly on the definition of "the app". As I've stated, I don't want to force app developers to have to their code inspected by stores, nor do I want to force stores to review developers code. And if a code review hasn't happened I don't see what signing the code buys anyone. Instead I want stores to verify that they can trust a developer through things like contractual means and restricting which set of privileges they give an app. It has also been suggested that stores should be able to require certain technical security measures from the app, like EV Certs and/or certain CSP policies. This sounds like great ideas to me. Likewise, it would likely be a good idea to have minimum requirements on stores that they use things like EV Certs and CSP policies. If we do this, then we can use SSL both go guarantee that the code that is delivered to the user is the code that the developers have authored, and the security policy that the store intended to entrust the code is the policy that is delivered to the user. / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
