WebAPI Security Discussion: Camera API

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

Re: [b2g] WebAPI Security Discussion: Camera API

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

Re: WebAPI Security Discussion: Camera API

Lucas Adamski-2
In reply to this post by Adrienne Porter Felt
On 4/15/2012 1:32 PM, Adrienne Porter Felt 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.
>

I have to think about this some more (and I'd really like to see more PM and UX feedback), but one possible approach
would be to go with the "magic button" model for unauthenticated content, but also enable a more traditional persisted
permission design for authenticated apps.  This would more neatly divide the use cases into the respective categories,
rather than trying to cram them all into the "button" when some are frankly a poor fit.

The delay I am uncomfortable with.  As others also mentioned, an app having focus does not guarantee it has my focus.
Many apps (music players and GPS apps) often run for extended periods of time in the foreground without anyone looking
at them.  In fact it'd be a neat trick to use motion sensors to detect when the device hasn't been touched for some time
and start recording, then turn it off again the moment any motion is detected or the screen is unlocked.  Audio is
arguably more sensitive than video, and is orientation insensitive to boot.

For the background case, I'm guessing your emphasis is on "begin"?  Because in general I would like to keep recording in
a video-conferencing app for example when I switch to look at my browser or email.
  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

Lucas Adamski-2
In reply to this post by Zack Weinberg-2
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.
_______________________________________________
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
In reply to this post by Lucas Adamski-2
On 4/17/2012 8:47 PM, Lucas Adamski wrote:

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

Thanks.
-Maire

--
Maire Reavy<[hidden email]>
Mozilla


_______________________________________________
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-3
In reply to this post by Adrienne Porter Felt
On 4/17/2012 9:00 PM, Lucas Adamski wrote:

> On 4/15/2012 1:32 PM, Adrienne Porter Felt 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.
>>
>
> I have to think about this some more (and I'd really like to see more PM and UX feedback), but one possible approach
> would be to go with the "magic button" model for unauthenticated content, but also enable a more traditional persisted
> permission design for authenticated apps.  This would more neatly divide the use cases into the respective categories,
> rather than trying to cram them all into the "button" when some are frankly a poor fit.

I think when we look at how "magic buttons" would really work (including
being able to be sure you've turned *off* recording, possible
clickjacking attacks, etc).  I also think getting users to trust "magic"
buttons in pages to be safe is a bad precedent and bad user training,
and invite all sorts of social engineering attacks, etc.

There's also the problem of "what's a magic button", and how the user
finds that it's magic - does it glow, and announce its presence and
function when the mouse gets near it?  :-)  I'm joking, but you get the
idea; I think it hurts the overall model the user has of how things work
(note that this model may well not match reality!!!)

> The delay I am uncomfortable with.  As others also mentioned, an app having focus does not guarantee it has my focus.
> Many apps (music players and GPS apps) often run for extended periods of time in the foreground without anyone looking
> at them.  In fact it'd be a neat trick to use motion sensors to detect when the device hasn't been touched for some time
> and start recording, then turn it off again the moment any motion is detected or the screen is unlocked.  Audio is
> arguably more sensitive than video, and is orientation insensitive to boot.

Audio can be worrying, but I think most users would find unauthorized
video far more worrying than audio.... a lot more.

> For the background case, I'm guessing your emphasis is on "begin"? Because in general I would like to keep recording in
> a video-conferencing app for example when I switch to look at my browser or email.

This is actually a rather contentious point, though I agree with you in
general.  Realize in some UI instances (phones) the user may not have
any clear idea that a tab might still be active when not visible.  (This
brings up the WebRTC/Media Capture proviso that a camera-active
indicator be *always* visible when recording, even if on another tab or
window, and perhaps in the system tray as well - and this requirement is
especially problematic for mobile apps.)


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

Lucas Adamski-2
In reply to this post by Maire Reavy
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.

_______________________________________________
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

Lucas Adamski-2
In reply to this post by Maire Reavy
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapps

_______________________________________________
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-17 6:05 PM, Lucas Adamski wrote:

> On 4/17/2012 11:31 AM, Zack Weinberg wrote:
>>
>> 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.

Right.  I called it 'video recording mode' because I think that will be
the appropriate presentation to the user.  I wouldn't bother having
"take stills without further user intervention starting now (until
revoked)" be a distinct capability from "record video starting now
(until revoked)".  And I think this also covers the time lapse
photography scenario: if you've set up a camera for time lapse, you've
probably put it in a fixed location and aren't going to touch it for a
while, so the app can stay in the foreground.  Similarly for baby monitors.

