[ Reposting via mail interface because attempts to cross-post responses in News appeared to cause my message to end up in approval queues for the relevant mail lists - and no one appears to have approved them, at least not in security and B2G ]

>The countdown annoyance could also be mitigated by adding an "always allow"
>option to the user countdown indicator or recording notification UI.  That
>way a user can grant her favorite alternative Camera application persisted
>access to immediate stream access.  Those two concepts combined solve the
>issues I identified earlier.
>
>The delay could actually be combined with a dialog as well - perhaps
>something like the typical "allow camera access?" dialog, but with a timer
>that defaults to the "yes, this time" option after a few seconds. The more
>opportunities the user has to permanently grant or deny camera access, the
>better the user experience becomes for apps the user actually intends to
>use - remember, ideally these security additions should impact the
>malicious apps more than apps that have a genuine need for camera access.

Enabling the camera off a timer seems very, very iffy to me.  There are
all sorts of ways that could go wrong and possible ways a malicious app
might find to hide the countdown or distract you from it - even as
simple as forcing an unusually long GC/CC, since we have a problem even
blinking cursors during GC/CC.  (This is just an example; my point was
timers open all sorts of avenues of attack.)

And it has the same issue with requester fatigue - the user gets inured
to "just click ok" anytime they see it; they stop reading to see *which*
app actually requested it, and with a timeout they have little time to
read it, or to consider, or to see if they should trust (check online
resources about "is this app trustworthy?"), etc.

--
Randell Jesup, Mozilla Corp

_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to