> > If the user picks 'no', a well-written app should allow other > > functionality to work, but won't be able to use the camera.
Too many developers fall into this trap: If a user installs a camera application (some basic alternative camera), but denies it camera access - why would the OS even continue with installation? That situation represents an unfulfilled platform requirement (the same as if the device simply did not have a camera), which means the application is not going to be useful. A camera app without camera access can't have an appropriate fallback, it is simply non-functioning. That is an extremely poor user experience. You should also think about how complex such a UI would become - these are just the settings for camera access, which is definitely not the only permissions-based API camera apps would require access to. Now you're talking about a bunch of options for the user to turn on and off that fundamentally change the app's behavior. I seriously doubt any developers would be willing to write apps that account for every single case - you'll end up with a bunch of apps that throw up a "please grant this app all the permissions it needs to use it" dialog and be done with it. The developer of a camera app will not care that 2% of users got scared during installation by strongly worded dialogs and turn off the API access it requires. Those users aren't going to get a camera app anyway (it would be useless), so they shouldn't even be allowed to install it with such crippled permissions. This is why you have UI/UX people chiming in on a security discussion (much appreciated!) - this is so much more about working within the constraints of existing user habits than it is about API design. > A responsive permissions model could help build any kind of app, and > > giving the user total control over what it installs. The user already has control over that, because they make the decision to install the app after seeing a list of what high-level actions the app would be allowed to take. Also, isn't general mistrust of store-downloaded applications a more fundamental issue than one could hope to solve with a confusing development-centric permissions API? Most users **do not** understand the difference between "us[ing] custom camera interface" and "us[ing] the camera to take pictures/video" Perhaps there are two separate permissions models that need to be created here, based on the use-cases and issues that have come up so far: 1. Full access to Camera API confirmed during installation; or 2. In-app request for a specific type of camera access, granted (optionally permanent) by the classic "allow GPS access" type of dialog. Those are two different use-cases for camera access. One for apps that require access simply to be functional, the other for apps that can benefit from it outside their core functionality. - Jason _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
