WebAPI Security Discussion: Camera API

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

WebAPI Security Discussion: Camera API

Lucas Adamski-2
This discussion will be a bit more involved I think but I'd like to wrap this up by Tue 17th EOD PDT.

Name of API: Camera API

References:
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html ("Section 2 Scenarios") are use case
scenarios from the media capture task that is creating getUserMedia() which is what this API is based on.

Brief purpose of API: Let content take photos and capture video and/or audio

Use cases are the same for all content (regular web, trusted, certified):
*App allows user to take a picture for a profile
*App allows user to take a picture and record an audio clip
*App allows user to record a video with audio to send to someone else
*App allows user to record an audio clip to send to someone else
*App allows users to record video from multiple webcams [JStraus: How is this using the Camera API?]
*App allows foreground photo sharing with realtime preview and special effects.  Needs live video stream and the ability
to manipulate the stream on the fly.
*App allows video monitoring such as a baby monitor or security camera that can run for extended periods of time [Lucas:
Is this really a universal use case or an installed-only use case?]
*App allows the user to start a podcast, open other tabs/apps while the recording continues (to look up and comment on
information, etc) and then comes back to the tab/original app to finish the podcast.  Note: the user may continue to
record while opening or switching  to other tabs/apps [Lucas: Is this really a universal use case or an installed-only
use case?]
*App starts recording video and/or audio in the background on some signal that the device has been stolen.  Recordings
are uploaded. [Lucas: Is this really a universal use case or a certified-only use case?]

Inherent threats: Steal or spy on user video/audio
Threat severity: High per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Authorization model for normal content: explicit runtime
Authorization model installed content: explicit runtime
Potential mitigations: Prompt user to take a picture, record video, record an audio clip, or use the camera feed or
microphone feed.  If permitted, agent mediated viewfinder UI is launched to take a picture, record the video, or use the
camera/mic feed which user approves prior to it being provided to the content.  A/V stream only accessible while app has
focus. Only top level content can request access.
TBD: what gets shown when recording audio only?
TBD: Is there a visible indicator that the camera and/or microphone is active (because this is currently mandated by the
getUserMedia spec)?  Is this indicator visible even if the browser window is partially or completed obscured? What if
there is no browser window (like for Apps and B2G?)
TBD: Appropriate limitations to device fingerprinting
TBD: Should recording stop when content loses focus?  If it doesn't, how do we resolve concurrent audio/video feed
requests?  How does the user determine which tabs are recording?

== Trusted (authenticated by publisher) ==
Authorization model: explicit [upfront|runtime]??
Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit.  Uses <video>
tag (or some such) and is validated to have a non-collapsed extent, not be off-screen, not be (mostly) obscured by other
content.  Note: Video stream may need to be accessible while focus is given to another app

== Certified (vouched for by trusted 3rd party) ==
Authorization model: implicit
Potential mitigations: Settings manager could enumerate which apps have implicit access to camera.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
I'd like to propose the following based on discussions at Berkeley & with
others about camera access:

-- The OS provides two trusted UI buttons.  One has a photo icon, and the
other has a recording icon.  Applications can embed these icons into their
UIs but cannot write over them.
-- When the user presses one of these buttons, a photo is taken or
recording begins.  The result is returned to the user.
-- When the app takes a photo, some notification briefly appears on the
screen (on top of any other UI, including full-screened apps) to indicate
that a photo was just taken.
-- When the app is recording, a notification appears on the screen for the
duration of the recording.  Again, the notification is on top of any other
UI, including full-screened apps.  We recommend the notification be a
blinking red light since that is a standard warning that a device is
recording.
-- Applications can continue recording in the background but the
notification will persist.
-- If the user clicks on the recording notification (ie the blinking red
light) he/she is given the option of halting the recording.
-- Applications can register timeouts for taking photos instead of
recording, but the UI will make it appear as if the app is recording the
whole time.  This is to satisfy apps that take time-lapsed photos without
additional user intervention (e.g., an app that you mount to the front of
your bike that takes photos at 5 minute increments), but without incurring
the battery drain of needing to record the whole time to catch those frames.

On Tue, Apr 10, 2012 at 5:49 PM, Lucas Adamski <[hidden email]> wrote:

