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