There _is_ a more powerful capability that we may want to have available
to a small handful of apps: "turn on the camera at some indefinite time
in the future, without user interaction at the time".  The only use case
I can think of for that is an anti-device-theft system (turn on the
camera, GPS, etc. remotely and try to figure out where the device is - I
understand iPhones can do this), and maybe that should just be built
into the TCB rather than being an add-on.  But this does point at a
general hole in the implicit authorization model: you can't use it to
grant authorization to do something under programmatic conditions at
some time in the future.  Maybe there could be a special scheduler
powerbox for that, though.

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
In reply to this post by Adrienne Porter Felt
On Apr 13, 2012, at 10:37 PM, Adrienne Porter Felt wrote:

>
> On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski <[hidden email]> wrote:
> Even from my casual poking around in app stores its clear many mobile camera apps are applying realtime custom filters in preview, so we'd need a pretty compelling case to discourage that entire class of functionality.
>
> Yes.  I had not realized that applications actively edited streams of data during the preview phase.  This is indeed a problem with the approach.  We don't want people to have to click an extra button (one to start preview and another to capture) -- we'd been hoping that fitting the permission granting to the capture action would implicitly add the permission prompt to the user's flow without adding an extra step.
>  
> Put another way, maybe your proposal is how we handle the user agent mediated approach, but apps can still request direct access to camera via a more traditional, persist able permission dialog?
>
> I do agree that the proposal is mostly the same: I think that the permission should be granted at run-time, and there should be a notification.  However, the way that the actual permission prompt is shown to the user is very important, and a runtime dialog is not equivalent to a magic permission button.  Traditional permission dialogs do not work (there are many, many studies that show this).  The traditional permission dialog gets in the way, so people want to click through it as fast as possible in most cases, which leads them to click through as fast as possible out of habit every time.  A special "capture" button isn't an extra step -- it's the same step that people take in most camera apps.
>
> I'm trying to brainstorm a new way to fit trusted UI into the user's normal flow that would enable preview modification, without throwing up a standard dialog.  If anyone buys my case that we need such a thing, suggestions for how to get around the preview problem would be awesome.  :)

Instead of this button being embedded in the app, could it be provided in the door hanger?
  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

Lucas Adamski-2
In reply to this post by Lucas Adamski-2
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
>
> == Certified (vouched for by trusted 3rd party) ==
> Authorization model: implicit
> Potential mitigations: Settings manager could enumerate which apps have implicit access to camera.

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

Re: WebAPI Security Discussion: Camera API

Randell Jesup-3
In reply to this post by Lucas Adamski-2
[Grrr.  Silly tbird messing up quotes below...  Resent because direct
posting from Emacs/Gnus keeps getting flagged as needing moderator approval]

 >There _is_ a more powerful capability that we may want to have
available to
 >a small handful of apps: "turn on the camera at some indefinite time
in the
 >future, without user interaction at the time".  The only use case I can
 >think of for that is an anti-device-theft system (turn on the camera, GPS,
 >etc. remotely and try to figure out where the device is - I understand
 >iPhones can do this), and maybe that should just be built into the TCB
 >rather than being an add-on.  But this does point at a general hole in the
 >implicit authorization model: you can't use it to grant authorization
to do
 >something under programmatic conditions at some time in the future.  Maybe
 >there could be a special scheduler powerbox for that, though.

