We have trained users over a long period of time to think of sites/origins and not the actual code when making security decisions. The whole code signing discussion is a total distraction here. Web apps should use the same basic security model the web itself uses.
Andreas On Mar 17, 2012, at 3:13 AM, Panos Astithas wrote: > We don't currently prompt for permission to access geolocation information > when a website changes its code, right? The trust in the web model is > implicitly placed on the author (site), not the app (code). I would think > that this better matches how the user thinks about the process. > > Panos > On Mar 17, 2012 12:01 AM, "Jim Straus" <[email protected]> wrote: > >> Hello Justin - >> I don't think one precludes the other. If most apps don't need any >> escalated permissions, then none need to be granted and no signing needs to >> be done. Any code that the user has granted permission to can have it's >> signature generated and stored by gecko itself, no user interaction needed >> (beyond granting the permission in the first place). And if that code >> changes, the user will have to re-grant the permission. Again, no extra >> interaction from the user. >> Only if an app wants permissions granted a priori would some third party >> (who has a signing certificate) have to be involved. >> -Jim Straus >> >> On Mar 16, 2012, at 5:55 PM, Justin Lebar wrote: >> >>>> Anything that is granted permissions needs to be the same thing every >> time. >>> >>> I think we're going down a really dangerous path with this thinking. >>> >>> It's one thing to say that our super-trusted apps, like the dialer, >>> should be locked down and have every bit of code signed. >>> >>> But in my view, the vast majority of apps -- and any app you're going >>> to download from a store -- should have *exactly the same security >>> model as we apply to websites*. >>> >>> The whole point of our platform is that it's easy for web developers >>> to make an app, given an existing webpage. And one of the key selling >>> points of the web is that it's easy to change your code. >>> >>> Let's not shoot ourselves in the foot adding draconian requirements to >>> these 99% of apps which don't need any added protection. >>> >>> It's not even clear at this point that you'll be able to replace the >>> super-privileged apps via an app store, so I think this whole thread >>> of discussion should be dropped until such a time as we have a >>> super-privileged app we want to allow users to replace. >>> >>> On Fri, Mar 16, 2012 at 5:45 PM, Jim Straus <[email protected]> wrote: >>>> Ok, I think this has been said already, but I'm going go further... >>>> >>>> Anything that is granted permissions needs to be the same thing every >> time. If the thing changes, it needs to have all it's permissions reset or >> whoever is saying to grant the permissions needs to provide a new signature >> to authorize permissions. Otherwise why bother to have permissions. I'll >> go a bit further and say that is true for user granted permissions, though >> in that case,the signature can be generated in the browser/gecko itself. >> Thus, if I authorize some javascript (coming from some web site) to use >> geolocation, the permissions manager needs to store a signature of that >> code and verify it each time. This is different than the current system in >> Firefox. >>>> >>>> Following along this path, permissions aren't really granted to an >> application as a whole, but to specific code that makes up the application. >> So if other code is loaded, it would not have the same permissions . It >> also means that eval() has to do the same verification (thus eval() doesn't >> have to be restricted, but any code eval()ed would not inherit permissions. >>>> >>>> To answer Jonas, it doesn't mean that a store has to inspect all code. >> If the store wants to trust code based on contractual obligations, that's >> fine. But the code provided as being covered by the contract has to be >> signed so that it is known to come from that developer. And yes, if a >> developer wants to change their code, they will need to get it re-signed if >> they want it to have any permissions pre-granted. If they don't mind >> having the user manually grant permissions (through a dialog or the >> Permissions Manager app) then they don't need to bother the store. But the >> next time they change their code, the user will have to re-grant the >> permissions. >>>> >>>> On Mar 16, 2012, at 3:39 PM, Jonas Sicking wrote: >>>> >>>>> 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 th >> e >>>> 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-b2g mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-b2g >> >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> > _______________________________________________ > 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
