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" <jstr...@mozilla.com> 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 <jstr...@mozilla.com> 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 <jstr...@mozilla.com> > 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 > >> dev-...@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > dev-b2g mailing list > dev-...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
