On 4/17/2012 9:00 PM, Lucas Adamski wrote:
On 4/15/2012 1:32 PM, Adrienne Porter Felt wrote:
Would the following suggestion solve the problem?
* Applications may embed the "magic" photo or videorecord icons. As soon as
the user presses the button, the app
receives the data. A notification is present as long as the app is recording.
The API provides an optional preview
window, but the app cannot get the data.
* Foreground applications can begin video recording or previewing without the
user pressing a button or accepting a
dialog. A notification appears as soon as the app requests to begin
recording/previewing; if the user clicks on the
notification, she is shown a small dialog that has a "Stop recording" option.
However, there is a slight delay between
when the application requests the data and when the OS begins delivering it.
This short delay allows the user to notice
the presence of the notification and either (1) quit the app, or (2) click on
the notification and tell it to stop
recording.
* Background applications cannot begin video recording or previewing.
I have to think about this some more (and I'd really like to see more PM and UX
feedback), but one possible approach
would be to go with the "magic button" model for unauthenticated content, but
also enable a more traditional persisted
permission design for authenticated apps. This would more neatly divide the
use cases into the respective categories,
rather than trying to cram them all into the "button" when some are frankly a
poor fit.
I think when we look at how "magic buttons" would really work (including
being able to be sure you've turned *off* recording, possible
clickjacking attacks, etc). I also think getting users to trust "magic"
buttons in pages to be safe is a bad precedent and bad user training,
and invite all sorts of social engineering attacks, etc.
There's also the problem of "what's a magic button", and how the user
finds that it's magic - does it glow, and announce its presence and
function when the mouse gets near it? :-) I'm joking, but you get the
idea; I think it hurts the overall model the user has of how things work
(note that this model may well not match reality!!!)
The delay I am uncomfortable with. As others also mentioned, an app having
focus does not guarantee it has my focus.
Many apps (music players and GPS apps) often run for extended periods of time
in the foreground without anyone looking
at them. In fact it'd be a neat trick to use motion sensors to detect when the
device hasn't been touched for some time
and start recording, then turn it off again the moment any motion is detected
or the screen is unlocked. Audio is
arguably more sensitive than video, and is orientation insensitive to boot.
Audio can be worrying, but I think most users would find unauthorized
video far more worrying than audio.... a lot more.
For the background case, I'm guessing your emphasis is on "begin"? Because in
general I would like to keep recording in
a video-conferencing app for example when I switch to look at my browser or
email.
This is actually a rather contentious point, though I agree with you in
general. Realize in some UI instances (phones) the user may not have
any clear idea that a tab might still be active when not visible. (This
brings up the WebRTC/Media Capture proviso that a camera-active
indicator be *always* visible when recording, even if on another tab or
window, and perhaps in the system tray as well - and this requirement is
especially problematic for mobile apps.)
--
Randell Jesup, Mozilla Corporation
Remove ".news" for personal email
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
