WebAPI Security Discussion: Camera API

[Lucas Adamski]

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.

[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 <lada...@mozilla.com> 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

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[JOSE MANUEL CANTERA FONSECA]

El 11/04/12 02:59, "Adrienne Porter Felt" <a...@berkeley.edu> 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

[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.)

[Anant Narayanan]

Hi Lucas,

Thanks for sending this out!

> == Regular web content (unauthenticated) ==
> Authorization model for normal content: explicit runtime
> Authorization model installed content: explicit runtime

Does the explicit runtime authorization model leave room for a "remember
this" option whereby subsequent camera access does not result in a
permission prompt?

> 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.

The getUserMedia spec does not require an agent mediated viewfinder UI.
The specification was built explicitly to give web applications a high
degree of control over the A/V stream with respect to how and where they
display it (there is even the chance that they won't display it at all -
which is why the indicators become important).

I would also note that making the A/V stream only accessible when the
app has focus would make for a suboptimal user experience, especially
for video conferencing apps, as it is quite common for users to switch
tabs/apps while they are actively participating in a conference.

> 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?)

The spec does not mandate a visible indicator, but is a UI guideline
that I agree we must adhere to. My proposal is to make the indicator a
part of browser chrome in the cases that we can, and if the browser
window is moved out of focus, use a system-level notification to inform
the user that the mic/camera are live (Growl on Mac, system tray on
Windows).

For fullscreen apps & B2G, this is much trickier, and I propose
restricting camera access to trusted & certified apps only, for those
two cases.

> TBD: Appropriate limitations to device fingerprinting

A proposal I sent out earlier to the W3C list asks to disallow
enumeration of devices via the constraints/capabilities API to regular
untrusted web content. Web content will only be able to request for
"audio" and/or "video" with no further granularity.

For trusted and certified applications, we should implement the full API
that lets apps query and enumerate all available audio and video
devices. This API has been proposed at the W3C working group.

> 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?

As mentioned earlier, I think access to the A/V stream should not stop
even if the content loses focus. Concurrent audio/video feed requests
are disallowed until the user explicitly stops using the web application
that is currently in hold of A/V resources (for instance, by dropping
the video conference).

I was hoping that the aforementioned browser chrome indicator would be
tab level. There is a UI mockup that Jennifer made a little while ago
that may be relevant. (can't find the original URL, reposted to:
https://people.mozilla.com/~anarayanan/omgwebcam.png)

> == 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.

These look great to me, I propose adding a note that both trusted &
certified apps have access to the constraints/capabilities API.

Regards,
-Anant

[Lucas Adamski]

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.

[Lucas Adamski]

On Apr 11, 2012, at 12:17 PM, Anant Narayanan wrote:

> Hi Lucas,
>
> Thanks for sending this out!
>
>> == Regular web content (unauthenticated) ==
>> Authorization model for normal content: explicit runtime
>> Authorization model installed content: explicit runtime
>
> Does the explicit runtime authorization model leave room for a "remember this" option whereby subsequent camera access does not result in a permission prompt?

Yes I think the user should always be able to persist a trust decision (whether affirmative or negative).

>> 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.
>
> The getUserMedia spec does not require an agent mediated viewfinder UI. The specification was built explicitly to give web applications a high degree of control over the A/V stream with respect to how and where they display it (there is even the chance that they won't display it at all - which is why the indicators become important).
>
> I would also note that making the A/V stream only accessible when the app has focus would make for a suboptimal user experience, especially for video conferencing apps, as it is quite common for users to switch tabs/apps while they are actively participating in a conference.

So it seems like the basic "take a picture with an OS mediated UI" use case isn't really valuable and should be dropped?

>
>> 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?)
>
> The spec does not mandate a visible indicator, but is a UI guideline that I agree we must adhere to. My proposal is to make the indicator a part of browser chrome in the cases that we can, and if the browser window is moved out of focus, use a system-level notification to inform the user that the mic/camera are live (Growl on Mac, system tray on Windows).
>
> For fullscreen apps & B2G, this is much trickier, and I propose restricting camera access to trusted & certified apps only, for those two cases.

Hmm, it seems a bit odd though to allow camera access to uninstalled content but disallow it for installed untrusted content? :)
Lucas.

[Adrienne Porter Felt]

On Wed, Apr 11, 2012 at 5:46 PM, Lucas Adamski <lada...@mozilla.com> 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.

[Jason Miller]

>
>
> 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).

[Adrienne Porter Felt]

On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller <ja...@developit.ca> 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.

[Fabrice Desré]

On 04/12/2012 10:39 AM, Anant Narayanan wrote:
>>> For fullscreen apps & B2G, this is much trickier, and I propose
>>> restricting camera access to trusted & certified apps only, for those
>>> two cases.
>>
>> Hmm, it seems a bit odd though to allow camera access to uninstalled
>> content but disallow it for installed untrusted content? :)
>

> Yes, it is a bit odd, but only because there is no easy way to display a
> live mic/camera indicator for installed untrusted content that is
> fullscreen (especially on B2G).

I don't see any problems doing this for B2G. We can show an icon in the
status bar when not fullscreen, and a chrome indicator when fullscreen.

Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation

[Jason Miller]

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

*