That need is exactly what some WebRTC apps need (think VoIP-like service
- replacement for Skype, Google Hangouts were you want a
user-controlled/styled answer/call/etc buttons - you get the idea).

Users will not want to go through a security request on each call, and
app developers will not want to have "fixed" call/end buttons they can't
style (and I don't think this works anyways).

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

--
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: WebAPI Security Discussion: Camera API

Randell Jesup-3
In reply to this post by Lucas Adamski-2
[Grrr.  Silly tbird messing up quotes below...  Resent because direct
posting from Emacs/Gnus keeps getting flagged as needing moderator
approval]

 >There _is_ a more powerful capability that we may want to have
available to
 >a small handful of apps: "turn on the camera at some indefinite time
in the
 >future, without user interaction at the time".  The only use case I can
 >think of for that is an anti-device-theft system (turn on the camera,
GPS,
 >etc. remotely and try to figure out where the device is - I understand
 >iPhones can do this), and maybe that should just be built into the TCB
 >rather than being an add-on.  But this does point at a general hole in
the
 >implicit authorization model: you can't use it to grant authorization
to do
 >something under programmatic conditions at some time in the future.  
Maybe
 >there could be a special scheduler powerbox for that, though.

That need is exactly what some WebRTC apps need (think VoIP-like
service - replacement for Skype, Google Hangouts where you want a
user-controlled/styled answer/call/etc buttons - you get the idea).

Users will not want to go through a security request on each call, and
app developers will not want to have "fixed" call/end buttons they can't
style (and I don't think this works anyways, at least not well enough to
consider).

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

--
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: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
In reply to this post by Zack Weinberg-2
I spent yesterday afternoon playing around with a lot of the most-popular
iOS camera apps.  Most of the special effects applied to previews are
extremely simple: they change the contrast, blur everything but the center,
shade everything but the center, etc.  It would be pretty simple to write
these effects as shaders that are handed over to a trusted preview window.

And, as Zack suggested, the odd corner cases can be handled by requesting
the user's authorization to go into video-recording mode.

On Tue, Apr 17, 2012 at 8:31 PM, Zack Weinberg <[hidden email]> 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.
>
> I do know a use case that won't fit into this paradigm: Photosynth (
> http://itunes.apple.com/us/**app/photosynth/id430065256?mt=**8<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<https://lists.mozilla.org/listinfo/dev-security>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Camera API

Randell Jesup-5
In reply to this post by Lucas Adamski-2
[Grrr.  Resent because direct posting from Emacs/Gnus keeps getting
flagged as needing moderator approval.
Re-resent  to mailing list because posting to the newsgroup from
thunderbird went into a black hole...]

 >There _is_ a more powerful capability that we may want to have
available to
 >a small handful of apps: "turn on the camera at some indefinite time
in the
 >future, without user interaction at the time".  The only use case I can
 >think of for that is an anti-device-theft system (turn on the camera,
GPS,
 >etc. remotely and try to figure out where the device is - I understand
 >iPhones can do this), and maybe that should just be built into the TCB
 >rather than being an add-on.  But this does point at a general hole in
the
 >implicit authorization model: you can't use it to grant authorization
to do
 >something under programmatic conditions at some time in the future.  
Maybe
 >there could be a special scheduler powerbox for that, though.

That need is exactly what some WebRTC apps need (think VoIP-like
service - replacement for Skype, Google Hangouts where you want a
user-controlled/styled answer/call/etc buttons - you get the idea).

Users will not want to go through a security request on each call, and
app developers will not want to have "fixed" call/end buttons they can't
style (and I don't think this works anyways, at least not well enough to
consider).

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

--
Randell Jesup
[hidden email]

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

Re: WebAPI Security Discussion: Camera API

Serge Egelman-2
We thought about this (it's in the proposal that we're currently
writing up), and there is no optimal solution.  Implicit access
through trusted UI works for *most* use cases, but there is a special
set of edge cases---mostly security apps---that require permission for
future events where the user should not be notified.  However, these
use cases are exceedingly rare (e.g., anti-theft software, proxies for
calls and/or messages a la Google Voice, etc.).

The only reasonable solution that addresses these is having a separate
installation flow (e.g., runtime dialogs don't solve this problem
either), so that the user grants consent at installation time.
However, this mechanism needs to be heavily dis-incentivized to
prevent developers from shortcutting the security model when they
don't legitimately need to.  One possible way is by requiring manual
approval/audits of applications that require this alternate
installation flow.  But we're certainly open to better suggestions.

serge

On Tue, Apr 24, 2012 at 9:50 AM, Randell Jesup <[hidden email]> wrote:

> [Grrr.  Resent because direct posting from Emacs/Gnus keeps getting
> flagged as needing moderator approval.
> Re-resent  to mailing list because posting to the newsgroup from
> thunderbird went into a black hole...]
>
>
>>There _is_ a more powerful capability that we may want to have available to
>>a small handful of apps: "turn on the camera at some indefinite time in the
>>future, without user interaction at the time".  The only use case I can
>>think of for that is an anti-device-theft system (turn on the camera, GPS,
>>etc. remotely and try to figure out where the device is - I understand
>>iPhones can do this), and maybe that should just be built into the TCB
>>rather than being an add-on.  But this does point at a general hole in the
>>implicit authorization model: you can't use it to grant authorization to do
>>something under programmatic conditions at some time in the future.  Maybe
>>there could be a special scheduler powerbox for that, though.
>
> That need is exactly what some WebRTC apps need (think VoIP-like
> service - replacement for Skype, Google Hangouts where you want a
>
> user-controlled/styled answer/call/etc buttons - you get the idea).
>
> Users will not want to go through a security request on each call, and
> app developers will not want to have "fixed" call/end buttons they can't
> style (and I don't think this works anyways, at least not well enough to
> consider).
>
> This *is* a dangerous permission to give, though it's equivalent to what
>
> users grant Skype or WebEx or Hangouts already by installing them
> (perhaps less, actually).
>
> --
> Randell Jesup
> [hidden email]
>
>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security



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

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

Re: WebAPI Security Discussion: Camera API

Adrienne Porter Felt
In reply to this post by Randell Jesup-5
>
> >There _is_ a more powerful capability that we may want to have available
> to
> >a small handful of apps: "turn on the camera at some indefinite time in
> the
> >future, without user interaction at the time".  The only use case I can
> >think of for that is an anti-device-theft system (turn on the camera, GPS,
> >etc. remotely and try to figure out where the device is - I understand
> >iPhones can do this), and maybe that should just be built into the TCB
> >rather than being an add-on.  But this does point at a general hole in the
> >implicit authorization model: you can't use it to grant authorization to
> do
> >something under programmatic conditions at some time in the future.  Maybe
> >there could be a special scheduler powerbox for that, though.
>
> That need is exactly what some WebRTC apps need (think VoIP-like
> service - replacement for Skype, Google Hangouts where you want a
> user-controlled/styled answer/call/etc buttons - you get the idea).
>

There definitely are some very powerful applications that don't fit into
the model; anti-theft is a great example.  Anti-theft apps also want to do
things like delete all your data, delete all your other apps, record
without permission, etc.  However, these are uncommon applications that
should be handled differently than Instagram.  (Also, I certainly am not
suggesting that built-in applications should be subject to the same
requirements as third-party applications.)


> Users will not want to go through a security request on each call,


I agree with this completely.  Users hate going through security requests.
 Pressing a recognizable button that means "start video" or "take photo" is
not a security request from the user's perspective, though.


> app developers will not want to have "fixed" call/end buttons they can't
> style (and I don't think this works anyways, at least not well enough to
> consider).
>

Most applications use generic iconography because it's in the developer's
best interest to use clearly-recognizable buttons.  It lets users figure
out how to use the app quickly.  Having a standard trusted button helps
towards the goal of easy-to-use applications.  A trusted button could be
slightly customizable to help it fit into certain color schemes but still
have a recognizable shape and icon.

Secondly, app developers' desires are not always directly in line with
users' best interests.  Wanting to have slightly more rounded edges on a
button is a tiny complaint, not a functionality issue.  There are lots of
things app developers will complain about.  For example, many iOS
developers would love to be able to sell users' location without the
constraint that the app has to actually provide location-based services in
order to collect location data.
_______________________________________________
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 Lucas Adamski-2
On 2012-04-24 9:50 AM, Randell Jesup wrote:

>  >a small handful of apps: "turn on the camera at some indefinite time
> in the
>  >future, without user interaction at the time".
>
> That need is exactly what some WebRTC apps need (think VoIP-like
> service - replacement for Skype, Google Hangouts where you want a
> user-controlled/styled answer/call/etc buttons - you get the idea).
>
> Users will not want to go through a security request on each call, and
> app developers will not want to have "fixed" call/end buttons they can't
> style (and I don't think this works anyways, at least not well enough to
> consider).

This is emphatically *not* "turn on X _without user interaction_ at some
programmatically-determined time in the future".  I would argue that
this is exactly the use case for OS-provided call/end buttons, and that
actual security provided to the end user trumps application bling.

There might be a valid case for offering a small amount of stylability
on the buttons, e.g. round/square, variable size, controllable
background color (watch out for the "black icon on black background"
trick, though) -- CSS makes this quite easy.

And maybe some UX team time should go into writing a HIG document.

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

Jason Miller-10
In reply to this post by Randell Jesup-3
>
> 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.


Jason Miller
519.872.0797 // developIT <http://developit.ca/> // Jason Miller
Design<http://jasonmillerdesign.com/>
*Developer of amoebaOS <https://amoebaos.com/>,
Shutterborg<http://shutterb.org/> &
more

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

Re: [b2g] WebAPI Security Discussion: Camera API

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

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

Re: [b2g] WebAPI Security Discussion: Camera API

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


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

Security on the shader: someone else needs to answer.  I do wonder about
performance of using a shader, and possible bugs - our WebGL interface
is less than perfect; my Mozilla-issued-last-summer fancy laptop cannot
use accelerated WebGL.

It does mean the app cannot do any sort of processing on the image:
white balance, object detection, etc, etc all have to be handled by the
automatic systems or applied with by user selection.  May not be an
issue. (No "smile detection" shutter (or happens after button press), no
object/face-tracking focus/contrast/etc tricks in preview, etc).

There's also the "how" we do preview in a shader.  Normally, for
streaming preview we'd use getUserMedia() (which is where we can hook
permissions, camera selection, etc) and take the MediaStream and feed it
to whatever (video elements, peerconnections, etc).  I presented a slide
deck at the IETF RTCWEB interim in Feb. on "MediaStream Security" where
we proposed using cross-origin protections to protect the data in a
mediastream from untrusted JS apps (and even allow MediaStream
Processing in JS workers, sandboxed by cross-origin protections against
feeding data back to the app from the JS worker).

>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

Before we go there ("magic buttons", etc), we need to decide if these
are even technically feasible.  The number of possible attacks involving
hidden/transparent elements, moving/re-laying out, etc, etc seems
immense and likely a rats-nest of future vulnerabilities - and you're
going to end up relying on time as part of your security flow
(i.e. don't enable button for x ms/s after it gets to a position) - I
just can't see that as a really safe (or user-friendly) UI.

I myself in the WebRTC internal discussions proposed "magic buttons"
last fall, but after discussing it internally, I agreed there was no way
I could see leading to a "safe" implementation, and if it was "safe"
users would probably hate it.

If they can be made to work... then maybe I can be convinced.  I'm less
enamoured of them than I was back then. No matter how many you try to
think of, there will be uses that don't fit your
classes/iconography/etc, and lead to a mildly confused UI ("to adjust UI
brightness automatically using the camera, please hit the 'take video'
button").  Bad example, there are better ones.


--
Randell Jesup, Mozilla Corp
remove ".news" for personal email
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
1234