Just as a case in point, we've now performed no less than four studies on the types of information that users care about (i.e., the data types that permissions purport to protect). We've found that users have *significantly* greater levels of concern for things like taking photos than they do for geolocation. Due to the habituation problem, you can't just use the same UI elements to represent things with vastly varying risks.
Trusted UI solves many of these problems very elegantly, since the user is no longer required to read every single notification every single time data is requested. Instead, the system supports the user by creating a trusted path. I would argue that if there's no way of doing this in the current implementation, the system is fundamentally flawed and most other mitigations being suggested are just bolting security on post hoc, rather than designing it from the ground up. serge On Thu, Apr 12, 2012 at 9:05 AM, Adrienne Porter Felt <[email protected]> wrote: > > On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <[email protected]> wrote: >> >> What would be wrong with using the same UI from Geolocation access for >> something like camera access? An API method requests that the user grant >> camera permissions, which shows them the appropriate dialog to confirm. >> Events are fired to inform the requesting application whether it was >> granted access or not. It could even differentiate between video recordings >> and still picture taking, as long as there was a limited "preview" API >> (perhaps a low-quality media stream). > > > Standard runtime dialogs like that don't work well because of habituation. > Over time, people become so conditioned to click "yes" that they will > approve access under virtually any circumstance. Runtime dialogs can work > if they are very *infrequent* because people don't see them enough to become > conditioned to them. Once they start to be applied to multiple different > types of (commonly-used) capabilities, they lose their effectiveness. -- /* I am Serge Egelman and I approve this message. */ _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