> This discussion will be a bit more involved I think but I'd like to wrap
> this up by Tue 17th EOD PDT.
>
> Name of API: Camera API
>
> References:
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html("Section 2 Scenarios") are use case
> scenarios from the media capture task that is creating getUserMedia()
> which is what this API is based on.
>
> Brief purpose of API: Let content take photos and capture video and/or
> audio
>
> Use cases are the same for all content (regular web, trusted, certified):
> *App allows user to take a picture for a profile
> *App allows user to take a picture and record an audio clip
> *App allows user to record a video with audio to send to someone else
> *App allows user to record an audio clip to send to someone else
> *App allows users to record video from multiple webcams [JStraus: How is
> this using the Camera API?]
> *App allows foreground photo sharing with realtime preview and special
> effects.  Needs live video stream and the ability
> to manipulate the stream on the fly.
> *App allows video monitoring such as a baby monitor or security camera
> that can run for extended periods of time [Lucas:
> Is this really a universal use case or an installed-only use case?]
> *App allows the user to start a podcast, open other tabs/apps while the
> recording continues (to look up and comment on
> information, etc) and then comes back to the tab/original app to finish
> the podcast.  Note: the user may continue to
> record while opening or switching  to other tabs/apps [Lucas: Is this
> really a universal use case or an installed-only
> use case?]
> *App starts recording video and/or audio in the background on some signal
> that the device has been stolen.  Recordings
> are uploaded. [Lucas: Is this really a universal use case or a
> certified-only use case?]
>
> Inherent threats: Steal or spy on user video/audio
> Threat severity: High per
> https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Authorization model for normal content: explicit runtime
> Authorization model installed content: explicit runtime
> Potential mitigations: Prompt user to take a picture, record video, record
> an audio clip, or use the camera feed or
> microphone feed.  If permitted, agent mediated viewfinder UI is launched
> to take a picture, record the video, or use the
> camera/mic feed which user approves prior to it being provided to the
> content.  A/V stream only accessible while app has
> focus. Only top level content can request access.
> TBD: what gets shown when recording audio only?
> TBD: Is there a visible indicator that the camera and/or microphone is
> active (because this is currently mandated by the
> getUserMedia spec)?  Is this indicator visible even if the browser window
> is partially or completed obscured? What if
> there is no browser window (like for Apps and B2G?)
> TBD: Appropriate limitations to device fingerprinting
> TBD: Should recording stop when content loses focus?  If it doesn't, how
> do we resolve concurrent audio/video feed
> requests?  How does the user determine which tabs are recording?
>
> == Trusted (authenticated by publisher) ==
> Authorization model: explicit [upfront|runtime]??
> Potential mitigations: Prompt for camera access, app then retains access
> to video/audio stream until exit.  Uses <video>
> tag (or some such) and is validated to have a non-collapsed extent, not be
> off-screen, not be (mostly) obscured by other
> content.  Note: Video stream may need to be accessible while focus is
> given to another app
>
> == Certified (vouched for by trusted 3rd party) ==
> Authorization model: implicit
> Potential mitigations: Settings manager could enumerate which apps have
> implicit access to camera.
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

JOSE MANUEL CANTERA FONSECA
El 11/04/12 02:59, "Adrienne Porter Felt" <[hidden email]> escribió:

>I'd like to propose the following based on discussions at Berkeley & with
>others about camera access:
>
>-- The OS provides two trusted UI buttons.  One has a photo icon, and the
>other has a recording icon.  Applications can embed these icons into their
>UIs but cannot write over them.
>-- When the user presses one of these buttons, a photo is taken or
>recording begins.
>The result is returned to the user.

I'm a bit confused ... So, the user cannot see a preview of the photo to
be taken?

>


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Adrienne Porter Felt
No, in our proposal, it's up to the app to provide a preview or the final
result (or not).  The user knows what his or her phone is pointing at and
whether the context is appropriate.  A non-malicious app will provide a
preview on its own; a malicious app might not, but the user won't click the
icon if he/she doesn't trust the app to take a photo of the physical space
the user is in at the moment.  (We assume that the trusted button can be
the topmost element and it appears for perhaps a half second or so before
it is clickable.)

On Wed, Apr 11, 2012 at 1:33 AM, JOSE MANUEL CANTERA FONSECA <[hidden email]>wrote:

> El 11/04/12 02:59, "Adrienne Porter Felt" <[hidden email]> escribió:
>
> >I'd like to propose the following based on discussions at Berkeley & with
> >others about camera access:
> >
> >-- The OS provides two trusted UI buttons.  One has a photo icon, and the
> >other has a recording icon.  Applications can embed these icons into their
> >UIs but cannot write over them.
> >-- When the user presses one of these buttons, a photo is taken or
> >recording begins.
> >The result is returned to the user.
>
> I'm a bit confused ... So, the user cannot see a preview of the photo to
> be taken?
>
> >
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Devdatta Akhawe-2
You want the application to be able to overlay things on top of the
picture. Think a barcode scanner, an OCR system, an AR app and so on. OS
imposed previews might be a problem.

--Dev

On 11 April 2012 01:39, Adrienne Porter Felt <[hidden email]> wrote:

> No, in our proposal, it's up to the app to provide a preview or the final
> result (or not).  The user knows what his or her phone is pointing at and
> whether the context is appropriate.  A non-malicious app will provide a
> preview on its own; a malicious app might not, but the user won't click the
> icon if he/she doesn't trust the app to take a photo of the physical space
> the user is in at the moment.  (We assume that the trusted button can be
> the topmost element and it appears for perhaps a half second or so before
> it is clickable.)
>
> On Wed, Apr 11, 2012 at 1:33 AM, JOSE MANUEL CANTERA FONSECA <[hidden email]>wrote:
>
>> El 11/04/12 02:59, "Adrienne Porter Felt" <[hidden email]> escribió:
>>
>> >I'd like to propose the following based on discussions at Berkeley & with
>> >others about camera access:
>> >
>> >-- The OS provides two trusted UI buttons.  One has a photo icon, and the
>> >other has a recording icon.  Applications can embed these icons into
>> their
>> >UIs but cannot write over them.
>> >-- When the user presses one of these buttons, a photo is taken or
>> >recording begins.
>> >The result is returned to the user.
>>
>> I'm a bit confused ... So, the user cannot see a preview of the photo to
>> be taken?
>>
>> >
>>
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>> nuestra política de envío y recepción de correo electrónico en el enlace
>> situado más abajo.
>> This message is intended exclusively for its addressee. We only send and
>> receive email on the basis of the terms set out at
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Lucas Adamski-2
In reply to this post by Adrienne Porter Felt
On Apr 10, 2012, at 5:59 PM, Adrienne Porter Felt wrote:

