We thought about this (it's in the proposal that we're currently writing up), and there is no optimal solution. Implicit access through trusted UI works for *most* use cases, but there is a special set of edge cases---mostly security apps---that require permission for future events where the user should not be notified. However, these use cases are exceedingly rare (e.g., anti-theft software, proxies for calls and/or messages a la Google Voice, etc.).
The only reasonable solution that addresses these is having a separate installation flow (e.g., runtime dialogs don't solve this problem either), so that the user grants consent at installation time. However, this mechanism needs to be heavily dis-incentivized to prevent developers from shortcutting the security model when they don't legitimately need to. One possible way is by requiring manual approval/audits of applications that require this alternate installation flow. But we're certainly open to better suggestions. serge On Tue, Apr 24, 2012 at 9:50 AM, Randell Jesup <rande...@jesup.org> wrote: > [Grrr. Resent because direct posting from Emacs/Gnus keeps getting > flagged as needing moderator approval. > Re-resent to mailing list because posting to the newsgroup from > thunderbird went into a black hole...] > > >>There _is_ a more powerful capability that we may want to have available to >>a small handful of apps: "turn on the camera at some indefinite time in the >>future, without user interaction at the time". The only use case I can >>think of for that is an anti-device-theft system (turn on the camera, GPS, >>etc. remotely and try to figure out where the device is - I understand >>iPhones can do this), and maybe that should just be built into the TCB >>rather than being an add-on. But this does point at a general hole in the >>implicit authorization model: you can't use it to grant authorization to do >>something under programmatic conditions at some time in the future. Maybe >>there could be a special scheduler powerbox for that, though. > > That need is exactly what some WebRTC apps need (think VoIP-like > service - replacement for Skype, Google Hangouts where you want a > > user-controlled/styled answer/call/etc buttons - you get the idea). > > Users will not want to go through a security request on each call, and > app developers will not want to have "fixed" call/end buttons they can't > style (and I don't think this works anyways, at least not well enough to > consider). > > This *is* a dangerous permission to give, though it's equivalent to what > > users grant Skype or WebEx or Hangouts already by installing them > (perhaps less, actually). > > -- > Randell Jesup > randell-i...@jesup.org > > > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security -- /* I am Serge Egelman and I approve this message. */ _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
