I like the original thinking that is going into trying to avoid specific permission prompts and use implied consent. I have some questions and concerns, so I'm going to go through a scenario and see if I'm understanding correctly and solicit thoughts on some issues.
Scenario: A camera that takes antique style pictures, including showing the antique style in the preview, that wants to geotag the image and upload to a photo-sharing site. Possible implementation, given previous discussions here and on "WebAPI Security Discussion: Camera API": App opens the camera, bring up a system preview, supplying a shader to do the antique styling. There is a system shutter button to take the picture (that can't be click-jacked or hidden). At this point, I'm not sure how the geolocation is granted. I don't think we want a second "apply geolocation" system button that the user has to know to press. Maybe this is common enough that there is a special system shutter button that grants both permissions, or we need a permission dialog to appear. The user then sees the captured image and can apply whatever other transformations desired (cropping, rotating, brighten, etc.) On the captured image page there is a system "upload" button that is labeled by the app with the destination. Pressing the button grants permission to communicate with the photo-sharing site to upload the photo. Specific concerns are that apps that need more than one implied consent require users to know what to touch. In the case of a geolocation button (often a circle with cross-hairs on iOS), how does the user know that they need to press that in addition to the shutter button? If we start combining common permission patterns (geolocation with shutter, for example), how many do we end up with, will users know what they are granting, and what about a user who wants to take a picture but not tag it with the location? Can we make clear enough buttons for most (all) of the permissions? Shutter is particularly easy. Geolocation in some cases is pretty easy. What does an upload button look like (that is distinguishable from other buttons?) How does the upload communicate where it is going to upload that is not spoof-able by an application? Can an upload button protect from an app uploading other information? What does a Socket button look like? Or NFC, or even calendar or contacts? Can all permissions be moderated by user initiation? Will apps be made less convenient by making the user click a "Battery" button before they can access the state of the battery? This isn't meant to discourage the idea of coming up with ways of making implicit permissions work. But I think we have been focusing on a relatively easy case. I'd like to see the thread explore some of the other APIs and how implicit consent would work. And how they would work in conjunction with each other. On Apr 17, 2012, at 3:56 PM, Adrienne Porter Felt wrote: > +1 to everything Zack said > > Standard runtime dialogs that ask for Allow/deny are familiar, so system > designers seem to like them -- but a lot of literature establishes that > they don't work. Android tried moving them to install-time, which works > for a small minority of users sometimes. Unfortunately, they're either > ignored or impossible to interpret without context. (People who aren't > programmers have a hard time imagining how install-time permissions connect > to what applications actually do.) > > There are certain resources that might need to be represented as either > install-time permission prompts or standard runtime dialogs. (For example, > I can't think of another way to represent the ability to read all of the > user's text messages.) However, I view these as last resorts in the > toolbox. A very small number of prompts/standard dialogs will be OK. OTOH > if a new one is added along with each new WebAPI, we end up with > dialogs/prompts that are completely useless because people will see them > all the time. > > On Tue, Apr 17, 2012 at 8:18 PM, Zack Weinberg <za...@panix.com> wrote: > >> I feel very strongly that we should initially attempt to design a system >> where there are no install-time permission prompts, and more generally, no >> prompts for which "remember this decision" is a desirable option. >> >> As Adrienne has been pointing out, permissions dialogs in general do not >> work. They ask a non-expert user to make a security-critical choice, based >> on inadequate information, at a point in the workflow where most users will >> actively *avoid* stopping to think. (I don't have studies to hand, but I'm >> sure Adrienne does.) From the UX perspective *and* the security >> perspective, anything we can do to get away from them is worth doing. And >> we have a known better alternative: implicit, one-time-only deduction of >> permission from intentional user actions, such as pressing a "take photo" >> button. >> >> I'm frustrated by the Camera API discussion because there seem to be a >> bunch of people who don't even want to *try* to do something better. Sure, >> there exist applications for which it's not obvious how to fit them into an >> only-if-the-user-pressed-the-**button-just-now paradigm, but that doesn't >> mean we should give up! (I'm pretty sure we can fit all camera use cases >> into a combination of "you can draw over the preview but you can't see the >> results" and "video recording mode".) >> >> Let's treat permissions dialogs as an option of last resort. Let's only >> do them if we really can't find any other way for a particular privilege. >> >> zw >> ______________________________**_________________ >> dev-security mailing list >> dev-security@lists.mozilla.org >> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security> >> > _______________________________________________ > 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