> I'd like to propose the following based on discussions at Berkeley & with
> others about camera access:
>
> -- The OS provides two trusted UI buttons.  One has a photo icon, and the
> other has a recording icon.  Applications can embed these icons into their
> UIs but cannot write over them.
> -- When the user presses one of these buttons, a photo is taken or
> recording begins.  The result is returned to the user.
> -- When the app takes a photo, some notification briefly appears on the
> screen (on top of any other UI, including full-screened apps) to indicate
> that a photo was just taken.
> -- When the app is recording, a notification appears on the screen for the
> duration of the recording.  Again, the notification is on top of any other
> UI, including full-screened apps.  We recommend the notification be a
> blinking red light since that is a standard warning that a device is
> recording.
> -- Applications can continue recording in the background but the
> notification will persist.
> -- If the user clicks on the recording notification (ie the blinking red
> light) he/she is given the option of halting the recording.
> -- Applications can register timeouts for taking photos instead of
> recording, but the UI will make it appear as if the app is recording the
> whole time.  This is to satisfy apps that take time-lapsed photos without
> additional user intervention (e.g., an app that you mount to the front of
> your bike that takes photos at 5 minute increments), but without incurring
> the battery drain of needing to record the whole time to catch those frames.

Hi Adrienne,

So after sleeping on this I think this model is pretty compatible with what I sent out, modulo the idea of the "magic buttons".  I don't have a strong opinion about this from a security standpoint, but I do wonder about the feasibility of enforcing a specific button style.  How do we determine a size/shape/look&feel of this button that will work with a wide variety of apps?  I browsed around a bit and it seems like camera apps use a wide variety of button shapes/colors for the shutter.  

