of termination UI like the
"stop recording" and "uninstall & report" persistent UI.
Jason Miller
519.872.0797 // developIT <http://developit.ca/> // Jason Miller
Design<http://jasonmillerdesign.com/>
*Developer of amoeba
> > If the user picks 'no', a well-written app should allow other
> > functionality to work, but won't be able to use the camera.
Too many developers fall into this trap: If a user installs a camera
application (some basic alternative camera), but denies it camera access -
why would the OS even
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,
det
> NO. it *has* to be "the Operating System embeds the 'magic' photo or
> videorecord icons". you CANNOT do "security by cooperation in
> userspace". this isn't firefox: it's a completely different ballgame.
This is the same as text input within the browser on Android - there is a
DOM element t
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.
Jason Miller
5
out malicious apps using the
camera.
- Jason
Jason Miller
519.872.0797 // developIT <http://developit.ca/> // Jason Miller
Design<http://jasonmillerdesign.com/>
*Developer of amoebaOS <https://amoebaos.com/>,
Shutterborg<http://shutterb.org/> &
more
*
On Sun, Ap
.
At the very least, the typical permissions based approach gives the users
who genuinely care about their security rather convenient tools to manage
it. Reading comments on the Android market does seem to confirm that this
group of users actively polices their apps to ensure they aren&
>
>
> This is a good point. Clickjacking could be addressed by designing a way
> to ensure an element is "on top" (a master z-index?) and also ensuring that
> the button is visible for at least {the time it takes for a human to
> recognize a button}+1 before it can be pressed.
>
>
No, this does no
