On Wed, Jun 27, 2012 at 12:06 PM, Lucas Adamski <[email protected]>wrote:
> Thanks for forwarding this! Rather timely as I am looking at > https://bugzilla.mozilla.org/show_bug.cgi?id=768881 > > Its a valid point that features are different from permissions, so my > initial take in the bug is probably wrong. > > But I'm concerned that if we categorized permissions by "required" vs > "optional" that would be confusing and fundamentally incorrect. Implicit > permissions are permissions that can be granted to a given category of > applications without user involvement (but still needs to be enumerated in > the manifest); explicit permissions are ones that need to be approved by > the user. Having two groupings in the manifest could give developers the > mistaken impression that they can take an explicit permission (say camera > access), and just put that in the implicit ("required") section of the > manifest instead and no longer have to ask the user. > > Since the behavior of the permissions is a function of the particular > permissions being requested + type of application, breaking these out in > the manifest doesn't seem beneficial. > I feel like we're combining a couple different things here. I'd split things like this: 1) There are features the application requires, and without those features the application can't do anything useful. If the feature isn't possible to support (e.g., telephony on desktop) then we should stop the user from buying the app in the Marketplace, or installing the app from the cloud. 2) There are features the application wants, but doesn't need. It enhances the application in some way, but lack of the feature doesn't stop the app from being useful. There are also three kinds of features: a) Features that either exist or don't, but are available to any content. Flash is a good example of this. B2G phones won't support it, other devices will, some apps might require it. An app that can optionally use Flash shouldn't need to declare that at all. Maybe WebGL also fits here. b) Features that we are willing to give any app, without user consent, but aren't willing to give (without consent) to just any content on the web. Maybe IndexedDB would be an example. c) Features that require user consent always. Maybe the Contacts API? ---- The combinations: 1a) If an application requires a feature that is requires no permissions at all, like Flash, then it's just a way of indicating what devices will support the app. 1b) If an application requires a feature that doesn't require user consent, it can be pretty confident it will get that feature, if it is allowed to install at all. But, if it requires such a feature and some user agents don't provide that feature, then the application can be confident when it runs that it'll have that feature, but the app won't be available on some devices. For instance, if the app requires camera support (I'm not sure of the terminology, but I'm thinking mediated support with privacy protection), it won't work on a device without a camera, but if it is installed it should have camera access. 1c) If an application requires a feature that requires user consent, we're into the Android permission model, where the user is given an ultimatum: "give me this permission or I won't install". Yuck. But I think we've decided that we aren't cool with that, and that the permission should be granted contextually (i.e., in the application at the time the permission is being used). Is that still the plan? In that case, we are saying that the 1c combination merely means the user *could* give the application the permission, i.e., the capability exists. The app won't be installed onto a device that simply doesn't support the Contacts API, but once installed the user is still free to reject the permission request. If the user rejects the permission and the app fundamentally needs it, it is up to the app to signal that. 2a) This could mean that a feature is desired but not required. So far we've decided to skip this. Depending on what "optional" means, this might mean nothing – that is, we don't imply that missing optional features imply a degraded experience (or it might be degraded only in terms of performance or energy use, which we can't explain well to the user). 2b) This means the feature is desired and needs to be requested (i.e., it's not available to general content), but a device that doesn't support the feature is still okay. 3b) This is basically equivalent to 2b, except the app needs to be ready for the API to exist but the permission to be rejected. "required_features" vs. "optional_features" seems to distinguish between 1 and 2, but I wouldn't want to overload it to have some meaning with respect to a/b/c. I'm not sure if we need to distinguish a/b/c in the manifest or specification at all? Of course it still implies a great deal for our UX. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