What about an app that wants to take a picture on a time delay, say once a minute (but doesn't want a video feed)?

It seems like the consistent recording notification indicator is the key security mitigation.  Is the required button due to concerns a user might be tricked into enabling the camera without realizing they are?  Or is this a more specific concern for web content rather than installed apps?  As with anything HTML, clickjacking is a concern.
  Lucas.



_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
On Wed, Apr 11, 2012 at 5:46 PM, Lucas Adamski <[hidden email]> wrote:

> How do we determine a size/shape/look&feel of this button that will work
> with a wide variety of apps?  I browsed around a bit and it seems like
> camera apps use a wide variety of button shapes/colors for the shutter.
>

This is true, a standard button might not fit perfectly with all designs.
 But I also don't believe it will ruin any designs.  I'm not a graphic
designer -- but I suspect that a fairly neutral button could be selected
that would be both easily recognizable by users and inoffensive to the
aesthetics of UI designers.


> What about an app that wants to take a picture on a time delay, say once a
> minute (but doesn't want a video feed)?
>

You could create an API call specifically for time delay photos, and the
timeframes that are covered by it would be treated like a video feed with
respect to the UI that the user sees.  There really isn't much of a
difference between recording video and snapping a frame once a minute in
terms of privacy, so it makes sense to show them the same way to the user;
the main difference is the amount of battery that it drains (which can be
handled by a specific time-delay API call).


> It seems like the consistent recording notification indicator is the key
> security mitigation.  Is the required button due to concerns a user might
> be tricked into enabling the camera without realizing they are?  Or is this
> a more specific concern for web content rather than installed apps?


In many cases, I do agree that a notification is sufficient.  However, I
think that in instances where the action cannot be undone, a notification
is not enough.  Once a photo is taken, it's taken and possibly already off
your phone.


> As with anything HTML, clickjacking is a concern.


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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Jason Miller-10
>
>
> 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 not take into account visibility via the CSS visibility,
opacity and clip properties, or content containment+masking via frames.
The only implementation I know of that actually manages to "enforce"
visibility is the QuickTime plugin running in Firefox and Chrome. Even
then, there's nothing it can do about content obscuring it or making it
look like something else without actually covering it.


What would be wrong with using the same UI from Geolocation access for
something like camera access?  An API method requests that the user grant
camera permissions, which shows them the appropriate dialog to confirm.
 Events are fired to inform the requesting application whether it was
granted access or not.  It could even differentiate between video
recordings and still picture taking, as long as there was a limited
"preview" API (perhaps a low-quality media stream).
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <[hidden email]> wrote:
>
> What would be wrong with using the same UI from Geolocation access for
> something like camera access?  An API method requests that the user grant
> camera permissions, which shows them the appropriate dialog to confirm.
>  Events are fired to inform the requesting application whether it was
> granted access or not.  It could even differentiate between video
> recordings and still picture taking, as long as there was a limited
> "preview" API (perhaps a low-quality media stream).
>

Standard runtime dialogs like that don't work well because of habituation.
 Over time, people become so conditioned to click "yes" that they will
approve access under virtually any circumstance.  Runtime dialogs can work
if they are very *infrequent* because people don't see them enough to
become conditioned to them.  Once they start to be applied to multiple
different types of (commonly-used) capabilities, they lose their
effectiveness.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Serge Egelman-2
Just as a case in point, we've now performed no less than four studies
on the types of information that users care about (i.e., the data
types that permissions purport to protect).  We've found that users
have *significantly* greater levels of concern for things like taking
photos than they do for geolocation.  Due to the habituation problem,
you can't just use the same UI elements to represent things with
vastly varying risks.

Trusted UI solves many of these problems very elegantly, since the
user is no longer required to read every single notification every
single time data is requested.  Instead, the system supports the user
by creating a trusted path.  I would argue that if there's no way of
doing this in the current implementation, the system is fundamentally
flawed and most other mitigations being suggested are just bolting
security on post hoc, rather than designing it from the ground up.

serge

On Thu, Apr 12, 2012 at 9:05 AM, Adrienne Porter Felt <[hidden email]> wrote:

>
> On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <[hidden email]> wrote:
>>
>> What would be wrong with using the same UI from Geolocation access for
>> something like camera access?  An API method requests that the user grant
>> camera permissions, which shows them the appropriate dialog to confirm.
>>  Events are fired to inform the requesting application whether it was
>> granted access or not.  It could even differentiate between video recordings
>> and still picture taking, as long as there was a limited "preview" API
>> (perhaps a low-quality media stream).
>
>
> Standard runtime dialogs like that don't work well because of habituation.
>  Over time, people become so conditioned to click "yes" that they will
> approve access under virtually any circumstance.  Runtime dialogs can work
> if they are very *infrequent* because people don't see them enough to become
> conditioned to them.  Once they start to be applied to multiple different
> types of (commonly-used) capabilities, they lose their effectiveness.



--
/*
I am Serge Egelman and I approve this message.

*/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Jason Miller-10
I'm not opposed to a trusted UI approach, but I don't think it is possible
to provide adequate functionality using a "take picture" button.  The
preview point is spot on.  Think about the camera apps people use - preview
is a universal feature among them.

One solution might be to bundle the preview option into the take picture UI
- what happens now? That's basically reducing the typical access
confirmation modal with a button that does the same thing, but doesn't have
an option to "always allow".

As an example of another (existing) camera permissions flow, look at Flash.
 They pop a settings dialog that can't be modified by the application, and
the user has an option to persist the granted access.  Taking that one step
further, on Apple laptops there is a *hardware* indicator for camera
access.  That is something users trust.

Also notice that there really aren't any popular systems that are designed
to be secure from the ground up.  Users want an experience that works and
uses their device to its full potential *first*, and worry about security
after that need has been met.  For examples of this, look to Android's SD
security or iOS's lazy address book access control (or any iOS API access
for that matter).  When security comes at the price of usefulness, you
might want to think about how much security will matter if users return
their devices in favor of a phone that has expected features like a camera
viewfinder.

I don't mean to specifically knock your point, however.  If there was a way
to use a trusted UI approach while still allowing for the features
developers need now (and to a reasonable degree in the future), then surely
that's the ideal path.  I just have yet to see a workable concept.

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't being
duped.

- 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

*
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
> I'm not opposed to a trusted UI approach, but I don't think it is possible
> to provide adequate functionality using a "take picture" button.  The
> preview point is spot on.  Think about the camera apps people use - preview
> is a universal feature among them.


Apps can still have a preview window; it just won't return data until the
user presses a button.  This allows applications to have static overlays
over the preview window (e.g., lines to line up text for OCR).  If you have
a mandatory preview window as part of a trusted UI, then you can't have
static overlays.  This is why we say the button is our security feature --
preview windows can still exist.

Are you worried about any other functionality issues besides the preview
window issue?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Serge Egelman-2
In reply to this post by Jason Miller-10
I think there's a huge misunderstanding here:

We're not advocating getting rid of the preview screen.  What we're
advocating is that apps cannot receive camera data until the user has
pressed the button (which is owned by the OS).

In the current state of the world, some apps do not show preview screens.
 If this option is to remain, this is why the record button (and
notification) need to have a trusted path.  An alternative would be to make
the preview screen the trusted UI (and therefore enforce minimum/maximum
dimensions).  However, we believe that this latter option would be more
onerous on app developers.  Those that wish to include preview windows are
more than welcome to.

serge

On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[hidden email]> wrote:

> I'm not opposed to a trusted UI approach, but I don't think it is possible
> to provide adequate functionality using a "take picture" button.  The
> preview point is spot on.  Think about the camera apps people use - preview
> is a universal feature among them.
>
> One solution might be to bundle the preview option into the take picture
> UI - what happens now? That's basically reducing the typical access
> confirmation modal with a button that does the same thing, but doesn't have
> an option to "always allow".
>
> As an example of another (existing) camera permissions flow, look at
> Flash.  They pop a settings dialog that can't be modified by the
> application, and the user has an option to persist the granted access.
>  Taking that one step further, on Apple laptops there is a *hardware*
> indicator for camera access.  That is something users trust.
>
> Also notice that there really aren't any popular systems that are designed
> to be secure from the ground up.  Users want an experience that works and
> uses their device to its full potential *first*, and worry about security
> after that need has been met.  For examples of this, look to Android's SD
> security or iOS's lazy address book access control (or any iOS API access
> for that matter).  When security comes at the price of usefulness, you
> might want to think about how much security will matter if users return
> their devices in favor of a phone that has expected features like a camera
> viewfinder.
>
> I don't mean to specifically knock your point, however.  If there was a
> way to use a trusted UI approach while still allowing for the features
> developers need now (and to a reasonable degree in the future), then surely
> that's the ideal path.  I just have yet to see a workable concept.
>
> 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't being
> duped.
>
> - 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
>
> *
>
>
>