[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?

[Ben Francis]

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 <se...@guanotronic.com>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 <ja...@developit.ca> 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.
> >

> --
> /*
> I am Serge Egelman and I approve this message.
>
> */
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>



--
Ben Francis
http://tola.me.uk

[Anant Narayanan]

On 4/11/2012 6:22 PM, Lucas Adamski wrote:
>> The getUserMedia spec does not require an agent mediated viewfinder UI. The specification was built explicitly to give web applications a high degree of control over the A/V stream with respect to how and where they display it (there is even the chance that they won't display it at all - which is why the indicators become important).
>>
>> I would also note that making the A/V stream only accessible when the app has focus would make for a suboptimal user experience, especially for video conferencing apps, as it is quite common for users to switch tabs/apps while they are actively participating in a conference.
>
> So it seems like the basic "take a picture with an OS mediated UI" use case isn't really valuable and should be dropped?

No, this use case is definitely valuable by itself, but your original
email seemed to imply that it was the only use case for untrusted web
content. I was merely pointing out that we do need to support giving
untrusted web content full access to A/V streams, in *addition* to OS
mediated UI -- if that was your intent in the original email, I
apologize for the confusion.

-Anant

[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.

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

[Lucas Adamski]

Seems like the full A/V access includes all of the OS mediated UI use cases, so do we still need both? Or is it that OS mediated UI would not require a permission prompt (or even a request for camera access in the manifest)?
Lucas.

[Lucas Adamski]

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.

[Adrienne Porter Felt]

On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski <lada...@mozilla.com> 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. :)

[Anant Narayanan]

On 4/13/2012 6:14 PM, Lucas Adamski wrote:
> On Apr 13, 2012, at 8:18 AM, Anant Narayanan wrote:
>> No, this use case is definitely valuable by itself, but your original email seemed to imply that it was the only use case for untrusted web content. I was merely pointing out that we do need to support giving untrusted web content full access to A/V streams, in *addition* to OS mediated UI -- if that was your intent in the original email, I apologize for the confusion.
>

> Seems like the full A/V access includes all of the OS mediated UI use cases, so do we still need both? Or is it that OS mediated UI would not require a permission prompt (or even a request for camera access in the manifest)?

Yes, the OS mediated UI case is very similar to the file upload dialog;
whereby selecting a picture and clicking OK is implied consent and thus
doesn't require an entry in the manifest, nor a runtime prompt.

This will be attractive to some apps (selecting profile picture on
Facebook is one example), so I think we should support both use cases.

-Anant

[Lucas Adamski]

On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:

> On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
>> 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. :)
>

> The API could let the app apply arbitrary WebGL operations to the feed from the camera, but not allow the result to go anywhere but the screen until the user hits the button.
>
> zw

I won't pretend to know WebGL enough to understand its full capabilities, but is it feasible to apply such effects to images without being able to read the data? Depending on the exposure, color balance, etc. of the picture it can really effect the outcome of a filter. Maybe WebGL alone can do all that, I'm not sure.

Taking a step back, I looked briefly at the first 10 iPhone apps that came up when I searched for "camera". Here are some of the more interesting ones that jumped out at me:

CamWow (http://itunes.apple.com/us/app/camwow-free-photo-booth-effects/id418368641)
When it starts it immediately shows you a preview of a 2x2 grid with four different effects applied (well, 3 effects plus the original image). You can swipe back and forth to see several pages more worth of effects. When you tap one, you get a fullscreen preview of the image with the effect applied and a generic OS camera button to take the actual picture. So the use case here is the ability to show a live preview multiple times simultaneously, with different effects applied.

Camera ∞ (http://itunes.apple.com/us/app/camera/id486376930)
Shows a preview when it starts. You can touch the image to set focus lock. Includes a custom shutter button on the bottom middle that allows you to take multiple shots in rapid succession. Use case here includes immediate preview with user interaction (focus lock) and a custom shutter button.

Camera- (http://itunes.apple.com/us/app/camera/id442613820)
This one is kinda interesting. Previews right away and you can set tap to set exposure and focus lock independently. Uses custom menu ribbon on right (the shutter button is the current mode button). You an also active overlay tools over the image in preview, including an artificial horizon. So use cases appear to be fully customizable UI for picture taking and the ability to overlay interactive dynamic tools over the image that can in turn affect the image. There might be others as this appears to be a pretty complex ap.

8mm Vintage Camera (http://itunes.apple.com/us/app/8mm-vintage-camera/id406541444)
Kinda different, this primarily a video recorder with various vintage effects applied. It immediately shows a preview with whatever effects you have selected applied. The effects include tone adjustment along with different vintage film artifacts, as well as with "lens" changes and the ability to introduce jitter (i.e. looks like the video is jumping a frame). The shutter button itself is a retro red looking knob. So the use case here is immediate preview with a wide range of video effects applied, and a completely custom UI.

There's a ton more camera apps out there obviously so this is far from exhaustive, but it does indicate that some of these patterns are actually quite common.
Lucas.

[Adrienne Porter Felt]

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.

[Jason Miller]

Why wouldn't a hardware camera light and/or persisted "recording" indicator
(bar, light or otherwise) sufficient for both cases? The general idea
being that the user is now forced into being aware of the recording process
and can always terminate it in the same way.

Also, I think the idea of a foreground-only limitation is an excellent step
in the right direction. A user's first reaction to uncertainty over being
recorded by an application would probably involve either turning the phone
off, or closing/dismissing the application - if sending an app to the
background causes recording to stop, that harnesses instinctive user
behavior to solve the problem with nothing new to learn.

Keep in mind, when laptops first started shipping with built-in webcams, an
alarmingly large group of users placed tape over the camera when not in
use. Users don't trust technology as much as we wish they did.

Also of interest here, it might be a nice touch if the persisted
"recording" indicator UI had an option to report suspicious camera use
after forcing a camera stop action. That information could be extremely
useful in automating the process of filtering 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

*

[Adrienne Porter Felt]

The trick with a notification is that you want the user to be able to say
"ack! not wearing pants! stop!" before the app actually gets any data.
There are some ramifications of this:

* You probably want a software notification so that the user can click on
the notification and halt the recording. (You can't do that with a
hardware light.)

* You want a short delay between when the API call is made and when the
data is delivered to the app so that the user can notice the notification
before it starts. You can even represent the delay to the user as part of
the notification (a flashing red light with a countdown of 3, 2, 1...).

The delay might be annoying in some apps, even though it isn't very long.
For those apps, you could have a button that demonstrates that there is
user intent to capture camera data, so you don't need the delay.

On Sun, Apr 15, 2012 at 1:40 PM, Jason Miller <ja...@developit.ca> wrote:

> Also of interest here, it might be a nice touch if the persisted
> "recording" indicator UI had an option to report suspicious camera use
> after forcing a camera stop action. That information could be extremely
> useful in automating the process of filtering out malicious apps using the
> camera.
>

That sounds like a really good idea to me!

[Jason Miller]

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.

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

*

[Adrienne Porter Felt]

On Sun, Apr 15, 2012 at 5:30 PM, lkcl luke <luke.l...@gmail.com> wrote:

> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt <a...@berkeley.edu>
> wrote:
> > Would the following suggestion solve the problem?
> >
> > * Applications may embed the "magic" photo or videorecord icons.
>

> 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.
>

Doesn't the application need to say where to put it...?

[Jason Miller]

> 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 that defines the "requested" position within the DOM, and a
native UI element is placed based on its location. This removes absolute
control from the app/developer, but lets them define an ideal location for
the UI component without being given any control over it.

I don't think anyone here is suggesting a userspace solution, this is a
security discussion.

- Jason

[Adrienne Porter Felt]

>
>
> but yes, adrienne - perhaps unintentionally - did actually say that
> it should be userspace. allow me to quote again the relevant part of

> what adrienne (hello adrienne) said:
>
> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt <a...@berkeley.edu>
> wrote:
> > Would the following suggestion solve the problem?
> >

> > * Applications may embed the "magic" photo or videorecord icons.
>
> *applications* may embed the "magic" photo or videorecord icon(s).
>
> in other words, the implication is that it is the application which
> creates the DOM with the high z-Index to display the videorecord icon.
>

Of course we shouldn't trust an app to actually create or insert the
element itself. That makes no sense. However, the application needs to
indicate where such a button should go.

My suggestion is that we discuss the policy first, mechanism later.

[Jason Miller]

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?

[Mike Habicher]

----- Original Message -----
> From: "Adrienne Porter Felt" <a...@berkeley.edu>
> To: "Lucas Adamski" <lada...@mozilla.com>
> Cc: dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, "Zack Weinberg" <za...@panix.com>, "dev-b2g list"
> <dev...@lists.mozilla.org>, mozilla-de...@lists.mozilla.org
> Sent: Sunday, 15 April, 2012 4:32:06 PM
> Subject: Re: [b2g] WebAPI Security Discussion: Camera API
>
> 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.

I'm just catching up to this thread now, but I'd like to propose a solution based on a more fine-grained approach to permissions. For example:

* Permission 1: Allow this app to use the camera to take pictures/video? yes/no

If the user picks 'yes', the above scenario is enabled, but the app is forced to use the stock camera UI: viewfinder, buttons, etc., and may only capture data (either still or video) when the user presses the stock shutter/record button. The UI will have all the expected dressings: a shutter noise, a blinky recording indicator, etc. In essence the app would be allowed to invoke the camera, and would be allowed to get the data returned by it.

If the user picks 'no', a well-written app should allow other functionality to work, but won't be able to use the camera.

> * 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.

This scenario could be addressed by a different permission:

* Permission 2: Allow this app to use a custom camera interface? yes/no

If 'yes', the camera may customise anything, including the viewfinder, the capture button, indicators (though perhaps we'll need to keep the shutter sound, as per local regulations), etc. Here, the app would have access to lower-level camera APIs, essentially the ones used by the stock camera in Permission 1, provided it was in the foreground.

If 'no', well-written apps may gracefully degrade to the Permission 1 experience, but still be (somewhat) useful.

> * Background applications cannot begin video recording or previewing.

I don't think a blanket prohibition of camera usage while in the background in the right solution--although I can't think of a use case as it applies to me, the user may see it differently. Perhaps s/he is an artist who wants to put together an exhibit of photos taken at 1-minute intervals over the course of a day. If B2G is about giving the user complete control over his/her phone, we have to accept Scenario 3:

* Scenario 3: Allow this app to take photos and/or video ANY TIME IT LIKES WITHOUT WARNING? yes/no

If 'yes', the app may run in the background and do whatever it wants.

If 'no', the app may not use the camera at all, or may degrade to the Permission 2 or 1 scenarios.

I just looked back over Lucas' original proposal, and out of his proposed use cases, 'stolen phone tracking' definitely falls under Scenario 3; and 'baby monitor' may fall under Scenario 2 or 3, depending on where we slot in "camera active while display backlight is off" fits in.

--m.

[Jordano Francisco (UK)]

+1 to the permissions model.

A responsive permissions model could help build any kind of app, and
giving the user total control over what it installs.

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

This electronic message contains information from Telefonica UK, Telefonica Europe or Telefonica Digital which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email.


Switchboard: +44 (0)113 272 2000
Email: feed...@o2.com

Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85
Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85
Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85

[Jason Miller]

> > 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 continue with installation? That situation
represents an unfulfilled platform requirement (the same as if the device
simply did not have a camera), which means the application is not going to
be useful. A camera app without camera access can't have an appropriate
fallback, it is simply non-functioning. That is an extremely poor user
experience.

You should also think about how complex such a UI would become - these are
just the settings for camera access, which is definitely not the only
permissions-based API camera apps would require access to. Now you're
talking about a bunch of options for the user to turn on and off that
fundamentally change the app's behavior. I seriously doubt any developers
would be willing to write apps that account for every single case - you'll
end up with a bunch of apps that throw up a "please grant this app all the
permissions it needs to use it" dialog and be done with it. The developer
of a camera app will not care that 2% of users got scared during
installation by strongly worded dialogs and turn off the API access it
requires. Those users aren't going to get a camera app anyway (it would be
useless), so they shouldn't even be allowed to install it with such
crippled permissions.

This is why you have UI/UX people chiming in on a security discussion (much
appreciated!) - this is so much more about working within the constraints
of existing user habits than it is about API design.

> A responsive permissions model could help build any kind of app, and
> > giving the user total control over what it installs.

The user already has control over that, because they make the decision to
install the app after seeing a list of what high-level actions the app
would be allowed to take. Also, isn't general mistrust of store-downloaded
applications a more fundamental issue than one could hope to solve with a
confusing development-centric permissions API?

Most users **do not** understand the difference between "us[ing] custom
camera interface" and "us[ing] the camera to take pictures/video"

Perhaps there are two separate permissions models that need to be created
here, based on the use-cases and issues that have come up so far:
1. Full access to Camera API confirmed during installation; or
2. In-app request for a specific type of camera access, granted
(optionally permanent) by the classic "allow GPS access" type of dialog.

Those are two different use-cases for camera access. One for apps that
require access simply to be functional, the other for apps that can benefit
from it outside their core functionality.

- Jason

[Henri Sivonen]

On Tue, Apr 17, 2012 at 9:52 AM, Jason Miller <ja...@developit.ca> wrote:
>> > 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 continue with installation?

Because camera functionality might be peripheral to the app and the
user wants to use the rest of the app without trusting the app with
camera access.

Example:

I installed a GPS logger on my Android phone. At the time I installed
it, it didn't require access to my Google accounts. Now an update
wants access to my Google accounts and says it will only use the
privilege if I want to send my log data to Google Docs.

Now I have to either believe that the app author is telling the truth
or I have to reject updates forever and hope I never need to
reinstall. (I only want local .gpx logging.)

I would want to have the option to install the update but deny access
to my Google accounts. If the app author was telling the truth about
the need to access my Google accounts, it shouldn't be a problem to
deny access.

I think B2G should not have this permission system bug that Android has.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Jason Miller]

Nothing in my description goes against your use-case (though I trust you
are aware how uncommon the use-case is). An update would simply require
that you view+confirm the installation-time permissions list again. I
disagree that this represents a bug in Android, however. As I have stated
here already, absolute maximum security at high cost to user experience is
*not* ideal, and should not be a goal for any project hoping to target
consumers.

The suggestion I made was that app developers can choose to request access
during installation, or to request it as-needed at runtime. In your
situation, as long as the app developer used the latter. Perhaps for
*updates* on-the-fly access grants would be the only available option for
new privileges (this makes sense if apps auto-update, which they do in B2G
from what I understand, just using the cache manifest).

So, again, secondary features in an app would use a runtime permissions
request, primary features should require access to be granted during
installation. This is all in addition to the various recording
indicator/revoke UI discussed here earlier.

- 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

*

[Randell Jesup]

[ 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

[Randell Jesup]

[ 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 ]

>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

My severe apologies, but I'm going to add another layer of complication
to this discussion:

(tl;dr: We need to consider how these choices will impact WebRTC as well
so we don't end up having to change them after a short time, or end up
with very different user security models for Interactive and
Capture/Record.)

For WebRTC, we also need access to the camera and mics. We also have
use cases where security warnings will rapidly become too painful for
users to deal with (think a Skype-equivalent). And we need the api
decided on to not be at odds with what we want to do there; the current
Camera API (recording) cases are just part of the overall need and
constraint. I'm not saying we have to have full support for WebRTC in
the tree for Camera API to move forward, but we at least need to know
that the UI/UX we design will be extendable for interactive cases
without going back to square one.


We need to be able to support *choosing* a camera (yes, devices have
more than 1!), whether to use a camera, or multiple cameras at once.
See the Media Capture Task Force use-cases for capturing -
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html
and
http://dev.w3.org/2011/webrtc/editor/getusermedia.html

WebRTC likewise will need to support multiple cameras and mics.

The webrtc folk considered the "unstylable button" idea; we were very
concerned with the potential security risks that approach engenders
(clickjacking, etc) as well as it could seriously constrain the UI of
apps. We've gravitated to some type of doorhanger that also functions
as a preview and visual way to identify the correct camera. (Mic
selection is a little trickier, though usually they're mostly tied to
cameras.)

Note also that there are two forms of Camera API for recording: the
<input> tag form, which inherently limits the amount of interaction with
the app in terms of preview, etc, and what the Media Capture Task Force
is defining, navigator.getUserMedia(). As getUserMedia will supply a
MediaStream when fully implemented, this allows for full preview and
modification in the app, and all sorts of other things.

The WebRTC group has talked about "installed" webapps in order to deal with
Requester Fatigue, especially in things like Skype-equivalents, and have
discussed leveraging the installed-app model for security. Note that at
the full Skype-like level, the app can turn on the camera and mic,
either anytime or at least in response to any user UI action/click.

For WebRTC, we'll also want the user to be able to supply a picture or
maybe a video in some cases in place of a camera stream.


For security, the equivalency model is that if you were to install
Skype, WebEx, etc, you've given total access to skype to camera, mics,
probably the internet, etc (plus all your files, etc). So there's
precedent that some level of installed webapp be given extended
permissions.

Lastly, there's an issue of access by the app to the raw data in the
mediastream, especially for non-fully-trusted apps (installed or not).
This is mostly an issue for interactive use, but recording cases can
trigger it as well. The issues and some possible solutions (leveraging
cross-origin controls) are detailed in my slides here:
http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-2.pdf


My apologies for complicating the issue, but we need the solution for
image/video capture to not box in the design for WebRTC.

[Maire Reavy]

On 4/17/2012 4:15 PM, Randell Jesup wrote:

> 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<mre...@mozilla.com>
Mozilla

[Lucas Adamski]

On 4/17/2012 3:43 PM, Maire Reavy wrote:
>
> 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?

We are designing the security model for these APIs, which has potential implications for the app use cases and UX.
Nobody is proposing a particular button design here, but the question of which mechanism we use is integral to the
security model. We are having this discussion on the webapps list specifically because we need the broader perspective
(outside of just security) to ensure we understand the inherent tradeoffs in the various proposals. Thanks!
Lucas.

[Lucas Adamski]

On 4/17/2012 11:31 AM, Zack Weinberg wrote:

> On 2012-04-14 9:57 PM, Lucas Adamski wrote:
>> On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
>>
>>> On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
>>>> 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. :)
>>>
>>> The API could let the app apply arbitrary WebGL operations to the
>>> feed from the camera, but not allow the result to go anywhere but
>>> the screen until the user hits the button.
>>

>> I won't pretend to know WebGL enough to understand its full
>> capabilities, but is it feasible to apply such effects to images
>> without being able to read the data?
>

> Shader programs are Turing-complete and run in a sandbox with exactly the security properties we need here. I'm pretty
> sure all of the examples you gave can be done under the constraint I described.

Good to know, thanks!

> I do know a use case that won't fit into this paradigm: Photosynth (
> http://itunes.apple.com/us/app/photosynth/id430065256?mt=8 ) lets you construct a panoramic image simply by waving your
> phone around. It automatically positions photos on a virtual sphere based on orientation sensor data plus image
> analysis, and automatically takes photos to fill in gaps. The image analysis here could (in principle) be done in a
> shader, but taking additional photos at appropriate times based on the analysis can't.
>
> But we have an alternative ready-to-hand, without falling back to permissions dialogs: video recording mode. If
> WebGL-preview-until-user-authorizes-still isn't good enough, ask for permission to record video; that gives access to
> the raw video stream (until the user presses the button again) and an API to take stills whenever you want.

I'm guessing by "video recording mode" you really mean "full camera access"? I ask because video frame capture is not
comparable to photo capture from a quality standpoint, but we could grant the app the ability to take unlimited pictures
for that period of time.
Lucas.

[Maire Reavy]

It seems that one thing we've discovered is that we can't separate the
security design and discussion from the UX/UI design itself. Our UX/UI
teams would tell us that the most critical and interesting pieces of the
UX/UI design is not a particular button design, but rather if there is a
button at all, where it is on the screen and how it interacts with and
affects the user -- which is exactly what this thread discussion has
turned into.

I have no idea who is subscribed to webapps list, but I know who I would
invite to a UX/UI design meeting, and I think many of them aren't on
this thread, or they would have chimed in by now.

What's more, I think people participating in this discussion are going
to be more comfortable seeing the actual mock ups themselves, along with
the UX description of the feature, before agreeing to a solution.

I'm going to reach out to the UX/UI designers/contributors who would
normally be involved in a camera/mic app design meeting, and ask them to
catch up on this thread if they haven't been following it. Once they
are involved in the discussion, I believe the next logical step would be
to have a meeting and ask them to create candidate mock ups for this
feature, accompanied by UX descriptions (what behaviors we would see for
each use case we care about). I believe those will get us what we need
to drive toward consensus and approval.

If anyone thinks this plan is crazy, let me know, but this feels like
the logical next step.

[Lucas Adamski]

On Apr 17, 2012, at 8:19 PM, Maire Reavy wrote:

> It seems that one thing we've discovered is that we can't separate the security design and discussion from the UX/UI design itself. Our UX/UI teams would tell us that the most critical and interesting pieces of the UX/UI design is not a particular button design, but rather if there is a button at all, where it is on the screen and how it interacts with and affects the user -- which is exactly what this thread discussion has turned into.

Agreed, I definitely want UX to be involved in this discussion.

To be clear, we are not proposing a button fixed in the chrome. This button is really a permission mechanism implemented by the OS that an app can place within its UI (if that sounds a bit tricky, it is).

> I have no idea who is subscribed to webapps list, but I know who I would invite to a UX/UI design meeting, and I think many of them aren't on this thread, or they would have chimed in by now.
>
> What's more, I think people participating in this discussion are going to be more comfortable seeing the actual mock ups themselves, along with the UX description of the feature, before agreeing to a solution.
>
> I'm going to reach out to the UX/UI designers/contributors who would normally be involved in a camera/mic app design meeting, and ask them to catch up on this thread if they haven't been following it. Once they are involved in the discussion, I believe the next logical step would be to have a meeting and ask them to create candidate mock ups for this feature, accompanied by UX descriptions (what behaviors we would see for each use case we care about). I believe those will get us what we need to drive toward consensus and approval.

Comparing mockups would help, but I think it would also be important to get guidance on the potential impact on app design and UI for each of their proposals. In other words, if they were asked to build a camera or teleconferencing app, how would the respective proposals impact their designs?
Lucas.

[Ben Francis]

On Wed, Apr 18, 2012 at 6:49 AM, Ragavan Srinivasan <ragav...@mozilla.com
> wrote:

>
> So, I'd like some help. I'll describe the two main use cases for *still*
> image capture that I believe are our immediate priorities for Kilimanjaro
> (K9O).


Thank you Ragavan, I was struggling to follow this thread too and I think
starting with high priority use cases is exactly the right way to go about
discussing this, otherwise we end up building something overcomplicated
that people don't need, yet. I worked on B2G's current camera app and have
been loosely following the progress of getUserMedia at WebRTC. I'm trying
to keep a handle on this thread because it has B2G UX worried :)

1. Default camera app for a B2G phone that functions like the default
> camera app you have on your iphone/android phone. This app will, in all
> probability, come pre-bundled on your phone.
>

Exactly, as a minimum this means having the ability to get a video stream
from the camera as soon as the user launches the app in order to display a
viewfinder, then allowing the capture of a still image using a button.


> 2. An Instagram like app that allows you to take a picture, capture the
> preview, apply some filters and save/share the picture. This class of apps
> will likely want to control the entire experience (including the frame,
> what the buttons look like etc). I will note that this may not be possible
> until more of the getUserMedia functionality lands, but this is the
> platform capability we want to enable. This app will be available via the
> marketplace.
>

Right, so the capabilities described above should not be exclusive to
"pre-bundled" apps because the user should be able to swap out the default
camera app with another one (or have two), which should be able to request
exactly the same kind of access from the user. Personally I feel this
should be at install time and/or at first use, with the user given the
option to "always allow" access.

Ben

--
Ben Francis
http://tola.me.uk

[Mounir Lamouri]

On 04/11/2012 02:49 AM, Lucas Adamski wrote:
> == Regular web content (unauthenticated) ==
> Authorization model for normal content: explicit runtime
> Authorization model installed content: explicit runtime

I don't know if we should allow normal content to access the Camera API
but I think most use cases can be solved by simply using that:
<input type='file' accept='video/*'> (video/* can be changed to audio/*
or image/*).
That should bring a UI that would allow the user to take a picture or do
anything appropriate to the type. That UI would be made by the Chrome so
the user would understand what is happening exactly like <input
type='file'>.
FWIW, we already have something like that implemented in Firefox for
Android (Ngihtly).

An alternative to that is to have the content to use Web Intents/Web
Activities.

Those two solutions would be enough to solve most use cases content
would have. If you want to have something more real time (like applying
effects on currently showing picture, chat app, etc.), you will need to
access the Camera API but that should be rare enough to make that
permission hard to get.
I don't know if we should make that API unavailable to unauthenticated
content.

> == 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

I guess we can use the model Jonas proposed: ask at installation time
and if denied, ask at run-time?

> == Certified (vouched for by trusted 3rd party) ==
> Authorization model: implicit
> Potential mitigations: Settings manager could enumerate which apps have implicit access to camera.

I guess we can trust a vouched app.

--
Mounir

[Lucas Adamski]

At a high level the proposals are similar in the notification model - either way we'd have a persistent indicator while the camera is being accessed.

The main difference is how permission to the camera is granted. Whether its done with:
a) a combination of install-time and run-time UI "dialog" mechanism as has been discussed previously. This has the downside of potentially pestering the user into making poor decisions.
b) an OS "magic button" that the app places in its UI. This negates the need for a dialog but requires the user to click that button when they want the app to capture audio or video. It also means that apps couldn't have automatic access to the camera upon startup (i.e. no "always allow"), which limits what the app can do in terms of preview. As Zack pointed out, maybe apps can use WebGL shaders to overcome some of those issues, but I'm not sure if that's equivalent.
Lucas.

On Apr 17, 2012, at 9:49 PM, Ragavan Srinivasan wrote:

>
>
> Lucas Adamski wrote:
>>
>> Comparing mockups would help, but I think it would also be important
>> to get guidance on the potential impact on app design and UI for each
>> of their proposals. In other words, if they were asked to build a
>> camera or teleconferencing app, how would the respective proposals
>> impact their designs? Lucas.
>

> I've tried to catch up on this thread, but between poor threading on my NNTP client and Google Groups, I'm afraid I'm a bit lost.
>
> So, I'd like some help. I'll describe the two main use cases for *still* image capture that I believe are our immediate priorities for Kilimanjaro (K9O). I'd appreciate it if someone (Lucas?) could describe the security team's current proposal for how the permissions (and the UX) would work for these use cases.

>
> 1. Default camera app for a B2G phone that functions like the default camera app you have on your iphone/android phone. This app will, in all probability, come pre-bundled on your phone.
>

> 2. An Instagram like app that allows you to take a picture, capture the preview, apply some filters and save/share the picture. This class of apps will likely want to control the entire experience (including the frame, what the buttons look like etc). I will note that this may not be possible until more of the getUserMedia functionality lands, but this is the platform capability we want to enable. This app will be available via the marketplace.
>

> Thanks,
> Ragavan
>
> PS: I know there are discussions about a teleconferencing app, but that is not a P1 for K9O, so I'd like to focus on the above two for now.
>
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

[Lucas Adamski]

On Apr 18, 2012, at 2:23 AM, Ben Francis <b...@krellian.com> wrote:
>
> Exactly, as a minimum this means having the ability to get a video stream
> from the camera as soon as the user launches the app in order to display a
> viewfinder, then allowing the capture of a still image using a button.

Do you need immediate access to the feed from the camera or do you merely need to display the stream to the user (and maybe apply a WebGL shader)?

>
>> 2. An Instagram like app that allows you to take a picture, capture the
>> preview, apply some filters and save/share the picture. This class of apps
>> will likely want to control the entire experience (including the frame,
>> what the buttons look like etc). I will note that this may not be possible
>> until more of the getUserMedia functionality lands, but this is the
>> platform capability we want to enable. This app will be available via the
>> marketplace.
>>
>

> Right, so the capabilities described above should not be exclusive to
> "pre-bundled" apps because the user should be able to swap out the default
> camera app with another one (or have two), which should be able to request
> exactly the same kind of access from the user. Personally I feel this
> should be at install time and/or at first use, with the user given the
> option to "always allow" access

So Instagram doesn't appear to require realtime preview with special effects applied, but other apps do.

My thinking is the magic button approach could work for in unauthenticated apps and content and we could use the more persistent trust model for authenticated apps.
Lucas.

[Ben Francis]

On Wed, Apr 18, 2012 at 9:19 PM, Lucas Adamski <lada...@mozilla.com> wrote:

>
> On Apr 18, 2012, at 2:23 AM, Ben Francis <b...@krellian.com> wrote:
> >
> > Exactly, as a minimum this means having the ability to get a video stream
> > from the camera as soon as the user launches the app in order to display
> a
> > viewfinder, then allowing the capture of a still image using a button.
>
> Do you need immediate access to the feed from the camera or do you merely
> need to display the stream to the user (and maybe apply a WebGL shader)?
>

I'm not quite sure what the difference is, but we'd need to be able to
display the video stream, style the way it's presented, transform the video
etc. and apply filters in real time. Does that answer your question?

>
> >
> >> 2. An Instagram like app that allows you to take a picture, capture the
> >> preview, apply some filters and save/share the picture. This class of
> apps
> >> will likely want to control the entire experience (including the frame,
> >> what the buttons look like etc). I will note that this may not be
> possible
> >> until more of the getUserMedia functionality lands, but this is the
> >> platform capability we want to enable. This app will be available via
> the
> >> marketplace.
> >>
> >
> > Right, so the capabilities described above should not be exclusive to
> > "pre-bundled" apps because the user should be able to swap out the
> default
> > camera app with another one (or have two), which should be able to
> request
> > exactly the same kind of access from the user. Personally I feel this
> > should be at install time and/or at first use, with the user given the
> > option to "always allow" access
>
> So Instagram doesn't appear to require realtime preview with special
> effects applied, but other apps do.
>
> My thinking is the magic button approach could work for in unauthenticated
> apps and content and we could use the more persistent trust model for
> authenticated apps.
>

I'm not sure how much trust can be assigned to a "magic button", it
requires educating the user what that button is and somehow enforcing
consistent presentation. But it sounds similar to the filepicker dialog
with a camera grab option which whilst not being great UX, probably works
for unprivileged content. As long as privileged content can gain greater
access through requesting permissions from the user then I'm happy, I think
:)

I have no idea how aligned this is with the getUserMedia work at WebRTC
though.

[Jim Straus]

In thinking about the "magic button" and un-authenticated apps, particularly those that just want a simple camera interface (I'm figuring that they are not primarily camera apps), can we have a whole camera widget? I'm thinking this would be a system iframe or something similar that has the video stream from the camera as preview, has a shutter button, front/rear camera select, flash on/off, supports touch focus (or whatever the control is for focus), etc. It has a minimum size, has content generated events blocked, and is forced to the top layer. It could also support selecting a picture from the image store. It posts an image back to it's parent when it is done (or null if canceled). Basically a secure picture selection. Any app could use this to get a new or saved picture. This would be available to any app (or web page even). I'm guessing we might want something like this in any case to simplify the operation of the camera for apps that just want to get a picture without having to worry about how to set focus, switch cameras, etc.
Given this, it is easy for a user to see that a picture is being taken and that they can cancel or take or select a picture. A non-secure app couldn't spoof or make use of the data until the user has implicitly granted permission. The app only gets the one image, so doesn't have access to the rest of the stream or image store. No special training required.
Camera apps may want more control than this provides, but it should do for many any other app. To make it useful for a set of dedicated camera apps, a shader could be passed in (assuming that running a shader is secure). If we had this control, we could potentially get by on the first release without the lower level access and permissions. That said, building the widget would be non-trivial, but better for us to do it once and well.

[Lucas Adamski]

On Apr 13, 2012, at 10:37 PM, Adrienne Porter Felt wrote:

>
> On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski <lada...@mozilla.com> 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. :)

Instead of this button being embedded in the app, could it be provided in the door hanger?
Lucas.

[Lucas Adamski]

I've attempted to update the proposal per all of the recent discussion. I've almost certainly missed something so please let me know what.

The controversial part of this proposal may be not allowing persistent access to the camera from unauthenticated content, only from trusted apps. The reason is that besides the UI challenges we are looking at, regular content has very different security properties from authenticated apps and allowing full persisted access to camera from an HTTP website has troubling consequences in a mobile computing environment.

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: have been moved to their respective app categories

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

== Regular web content (unauthenticated) ==

Use cases:
*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 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
*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 (this one might be a bit of a stretch; can work with the magic button or WebGL shader approach but requires some more research)

Authorization model for normal content: user-mediated OS UI
Authorization model installed content: user-mediated OS UI
Potential mitigations: App can launch a user-mediated viewfinder UI take a picture, record the video, or use the
camera/mic feed which user approves prior to it being provided to the content. 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. Additionally (contingent upon addressing UX and clickjacking concerns), we could potentially use a "magic button" rendered by OS with the app context. There is a persistent recording indicator (blinking red light?). App can continuing recording if it loses focus. Only top level content can request access. There is no "always allow" option in this app category.
TBD: Appropriate limitations to device fingerprinting

== Trusted (authenticated by publisher) ==

Use cases:
*App allows users to record video from multiple webcams
*App allows video monitoring such as a baby monitor or security camera that can run for extended periods of time

Authorization model: explicit (at install, at runtime, with "always allow/deny" option)
Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit. There is a persistent recording indicator (blinking red light?) App can continuing recording if it loses focus.

== Certified (vouched for by trusted 3rd party) ==

Use cases:
*App starts recording video and/or audio in the background on some signal that the device has been stolen. Recordings
are uploaded.

Authorization model: implicit
Potential mitigations: Settings manager could enumerate which apps have implicit access to camera.

Notes:
*Trusted & certified apps have access to the constraints/capabilities API


On Apr 10, 2012, at 5:49 PM, Lucas Adamski 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
>

[Henri Sivonen]

> On Tue, Apr 17, 2012 at 3:18 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>> Because camera functionality might be peripheral to the app and the
>> user wants to use the rest of the app without trusting the app with
>> camera access.
>>
>> Example:
>>
>> I installed a GPS logger on my Android phone. At the time I installed
>> it, it didn't require access to my Google accounts. Now an update
>> wants access to my Google accounts and says it will only use the
>> privilege if I want to send my log data to Google Docs.
>>
>> Now I have to either believe that the app author is telling the truth
>> or I have to reject updates forever and hope I never need to
>> reinstall. (I only want local .gpx logging.)
>>
>> I would want to have the option to install the update but deny access
>> to my Google accounts. If the app author was telling the truth about
>> the need to access my Google accounts, it shouldn't be a problem to
>> deny access.
>>
>> I think B2G should not have this permission system bug that Android has.

On Tue, Apr 17, 2012 at 10:43 AM, Jason Miller <ja...@developit.ca> wrote:
> Nothing in my description goes against your use-case (though I trust you
> are aware how uncommon the use-case is).

It's not *that* uncommon. I've used Android only since September, and
I've already encountered two case where an update to an app wanted
inessential extra permissions and the options I had were:
1) Grant the app inessential extra permissions I wouldn't have
accepted initially but now I face the loss of an app I've already
started using.
2) Have a permanent update notification cluttering my notification area.
3) Uninstall the app and lose all the previous functionality, too.

(One case was the GPS logger I mentioned above. The other was a game
that came as a paid version and an ad-supported version. At the time I
bought the paid version, it didn't insist on the snooping permissions
the ad-supported version wanted in order to target apps. Yet, a later,
after I had paid to avoid the snooping permissions, update added
snooping permissions to the paid version, too.)

Furthermore, when looking at new apps I might or might not install, I
see excess permission requests *all* *the* *time*. The most common
thing is that apps that aren't dialer replacements want a permission
whose description suggests it would give the app information about
which phone numbers I'm calling.

> An update would simply require
> that you view+confirm the installation-time permissions list again.

But I don't want to confirm the new permissions! That's the whole
point! (And yes, Android does show the new permission list for
confirmation when an update wants more permissions than the previous
version, but the choice is all-or-nothing. If you want the update, you
have to give it all the permissions it wants.)

[Jason Miller]

So you're saying an application platform should let its users revoke
essential permissions (required for the app to run) simply because it might
add "clutter"? Why not turn off update notifications, or turn off
auto-updates for that app? Certainly Android's notifications model is to
blame for that mess, not their update policy.

Regardless of the use case's relevancy (I was referring to backgrounded GPS
logging, not update-time permission changes), the problem you encountered
is that an application developer created a feature you don't like. It you
still want to use the application, you should install the update and look
for a setting to turn the upload feature off. If that doesn't exist, then
you have to contact the developer. It was their choice to push that
feature out (as it should be, since developers decide how their
applications work). In the Android ecosystem, the *only* solution for this
is to find a different app - their marketplace is supposed to be open, it
should be easy.

Regarding your interpretation of the Android permissions strings - perhaps
Android was a poor choice for your main phone. It's an open market, and
it's extremely to get sketchy apps into their store. You have to install
apps from developers you trust, basing your decision off of high-level
permissions alone represents a misunderstanding of what those strings are
capable of conveying to the user. "Snooping permissions" seem more like a
problem with Android's SD card management permissions or intent resolution
process than anything else.

So, while I understand your concern with install-time permissions changing
in an app update, I don't think pointing out Android's implementation flaws
justifies your argument. There are far too many User Interface choices
that affect the experience, it is not a simple comparison.

- 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

*

[Jason Miller]

>
> This *is* a dangerous ability to give, though it's equivalent to what
> users grant Skype or WebEx or Hangouts already by installing them
> (perhaps less, actually).


Agreed. App installation can never be free from danger. Regardless of any
security restrictions, you are granting the app permission to execute on
your device. Users can't/don't/wouldn't want to review the source of an
app before they install it, and providing insight into API access is only a
small step in making that more user-friendly.

This is why I have been pushing for the use of termination UI like the
"stop recording" and "uninstall & report" persistent UI.

[Jim Straus]

Apps on other devices do get access to the preview to be able to do things with it like providing effects. The proposal to use WebGL shaders to modify the preview seems to ameliorate that issue in a way that other platforms aren't using (which is good). An API to open the preview that takes an optional shader would allow a preview to be shown and effects added without providing the preview data to the user. Overlays would be allowed (yes, a developer could completely hide the preview, but why bother when they can just not invoke the preview). And the magic button to allow access would keep the content from accessing the image stream before the user has "granted permission" using the magic button.

Thinking through some of the types of apps on other devices, this seems to be work for Instagram type cameras (shader provides effects). Looks like shaders can tesselate so apps (like PhotoBooth) showing multiples of the preview could work (not positive about this, as I'm not a WebGL Shader expert). Time machine camera apps (iOS Precorder) could work by having the user hit the magic button to start capturing multiple images and then the app could allow the user to select the images they wanted after capture has stopped. Skype type apps would get access to the video stream once the user hits the magic button (which could also be used to initiate the call) or the call could be initiated and then the magic button hit to say the user wanted to transmit video.

The questions seem to me are 1) is the shader sufficient and secure enough for developer needs and 2) can we design a magic button that is secure and distinctive enough for developer needs and sufficiently distinctive to the user to let them know what they're allowing access to.

I guess the final question is: can we generalize this for other APIs. I would prefer not to go through all the effort of making a secure camera without permissions prompts just to have everything else using permission prompts. That would make users feel insecure about the API(s) that use magic UI infrastructure.

I'm guessing we could come up with magic UI for a class of permissions: microphone button, phone handset button for audio/voip, phone handset button for dialer, envelope button for email, globe or target button for geolocation, bluetooth icon button for bluetooth, usb icon button for usb, etc. I'm not sure about things like storage, permissions API, settings API, etc. Maybe those are handled more at the install/first launch stage and not at runtime. And background apps or services are a whole different question.
-Jim Straus

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 <b...@krellian.com> 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 <se...@guanotronic.com> 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 <ja...@developit.ca> 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
>> dev...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-b2g
>>
>>
>>

>> --
>> Ben Francis
>> http://tola.me.uk
> _______________________________________________

> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Lucas Adamski]

On 4/24/2012 8:56 AM, Jason Miller wrote:
> So you're saying an application platform should let its users revoke essential permissions (required for the app to run)
> simply because it might add "clutter"? Why not turn off update notifications, or turn off auto-updates for that app?
> Certainly Android's notifications model is to blame for that mess, not their update policy.

I think the entire point is that these permissions often are not essential. Many of these involve a developer trading
user privacy, battery life and performance for an incremental improvement in monetization.

This is also how the web works. All site permissions are runtime optional, and if a web app doesn't get access to your
camera or location, it still works. Maybe just a bit less than it could otherwise. If that breaks something essential,
you can always change your mind later and grant that permission.

Providing an incremental evolution for installed apps seems like a better approach than switching to a system that is
the polar opposite. We're putting together a more detailed proposed workflow around this that we'll discuss in its own
thread shortly.
Lucas.

[Jim Straus]

I want to raise a general point that is touched on by Lucas below. We want app developers to develop compelling apps for our platform(s). To encourage them to do so they need to be able to monetize their apps. One way to do that is to directly charge users for the apps. The other way is to get indirect revenue, through advertisements.
On the web, this is a constant battle with chrome developers developing things that block advertisements and web developers figuring out ways to keep themselves from being blocked, or at least guessing that most users won't install blockers and so only miss a small amount of revenue. Think what would happen to someplace like Google if all advertisement on the web was blocked.
If we make it too convenient for app users to block advertisements, then we will be blocking a source of revenue for app developers. This leads to their only revenue sources coming directly from the users through direct sales (paid apps, in-app purchases). On the other hand there are large number of users who prefer free apps even if they have advertisements. And those that don't want advertisements can either upgrade to remove ads with an in-app purchase or buying the "pro" paid version (given that the developer gives one of these options). I'm concerned that if developers can't make use of alternative revenue sources (advertisements) we won't have as robust an app ecosystem. Users won't acquire as many apps (because they're having to pay for everything) and this will lead to developers not being as interested in the platform because users aren't picking up as many apps.
I'm not saying we should make it impossible to block ads, or that ad vendors should be able to get to whatever data they want, but we should keep in mind that advertisements are an important aspect of the echosystem.
Thoughts?
-Jim Straus

[Paul Theriault]

("Final" proposal, please reply to dev-w...@lists.mozilla.org by COB
June 4 with any further comments )

Unless there are any further comments, I believe the previous proposal
still remain accurate. Note that in the absence of a magic button or
similar implementation in B2G, realtime preview/stream will only be
available to trusted and certified apps.

To summarize the model below:
Web Pages: Explicit (OS mediated only, e.g. web activities, trusted UI,
magic button etc)
Untrusted: Explicit (OS mediated only, e.g. web activities, trusted UI,
magic button etc)
Trusted: Explicit (some limitations)
Certified: Implicit, no limitations

Note that following a discussion at the San Diego B2G work week, I have
added the status icon mitigation to the certified case as well. While
this might be undesirable for a "take photos if my phone is stolen" app,
the consensus was that consistent UI and mitigation of privacy risk was
more important than the small risk that this feature might reduce the
effectiveness of this type of app.

-------------

Potential mitigations: Prompt for camera access, app then retains access to video/audio stream until exit. There is a persistent recording indicator.

App can continuing recording if it loses focus.

== Certified (vouched for by trusted 3rd party) ==
Use cases:

* Main Camera app
* App can continuing recording if it loses focus.

Authorization model: implicit
Potential mitigations:
Settings manager could enumerate which apps have implicit access to camera.

There is a persistent recording indicator.

Notes:
*Trusted& certified apps have access to the constraints/capabilities API

> *Trusted& certified apps have access to the constraints/capabilities API

[Justin Lebar]

Replying only to dev-webapps, because I understand that's our primary
mailing list for these threads.

> Note that in the absence of a magic button or similar implementation in
> B2G, realtime preview/stream will only be available to trusted and certified
> apps.

Have you spoken with the WebRTC folks about this?

Desktop does not (at the moment) have the concept of trusted/certified
apps. Therefore I don't believe that the WebRTC folks intend to
implement this restriction.

So is the proposed restriction for b2g a temporary one which will
change once WebRTC lands and we can adopt its security model (whatever
that is)?

[Paul Theriault]

On 6/5/12 12:02 AM, Justin Lebar wrote:
> Replying only to dev-webapps, because I understand that's our primary
> mailing list for these threads.
>
>> Note that in the absence of a magic button or similar implementation in
>> B2G, realtime preview/stream will only be available to trusted and certified
>> apps.
> Have you spoken with the WebRTC folks about this?

Now I have, but only briefly (but Randall posted earlier in this thread)
. Without really knowing enough about the webrtc security model I assume
that we follow the webrtc security model for webpages and untrusted web
apps, and follow the permissions model for trusted and untrusted apps to
provide any additional capabilities that are not included in the webrtc
api (such as the camera control API?)

>
> Desktop does not (at the moment) have the concept of trusted/certified
> apps. Therefore I don't believe that the WebRTC folks intend to
> implement this restriction.
>
> So is the proposed restriction for b2g a temporary one which will
> change once WebRTC lands and we can adopt its security model (whatever
> that is)?

Yes that was my thought. I assume that we would still retain seperate
permission for trusted and certified apps, as maybe you would grant more
fine-grained access to control the camera that might not be possible in
the webrtc model.

[Justin Lebar]

>> Have you spoken with the WebRTC folks about this?
>
> Now I have, but only briefly (but Randall posted earlier in this thread) .
> Without really knowing enough about the webrtc security model I assume that
> we follow the webrtc security model for webpages and untrusted web apps, and
> follow the permissions model for trusted and untrusted apps to provide any
> additional capabilities that are not included in the webrtc api (such as the
> camera control API?)

>> So is the proposed restriction for b2g a temporary one which will
>> change once WebRTC lands and we can adopt its security model (whatever
>> that is)?
>
> Yes that was my thought. I assume that we would still retain seperate
> permission for trusted and certified apps, as maybe you would grant more
> fine-grained access to control the camera that might not be possible in the
> webrtc model.

There's a lot of assuming going on here; it sounds to me like you
haven't had a chance to learn all of the relevant information about
WebRTC. Does it make sense to finalize this security discussion
before we're sure we have the right model?

-Justin

[Lucas Adamski]

WebRTC team has been tracking this model discussion from the very beginning. The current model is an intermediate step and we still have to solve this permission problem in general for browser and non-trusted apps. There was discussion of using shaders to help augment the OS preview for example, or to support a magic button.
Lucas.