On Mon, Mar 5, 2012 at 12:45 PM, Jim Straus <jstr...@mozilla.com> wrote: > Hello - > I definitely don't like the Android model. We'll have to figure out > exactly how to communicate permissions requests to users. On the other > hand, an appropriately vetted and signed app could be given permissions > implicitly in a permissions manifest, so the user doesn't need to deal with > it. Also, some kind of heuristics may make it possible for the permissions > manager to deal with things internally, again not bothering the user. These > are areas that need thought and experimentation.
There's been a bunch of research on the Android permission model in academia, including a bunch of suggestions for how to do better. If you'd like, I'd be happy to connect you with the folks who've studied this topic (off-list). > We will definitely need some sort of identification for web apps and sites. > Origin was the first thought, but if you have further suggestions, please > post. Maybe for network loaded apps/sites, permissions will need to be > re-goten from the user each time they are loaded (helps with, but doesn't > completely cure hacked sites). Maybe locally cached apps could keep their > permissions until they are re-installed. One thing that has worked well for packaged apps in Chrome is to use a public key in the URL to identify local content. For example: b2g-or-whatever://ankgjoopnopeoeljehjkighfcfefalcg/path/inside/package.html where ankgjoopnopeoeljehjkighfcfefalcg is a public key and "/path/inside/package.html" is a path inside a zip archive self-signed with ankgjoopnopeoeljehjkighfcfefalcg. This model is decentralized and provides a solid, secure foundation. It also plays well with the usual same-origin model for web security. I'm happy to answer any questions you have about Chrome's experience with this approach. Adam > On 3/5/12 1:25 PM, Lucas Adamski wrote: >> >> I like this proposal at a high level, it provides for a lot of >> flexibility. What I like about a permission model that can prompt at >> runtime is that is makes some permissions optional. On Android many free >> apps require geolocation purely for advertising targeting, requiring the >> user to trade their privacy for functionality. Those same apps, on iPhone, >> run just fine if the user denies them geolocation privileges. These >> decisions could be remembered for some finite amount of time (30 days), or >> indefinitely if you provide the user with the ability to manage them >> directly. >> >> The downside of prompting at runtime is that it does need to map to >> permissions an average user could hope to understand (hello user research?) >> Asking for location, contacts, etc seems like a reasonable question to ask >> the user. Asking the user to change the network proxy settings or fiddle >> with your email settings, maybe less so. The latter might be better bundled >> into a general "scary system access" category. >> >> The origin problem is still a tricky one. Browsers overall still rely on >> same origin as the only meaningful security boundary (including work on >> iframe sandbox, CSP, etc.). I'm still skeptical though that alone is >> sufficient to authenticate apps that would have "system access". A web >> server is generally a much easier thing to compromise than a code signature. >> >> Adding dev-security for more brains. >> Lucas. >> >> >> >> On Mar 3, 2012, at 2:44 PM, Jim Straus wrote: >> >>> Redirecting to the public list and to the webapps team, with some >>> additions... >>> >>> Hello all - >>> I've been thinking about what the permissions model of b2g might look >>> like, so I'm putting down my ideas to solicit feedback and see if we can get >>> this going. A lot of the components and services we've been building are >>> all waiting on a permissions design. >>> >>> Permissions in b2g are needed for access to services and data that is the >>> user might not want to allow an app to access. Examples include the users >>> current location (geolocation), contacts, making phone calls, maybe even >>> cellular data connections (if the user wants to control their costs), large >>> storage areas, etc. We'll have to decide the entire list as we go along. >>> >>> I envision two user interfaces needed, the dialog/bar/whatever that asks >>> the user for permission, and a permissions manager app where the user can >>> revoke permissions, a priori grant a permission to all apps for a component >>> (like always allow cellular data connections if the user has unlimited >>> data), and to see what permissions exist and what apps have been granted >>> permission. The permission request user interface would allow for the user >>> to grant/deny permission once or permanently. If permission is not granted >>> permanent, the next time the service/component is invoked permission would >>> be asked for again. I also would like to make at least the permissions >>> manager be able to be changed to a non-built in app, if we feel we can >>> maintain security. >>> >>> The generally discussed model is that permissions are requested as a >>> feature is used, on a feature by feature basis (unlike Android's permission >>> model). However, there is nothing in particular about this design that >>> would prevent us from adding a permission manifest to the webapp manifest >>> that could do it wholesale when the app is loaded or launched, if that was >>> desired. It is also possible (but I'm not sure desirable) we could allow >>> for apps to have per-asserted permissions for appropriately signed and >>> validated webapps. >>> >>> My idea is that there is a permissions component that handles all the >>> internal work. The permissions component is also protected by a permission, >>> so that apps can't change the permissions without the user knowing. The >>> permissions component stores webapp signatures (originating url?, is this >>> un-spoofable?) along with the permissions permanently granted/denied in a >>> protected indexedDB. Components would query the permission component when >>> the component starts for a particular context and permission is returned >>> about whether permission is granted (by user interaction or previously >>> stored permission). Apps could possibly also explicitly ask the permission >>> component about the state of their granted/denied permissions so they could >>> handle denials in a graceful manner (this would not have to be protected). >>> >>> The permissions component can (and will) become more intelligent as we >>> figure out the right things to do. We can try to infer permissions in some >>> cases. Apps signed as having come from a site known to validate it's apps >>> and signed as having come from a known developer can have per-autherized >>> permissions in their webapp manifest (an extension to the webapp manifest >>> will be needed). Webapp manifests could be used to request permission once >>> when the app is installed. Or some combination of any or all of these. Or >>> something else. If the components are all using the the permissions >>> component, it doesn't matter to the rest of the system how the permission is >>> obtained, just that it is either granted or not. >>> >>> My thought is that the permission manager app would be internally >>> restricted to only being able to get the permission granting permission (is >>> that confusing enough), so that a third party permission manager would not >>> be able to secretly subvert other parts of the system. That still may not >>> be secure enough, so it is possible that we would not be able to allow the >>> permission manager app to be replaced. The permission granting to the >>> permissions app should not be able to be denied permanently so that the user >>> can't be locked out of controlling permissions. A full threat model and >>> consideration needs to be done here to figure out what is possible. >>> >>> I'm hoping that we can provide the ability to query the permission >>> component in a simple way in the .idl files so that every component doesn't >>> need to add in explicit code all over the place. This might either be done >>> in the .idl compiler or through an include in the .idl files. >>> >>> Note, this same architecture should be available for webapps in general, >>> and even non-app web sites in all other Mozilla browsers that need it. It >>> should also be proposed as a standard along with the webapp standard. >>> >>> To progress with this, we need several things. Someone with expertise in >>> webapps that can answer questions about whether webapps can interact with >>> other webapps, what should be used as a signature for a webapp/sites. >>> Someone to do a threat model and look at security considerations to make >>> sure we're covering all the bases of where a malicious webapp/site might >>> bypass the permissions model, and to see if the permissions manager app can >>> be replaced by a third party app. We need UI design and implementation for >>> the notification/dialog/etc. for asking the users permission. We need UI >>> design and implementation for the permissions manager app. We need >>> implementation of the permission component. We need .idl extension/include >>> for easily adding permission requests to components. >>> >>> Thoghts? Comments? >>> -Jim Straus >>> _______________________________________________ >>> 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 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