--
/*
I am Serge Egelman and I approve this message.

*/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Franzi Roesner
In reply to this post by Adrienne Porter Felt
If you can have a way of accurately capturing a user's intent to use the
camera/location in an application, you don't need a prompt. The buttons
that Adrienne suggested in her original email (or at least the first email
I saw) let you do this, or get closer to it.

One of the reasons that existing solutions to problems like this involve
prompts is that prompts are one of the only ways to get a secure UI. If you
can make a secure UI that's embeddable by an application, it functions more
seamlessly as part of the application, rather than breaking the flow. It's
also not a warning that users can become habituated to; they only click it
if they want the application to use the camera.

Making an embeddable UI secure does mean not allowing it to be active when
overlaid by other content (or overlaid at all), protecting against
clickjacking (e.g., with an activation delay when it appears), etc., as
others have pointed out.


Franzi

On Thu, Apr 12, 2012 at 9:05 AM, Adrienne Porter Felt <[hidden email]>wrote:

>
> On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <[hidden email]> wrote:
>>
>> What would be wrong with using the same UI from Geolocation access for
>> something like camera access?  An API method requests that the user grant
>> camera permissions, which shows them the appropriate dialog to confirm.
>>  Events are fired to inform the requesting application whether it was
>> granted access or not.  It could even differentiate between video
>> recordings and still picture taking, as long as there was a limited
>> "preview" API (perhaps a low-quality media stream).
>>
>
> Standard runtime dialogs like that don't work well because of habituation.
>  Over time, people become so conditioned to click "yes" that they will
> approve access under virtually any circumstance.  Runtime dialogs can work
> if they are very *infrequent* because people don't see them enough to
> become conditioned to them.  Once they start to be applied to multiple
> different types of (commonly-used) capabilities, they lose their
> effectiveness.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Ben Francis-7
In reply to this post by Serge Egelman-2
CC jcarpenter

No mobile camera app I know of requires the user to press a button to start
an image preview prior to capturing an image, the "viewfinder" starts as
soon as you open the app. This requirement would really break the UX of the
current B2G camera app. Preventing UI elements being overlayed on top of
the camera video stream is also a big limitation for UI design.

For Open Web Apps, the user can grant access to the camera permission
during installation, and/or with a geolocation style request at the time of
accessing the camera (with an option to "always allow").

Ben

On Thu, Apr 12, 2012 at 11:17 PM, Serge Egelman <[hidden email]>wrote:

> I think there's a huge misunderstanding here:
>
> We're not advocating getting rid of the preview screen.  What we're
> advocating is that apps cannot receive camera data until the user has
> pressed the button (which is owned by the OS).
>
> In the current state of the world, some apps do not show preview screens.
>  If this option is to remain, this is why the record button (and
> notification) need to have a trusted path.  An alternative would be to make
> the preview screen the trusted UI (and therefore enforce minimum/maximum
> dimensions).  However, we believe that this latter option would be more
> onerous on app developers.  Those that wish to include preview windows are
> more than welcome to.
>
> serge
>
> On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[hidden email]> wrote:
>
> > I'm not opposed to a trusted UI approach, but I don't think it is
> possible
> > to provide adequate functionality using a "take picture" button.  The
> > preview point is spot on.  Think about the camera apps people use -
> preview
> > is a universal feature among them.
> >
> > One solution might be to bundle the preview option into the take picture
> > UI - what happens now? That's basically reducing the typical access
> > confirmation modal with a button that does the same thing, but doesn't
> have
> > an option to "always allow".
> >
> > As an example of another (existing) camera permissions flow, look at
> > Flash.  They pop a settings dialog that can't be modified by the
> > application, and the user has an option to persist the granted access.
> >  Taking that one step further, on Apple laptops there is a *hardware*
> > indicator for camera access.  That is something users trust.
> >
> > Also notice that there really aren't any popular systems that are
> designed
> > to be secure from the ground up.  Users want an experience that works and
> > uses their device to its full potential *first*, and worry about security
> > after that need has been met.  For examples of this, look to Android's SD
> > security or iOS's lazy address book access control (or any iOS API access
> > for that matter).  When security comes at the price of usefulness, you
> > might want to think about how much security will matter if users return
> > their devices in favor of a phone that has expected features like a
> camera
> > viewfinder.
> >
> > I don't mean to specifically knock your point, however.  If there was a
> > way to use a trusted UI approach while still allowing for the features
> > developers need now (and to a reasonable degree in the future), then
> surely
> > that's the ideal path.  I just have yet to see a workable concept.
> >
> > 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't being
> > duped.
> >
> > - 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
> >
> > *
> >
> >
> >
>
>
> --
> /*
> I am Serge Egelman and I approve this message.
>
> */
> _______________________________________________
> dev-b2g mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-b2g
>



