WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

Zack Weinberg-2
On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:

>
> 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 couldn't agree more... we have an opportunity to get wholly away from
the "whatever"-button dialogs with B2G, let's not miss it.

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

Re: WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
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.


On Sat, Apr 14, 2012 at 9:57 PM, Lucas Adamski <[hidden email]> 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.
> >
> > 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.
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Jason Miller-10
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

*



On Sun, Apr 15, 2012 at 4:32 PM, Adrienne Porter Felt <[hidden email]>wrote:

> 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.
>
>
> On Sat, Apr 14, 2012 at 9:57 PM, Lucas Adamski <[hidden email]>
> 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.
> > >
> > > 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.
> > _______________________________________________
> > dev-webapi mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-webapi
> >
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

Jason Miller-10
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

*



On Sun, Apr 15, 2012 at 4:50 PM, Adrienne Porter Felt <[hidden email]>wrote:

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

Re: [b2g] WebAPI Security Discussion: Camera API

Adrienne Porter Felt
In reply to this post by Adrienne Porter Felt
On Sun, Apr 15, 2012 at 5:30 PM, lkcl luke <[hidden email]> wrote:

> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt <[hidden email]>
> 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...?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

Randell Jesup-6
In reply to this post by Lucas Adamski-2
>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
remove ".news" for personal email
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Randell Jesup-6
In reply to this post by Serge Egelman-2
>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.

--
Randell Jesup, Mozilla Corp
remove ".news" for personal email
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

Adrienne Porter Felt
In reply to this post by Jason Miller-10
>
>
>  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 <[hidden email]>
> 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

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

Re: [b2g] WebAPI Security Discussion: Camera API

Mike Habicher
In reply to this post by Adrienne Porter Felt


----- Original Message -----

> From: "Adrienne Porter Felt" <[hidden email]>
> To: "Lucas Adamski" <[hidden email]>
> Cc: [hidden email], [hidden email], "Zack Weinberg" <[hidden email]>, "dev-b2g list"
> <[hidden email]>, [hidden email]
> 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

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.

On 16/04/2012 16:27, "Mike Habicher" <[hidden email]> wrote:

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

Re: [b2g] WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

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

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

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

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

--
Randell Jesup, Mozilla Corp

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

Re: [b2g] WebAPI Security Discussion: Camera API

Randell Jesup-5
In reply to this post by Lucas Adamski-2
[ 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.

--
Randell Jesup, Mozilla Corp

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

Re: WebAPI Security Discussion: Camera API

Zack Weinberg-2
In reply to this post by Zack Weinberg-2
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.

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.

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

Re: [b2g] WebAPI Security Discussion: Camera API

Randell Jesup-3
In reply to this post by Adrienne Porter Felt
On 4/16/2012 11:14 AM, Jason Miller wrote:

> That is one area where one could trust the app - the only way for it to
> gain access to the camera would be to insert the button's DOM node facade
> (this is a secure mechanism, because the DOM node is not the button itself,
> it is only a placement indicator).  The OS then observes the positioning,
> determines if the app is trying to obscure the button, and creates the real
> UI element.
>
> That being said, is there still a need for the buttons?  I thought the
> general consensus was that the delay+indicator+permissions was the way to
> go?

Delay: so bad I don't know where to begin.  :-(

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


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.

I should also note that WebRTC is trying to make a minimum set of
security requirements, though it leaves the mechanism and UIs up to the
browser.  See http://tools.ietf.org/html/draft-ietf-rtcweb-security-02

--
Randell Jesup, Mozilla Corporation
Remove ".news" for personal email
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Camera API

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

> On 4/16/2012 11:14 AM, Jason Miller wrote:
>> That is one area where one could trust the app - the only way for it to
>> gain access to the camera would be to insert the button's DOM node
>> facade
>> (this is a secure mechanism, because the DOM node is not the button
>> itself,
>> it is only a placement indicator).  The OS then observes the
>> positioning,
>> determines if the app is trying to obscure the button, and creates
>> the real
>> UI element.
>>
>> That being said, is there still a need for the buttons?  I thought the
>> general consensus was that the delay+indicator+permissions was the
>> way to
>> go?
>
> Delay: so bad I don't know where to begin.  :-(

Delay really means timeout here, right?  I hate the idea that the app
after some period of time has access to the camera and mic data without
any further user action other than opening the app.

Use case (or anti-use case?): the user clicks on an app, interacts with
it and at some point later, the app requests access to the camera;  if
the user isn't looking at the screen, he/she may not notice the request
for camera/mic access.  After some period of time, the user looks at the
screen and discovers the app has been capturing his/her camera and mic
data "for a while."

>
> Unstyleable button:  We considered this in the early internal
> discussions with Boriss about possible ways to avoid/minimize
> requester-fatigue.  Hell, I was the one who suggested it.
>
> The problem with in-page UI is that it's hard to guarantee - For
> example clickjacking: Evil App plops/moves the button down right
> when/where it thinks you're going to click - it may be unstyleable,
> but it may not be there long enough for you to see it/avoid clicking
> on it.  Yes, you can try to mitigate those sorts of problems, but it's
> a bit of a rathole, and how does the user learn this is the "safe" way
> to invoke the camera?
>
> Maybe I'm wrong, but I think I'm right.  If we do this, we'll need
> something similar for 'end call'/'stop-recording', because you don't
> want the user to "stop recording" and have the app continue to stream
> your video to a server because the app put something that *looked*
> like Stop in their page.
>
> As already mentioned, another big problem is that whatever you pick
> for the button, it will like not work or work poorly for some class of
> apps/users.  If you add alternates, you lose the "the user will learn
> the standard button" argument (though even that argument has problems
> IMHO).
>

Yeah, the button seems problematic to me for the reasons you give above.

>
> I will say that the preview/camera-select/access doorhanger mockup
> done by boriss (which we showed at W3 TPAC) got a lot of positive
> response.

Yes, this is the direction I assumed we would go in.  For reference:
http://www.w3.org/2011/04/webrtc/wiki/images/7/73/Webrtc_privacy.pdf

It feels like we are designing most of the chrome UX/UI for this feature
on this thread -- instead of just calling out the security requirements
for a UX/UI design of the chrome.  If we are designing the UX/UI on this
thread, then we need to get the UX/UI people (people like Boriss) involved.

We definitely need to design the chrome UX/UI piece of the app,
including mock ups.  I just thought that was a separate thread/meeting
that happened after we got the security requirements from this thread.

What am I missing or misunderstanding?  Or is the entire design
happening now and therefore I should be pinging the UX/UI people to get
on this thread ASAP?

Thanks.
-Maire

--
Maire Reavy<[hidden email]>
Mozilla


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1234