On 4/17/2012 4:15 PM, Randell Jesup wrote:
On 4/16/2012 11:14 AM, Jason Miller wrote:
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node
facade
(this is a secure mechanism, because the DOM node is not the button
itself,
it is only a placement indicator). The OS then observes the
positioning,
determines if the app is trying to obscure the button, and creates
the real
UI element.
That being said, is there still a need for the buttons? I thought the
general consensus was that the delay+indicator+permissions was the
way to
go?
Delay: so bad I don't know where to begin. :-(
Delay really means timeout here, right? I hate the idea that the app
after some period of time has access to the camera and mic data without
any further user action other than opening the app.
Use case (or anti-use case?): the user clicks on an app, interacts with
it and at some point later, the app requests access to the camera; if
the user isn't looking at the screen, he/she may not notice the request
for camera/mic access. After some period of time, the user looks at the
screen and discovers the app has been capturing his/her camera and mic
data "for a while."
Unstyleable button: We considered this in the early internal
discussions with Boriss about possible ways to avoid/minimize
requester-fatigue. Hell, I was the one who suggested it.
The problem with in-page UI is that it's hard to guarantee - For
example clickjacking: Evil App plops/moves the button down right
when/where it thinks you're going to click - it may be unstyleable,
but it may not be there long enough for you to see it/avoid clicking
on it. Yes, you can try to mitigate those sorts of problems, but it's
a bit of a rathole, and how does the user learn this is the "safe" way
to invoke the camera?
Maybe I'm wrong, but I think I'm right. If we do this, we'll need
something similar for 'end call'/'stop-recording', because you don't
want the user to "stop recording" and have the app continue to stream
your video to a server because the app put something that *looked*
like Stop in their page.
As already mentioned, another big problem is that whatever you pick
for the button, it will like not work or work poorly for some class of
apps/users. If you add alternates, you lose the "the user will learn
the standard button" argument (though even that argument has problems
IMHO).
Yeah, the button seems problematic to me for the reasons you give above.
I will say that the preview/camera-select/access doorhanger mockup
done by boriss (which we showed at W3 TPAC) got a lot of positive
response.
Yes, this is the direction I assumed we would go in. For reference:
http://www.w3.org/2011/04/webrtc/wiki/images/7/73/Webrtc_privacy.pdf
It feels like we are designing most of the chrome UX/UI for this feature
on this thread -- instead of just calling out the security requirements
for a UX/UI design of the chrome. If we are designing the UX/UI on this
thread, then we need to get the UX/UI people (people like Boriss) involved.
We definitely need to design the chrome UX/UI piece of the app,
including mock ups. I just thought that was a separate thread/meeting
that happened after we got the security requirements from this thread.
What am I missing or misunderstanding? Or is the entire design
happening now and therefore I should be pinging the UX/UI people to get
on this thread ASAP?
Thanks.
-Maire
--
Maire Reavy<[email protected]>
Mozilla
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