--
Ben Francis
http://tola.me.uk
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Serge Egelman-2
Again, this is a complete misunderstanding. We are not requiring a button to start preview. We are requiring a button to start *capture*. No current camera app, of which I am aware, gets access to the preview data before the user actually starts recording or snaps a photo. This would completely undermine any notion of consent.

Serge

Sent from my iPhone, hence the typos.

On Apr 13, 2012, at 2:40, Ben Francis <[hidden email]> wrote:

> CC jcarpenter
>
> No mobile camera app I know of requires the user to press a button to start an image preview prior to capturing an image, the "viewfinder" starts as soon as you open the app. This requirement would really break the UX of the current B2G camera app. Preventing UI elements being overlayed on top of the camera video stream is also a big limitation for UI design.
>
> For Open Web Apps, the user can grant access to the camera permission during installation, and/or with a geolocation style request at the time of accessing the camera (with an option to "always allow").
>
> Ben
>
> On Thu, Apr 12, 2012 at 11:17 PM, Serge Egelman <[hidden email]> wrote:
> I think there's a huge misunderstanding here:
>
> We're not advocating getting rid of the preview screen.  What we're
> advocating is that apps cannot receive camera data until the user has
> pressed the button (which is owned by the OS).
>
> In the current state of the world, some apps do not show preview screens.
>  If this option is to remain, this is why the record button (and
> notification) need to have a trusted path.  An alternative would be to make
> the preview screen the trusted UI (and therefore enforce minimum/maximum
> dimensions).  However, we believe that this latter option would be more
> onerous on app developers.  Those that wish to include preview windows are
> more than welcome to.
>
> serge
>
> On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[hidden email]> wrote:
>
> > I'm not opposed to a trusted UI approach, but I don't think it is possible
> > to provide adequate functionality using a "take picture" button.  The
> > preview point is spot on.  Think about the camera apps people use - preview
> > is a universal feature among them.
> >
> > One solution might be to bundle the preview option into the take picture
> > UI - what happens now? That's basically reducing the typical access
> > confirmation modal with a button that does the same thing, but doesn't have
> > an option to "always allow".
> >
> > As an example of another (existing) camera permissions flow, look at
> > Flash.  They pop a settings dialog that can't be modified by the
> > application, and the user has an option to persist the granted access.
> >  Taking that one step further, on Apple laptops there is a *hardware*
> > indicator for camera access.  That is something users trust.
> >
> > Also notice that there really aren't any popular systems that are designed
> > to be secure from the ground up.  Users want an experience that works and
> > uses their device to its full potential *first*, and worry about security
> > after that need has been met.  For examples of this, look to Android's SD
> > security or iOS's lazy address book access control (or any iOS API access
> > for that matter).  When security comes at the price of usefulness, you
> > might want to think about how much security will matter if users return
> > their devices in favor of a phone that has expected features like a camera
> > viewfinder.
> >
> > I don't mean to specifically knock your point, however.  If there was a
> > way to use a trusted UI approach while still allowing for the features
> > developers need now (and to a reasonable degree in the future), then surely
> > that's the ideal path.  I just have yet to see a workable concept.
> >
> > 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't being
> > duped.
> >
> > - 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
> >
> > *
> >
> >
> >
>
>
> --
> /*
> I am Serge Egelman and I approve this message.
>
> */
> _______________________________________________
> dev-b2g mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-b2g
>
>
>
> --
> Ben Francis
> http://tola.me.uk
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Jim Straus
Actually, a lot of apps need access to the preview before starting to capture (an image or video).  Any app that wants to do realtime transformations or effects will need the preview stream and then display it themselves.  Also, there are a class of apps that do "pre-cording" so that you can capture fleeting events (think of being at a kids sporting event).  The apps are recording into a temporary buffer so that when you hit the record/capture button they add or show earlier images to the store.

On Apr 13, 2012, at 8:19 AM, Serge Egelman wrote:

> Again, this is a complete misunderstanding. We are not requiring a button to start preview. We are requiring a button to start *capture*. No current camera app, of which I am aware, gets access to the preview data before the user actually starts recording or snaps a photo. This would completely undermine any notion of consent.
>
> Serge
>
> Sent from my iPhone, hence the typos.
>
> On Apr 13, 2012, at 2:40, Ben Francis <[hidden email]> wrote:
>
>> CC jcarpenter
>>
>> No mobile camera app I know of requires the user to press a button to start an image preview prior to capturing an image, the "viewfinder" starts as soon as you open the app. This requirement would really break the UX of the current B2G camera app. Preventing UI elements being overlayed on top of the camera video stream is also a big limitation for UI design.
>>
>> For Open Web Apps, the user can grant access to the camera permission during installation, and/or with a geolocation style request at the time of accessing the camera (with an option to "always allow").
>>
>> Ben
>>
>> On Thu, Apr 12, 2012 at 11:17 PM, Serge Egelman <[hidden email]> wrote:
>> I think there's a huge misunderstanding here:
>>
>> We're not advocating getting rid of the preview screen.  What we're
>> advocating is that apps cannot receive camera data until the user has
>> pressed the button (which is owned by the OS).
>>
>> In the current state of the world, some apps do not show preview screens.
>> If this option is to remain, this is why the record button (and
>> notification) need to have a trusted path.  An alternative would be to make
>> the preview screen the trusted UI (and therefore enforce minimum/maximum
>> dimensions).  However, we believe that this latter option would be more
>> onerous on app developers.  Those that wish to include preview windows are
>> more than welcome to.
>>
>> serge
>>
>> On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[hidden email]> wrote:
>>
>>> I'm not opposed to a trusted UI approach, but I don't think it is possible
>>> to provide adequate functionality using a "take picture" button.  The
>>> preview point is spot on.  Think about the camera apps people use - preview
>>> is a universal feature among them.
>>>
>>> One solution might be to bundle the preview option into the take picture
>>> UI - what happens now? That's basically reducing the typical access
>>> confirmation modal with a button that does the same thing, but doesn't have
>>> an option to "always allow".
>>>
>>> As an example of another (existing) camera permissions flow, look at
>>> Flash.  They pop a settings dialog that can't be modified by the
>>> application, and the user has an option to persist the granted access.
>>> Taking that one step further, on Apple laptops there is a *hardware*
>>> indicator for camera access.  That is something users trust.
>>>
>>> Also notice that there really aren't any popular systems that are designed
>>> to be secure from the ground up.  Users want an experience that works and
>>> uses their device to its full potential *first*, and worry about security
>>> after that need has been met.  For examples of this, look to Android's SD
>>> security or iOS's lazy address book access control (or any iOS API access
>>> for that matter).  When security comes at the price of usefulness, you
>>> might want to think about how much security will matter if users return
>>> their devices in favor of a phone that has expected features like a camera
>>> viewfinder.
>>>
>>> I don't mean to specifically knock your point, however.  If there was a
>>> way to use a trusted UI approach while still allowing for the features
>>> developers need now (and to a reasonable degree in the future), then surely
>>> that's the ideal path.  I just have yet to see a workable concept.
>>>
>>> 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't being
>>> duped.
>>>
>>> - 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
>>>
>>> *
>>>
>>>
>>>
>>
>>
>> --
>> /*
>> I am Serge Egelman and I approve this message.
>>
>> */
>> _______________________________________________
>> dev-b2g mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-b2g
>>
>>
>>
>> --
>> Ben Francis
>> http://tola.me.uk
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Serge Egelman-2
Regardless, this is not incompatible with what we are proposing.

Serge

Sent from my iPhone, hence the typos.

On Apr 13, 2012, at 8:27, Jim Straus <[hidden email]> wrote:

> Actually, a lot of apps need access to the preview before starting to capture (an image or video).  Any app that wants to do realtime transformations or effects will need the preview stream and then display it themselves.  Also, there are a class of apps that do "pre-cording" so that you can capture fleeting events (think of being at a kids sporting event).  The apps are recording into a temporary buffer so that when you hit the record/capture button they add or show earlier images to the store.
>
> On Apr 13, 2012, at 8:19 AM, Serge Egelman wrote:
>
>> Again, this is a complete misunderstanding. We are not requiring a button to start preview. We are requiring a button to start *capture*. No current camera app, of which I am aware, gets access to the preview data before the user actually starts recording or snaps a photo. This would completely undermine any notion of consent.
>>
>> Serge
>>
>> Sent from my iPhone, hence the typos.
>>
>> On Apr 13, 2012, at 2:40, Ben Francis <[hidden email]> wrote:
>>
>>> CC jcarpenter
>>>
>>> No mobile camera app I know of requires the user to press a button to start an image preview prior to capturing an image, the "viewfinder" starts as soon as you open the app. This requirement would really break the UX of the current B2G camera app. Preventing UI elements being overlayed on top of the camera video stream is also a big limitation for UI design.
>>>
>>> For Open Web Apps, the user can grant access to the camera permission during installation, and/or with a geolocation style request at the time of accessing the camera (with an option to "always allow").
>>>
>>> Ben
>>>
>>> On Thu, Apr 12, 2012 at 11:17 PM, Serge Egelman <[hidden email]> wrote:
>>> I think there's a huge misunderstanding here:
>>>
>>> We're not advocating getting rid of the preview screen.  What we're
>>> advocating is that apps cannot receive camera data until the user has
>>> pressed the button (which is owned by the OS).
>>>
>>> In the current state of the world, some apps do not show preview screens.
>>> If this option is to remain, this is why the record button (and
>>> notification) need to have a trusted path.  An alternative would be to make
>>> the preview screen the trusted UI (and therefore enforce minimum/maximum
>>> dimensions).  However, we believe that this latter option would be more
>>> onerous on app developers.  Those that wish to include preview windows are
>>> more than welcome to.
>>>
>>> serge
>>>
>>> On Thu, Apr 12, 2012 at 1:31 PM, Jason Miller <[hidden email]> wrote:
>>>
>>>> I'm not opposed to a trusted UI approach, but I don't think it is possible
>>>> to provide adequate functionality using a "take picture" button.  The
>>>> preview point is spot on.  Think about the camera apps people use - preview
>>>> is a universal feature among them.
>>>>
>>>> One solution might be to bundle the preview option into the take picture
>>>> UI - what happens now? That's basically reducing the typical access
>>>> confirmation modal with a button that does the same thing, but doesn't have
>>>> an option to "always allow".
>>>>
>>>> As an example of another (existing) camera permissions flow, look at
>>>> Flash.  They pop a settings dialog that can't be modified by the
>>>> application, and the user has an option to persist the granted access.
>>>> Taking that one step further, on Apple laptops there is a *hardware*
>>>> indicator for camera access.  That is something users trust.
>>>>
>>>> Also notice that there really aren't any popular systems that are designed
>>>> to be secure from the ground up.  Users want an experience that works and
>>>> uses their device to its full potential *first*, and worry about security
>>>> after that need has been met.  For examples of this, look to Android's SD
>>>> security or iOS's lazy address book access control (or any iOS API access
>>>> for that matter).  When security comes at the price of usefulness, you
>>>> might want to think about how much security will matter if users return
>>>> their devices in favor of a phone that has expected features like a camera
>>>> viewfinder.
>>>>
>>>> I don't mean to specifically knock your point, however.  If there was a
>>>> way to use a trusted UI approach while still allowing for the features
>>>> developers need now (and to a reasonable degree in the future), then surely
>>>> that's the ideal path.  I just have yet to see a workable concept.
>>>>
>>>> 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't being
>>>> duped.
>>>>
>>>> - 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
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> /*
>>> I am Serge Egelman and I approve this message.
>>>
>>> */
>>> _______________________________________________
>>> dev-b2g mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-b2g
>>>
>>>
>>>
>>> --
>>> Ben Francis
>>> http://tola.me.uk
>> _______________________________________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Lucas Adamski-2
In reply to this post by Adrienne Porter Felt
On Apr 10, 2012, at 5:59 PM, Adrienne Porter Felt wrote:

