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 <[email protected]>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 <[email protected]> > 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-webapi > > > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