> I'd like to propose the following based on discussions at Berkeley & with
> others about camera access:
>
> -- The OS provides two trusted UI buttons.  One has a photo icon, and the
> other has a recording icon.  Applications can embed these icons into their
> UIs but cannot write over them.
> -- When the user presses one of these buttons, a photo is taken or
> recording begins.  The result is returned to the user.
> -- When the app takes a photo, some notification briefly appears on the
> screen (on top of any other UI, including full-screened apps) to indicate
> that a photo was just taken.
> -- When the app is recording, a notification appears on the screen for the
> duration of the recording.  Again, the notification is on top of any other
> UI, including full-screened apps.  We recommend the notification be a
> blinking red light since that is a standard warning that a device is
> recording.
> -- Applications can continue recording in the background but the
> notification will persist.
> -- If the user clicks on the recording notification (ie the blinking red
> light) he/she is given the option of halting the recording.
> -- Applications can register timeouts for taking photos instead of
> recording, but the UI will make it appear as if the app is recording the
> whole time.  This is to satisfy apps that take time-lapsed photos without
> additional user intervention (e.g., an app that you mount to the front of
> your bike that takes photos at 5 minute increments), but without incurring
> the battery drain of needing to record the whole time to catch those frames.
>

So upon further reflection, I'm not sure this idea is that different from the original proposal.  These two buttons are basically permission mechanisms that enables camera access.  The photo button is just like the "agent mediated viewfinder", and the camera button permits normal streaming access.  Notification models are basically the same.  So we are discussing whether requiring a specific style of button is a better permission mechanism than some other permission UI.

The main benefit I guess is that the user has to enable access every time?  Which is the downside too I guess.  Clickjacking still seems like a big risk if that's the only permission mechanism (besides the persistent notification).

The issue I see is that the button proposal doesn't allow for persistence of decisions which is an problem for apps that assume realtime preview of the image for whatever purposes.  In which case you'd likely see apps implementing a pattern where an app would immediately prompt a user to click on the video button, so it can start doing something useful, followed by a different shutter button to actually capture something?  

Even from my casual poking around in app stores its clear many mobile camera apps are applying realtime custom filters in preview, so we'd need a pretty compelling case to discourage that entire class of functionality.

Put another way, maybe your proposal is how we handle the user agent mediated approach, but apps can still request direct access to camera via a more traditional, persist able permission dialog?
  Lucas.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski <[hidden email]> wrote:

> Even from my casual poking around in app stores its clear many mobile
> camera apps are applying realtime custom filters in preview, so we'd need a
> pretty compelling case to discourage that entire class of functionality.
>

Yes.  I had not realized that applications actively edited streams of data
during the preview phase.  This is indeed a problem with the approach.  We
don't want people to have to click an extra button (one to start preview
and another to capture) -- we'd been hoping that fitting the permission
granting to the capture action would implicitly add the permission prompt
to the user's flow without adding an extra step.


> Put another way, maybe your proposal is how we handle the user agent
> mediated approach, but apps can still request direct access to camera via a
> more traditional, persist able permission dialog?
>

I do agree that the proposal is mostly the same: I think that the
permission should be granted at run-time, and there should be a
notification.  However, the way that the actual permission prompt is shown
to the user is very important, and a runtime dialog is not equivalent to a
magic permission button.  Traditional permission dialogs do not work (there
are many, many studies that show this).  The traditional permission dialog
gets in the way, so people want to click through it as fast as possible in
most cases, which leads them to click through as fast as possible out of
habit every time.  A special "capture" button isn't an extra step -- it's
the same step that people take in most camera apps.

I'm trying to brainstorm a new way to fit trusted UI into the user's normal
flow that would enable preview modification, without throwing up a standard
dialog.  If anyone buys my case that we need such a thing, suggestions for
how to get around the preview problem would be awesome.  :)
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1234