RE: UI for enabling webcam use from untrusted content

Is there a difference between "displaying the video viewfinder to the user" and "recording and uploading video to a remote website"?

Should there be? It may be that I just don't like the "recording" terminology.

With local HTML5 application there are a number of scenarios where local use of the camera and/or microphone is useful, but they aren't strictly "recording" - ie, the video is manipulated locally and then thrown away.

I think asking for device permission is still a requirement in these cases, but there is a difference between this and when the video is sent to a remote site.


> -----Original Message-----
> From: [mailto:public-device-apis-
>] On Behalf Of Tran, Dzung D
> Sent: Thursday, 10 December 2009 8:45 AM
> To: Ian Hickson; Robin Berjon
> Cc:
> Subject: RE: UI for enabling webcam use from untrusted content
> > Ian wrote:
> >
> > I agree, but what UI would you propose to let the user distinguish
> Google
> > Video Chat from Hostile Evil Corp?
> >
> > Arve Bersvendsen wrote:
> >
> >   The problem here is if really
> >   belongs to and start
> >   recording company-internal meetings without your knowledge.
> Just a thought,
> I think this is orthogonal issue to the capture API. The same problem
> applies to any type of data such as credit card info, login password,
> ..etc. If the user got hi-jacked by some evil corp, then how would the
> user knows to turn off his camera or provide his credit card info.
> UI could be as simple as the <video> tag:
>              +---------------------------+
>              |                           |
>              |                           |
>              |     ( ) Video Chat        |
>              |          with Mom         |
>              |                           |
>              |                           |
>              +---------------------------+
>              | ( ) stop     * recording..|
>              +---------------------------+
> Another issue is what happen when it is covered by another application
> or hidden by a TAB page.
> Thanks
> Dzung Tran,
> -----Original Message-----
> From: Ian Hickson []
> Sent: Wednesday, December 09, 2009 02:43 AM
> To: Robin Berjon; Tran, Dzung D
> Cc:
> Subject: Re: UI for enabling webcam use from untrusted content
> On Tue, 8 Dec 2009, Robin Berjon wrote:
> >
> > A quick few notes, I've been thinking along similar lines.
> >
> > First: distinguishing audio and video is sort of a geek approach to
> > things.
> Oh I didn't mean to imply that we would actually show video and audio
> options separately. I just meant those as two different devices. If it
> helps, consider instead a built-in iSight vs an external camera, or a
> webcam and a joystick controller, or an infrared port, or a CNC lathe,
> or
> digital train controller, or a serial port, or a USB fishtank, or
> anything
> else we might want to expose one day.
> > Another related note: how many "devices" (by which I mean things that
> > the user perceives as possibly grouped) are we likely to ever want to
> > enable simultaneously?
> The question is how should we handle it when a Web page asks for more
> than
> we expected any page would ever ask.
> > The approach I've been mulling over is an enhanced infobar of sorts.
> If
> > the author requests Video (in the AV sense) you get a regular infobar
> > and have to drag (or perhaps just click the icon) of the AV abstract
> > device. There can be a little ▾ next to the icon providing further
> > options to select a specific input amongst many, or disable parts of
> it
> > if it's a conceptual device grouping many. If discarded, the bar goes
> > away. If accepted, it sticks in a form that shows that same icon with
> an
> > active Rec symbol and the appropriate affordance to turn it off
> > (including turning it off temporarily, i.e. muting). If a further
> device
> > is requested while one is active, and it is also a device that needs
> to
> > be continuously shown, then the infobar+ appears below the
> "devicebar",
> > but activating a device closes it and the device's icon moves up to
> the
> > devicebar (possibly with an animation).
> >
> > It's a little convoluted to explain, but I think it would be
> reasonably
> > straightforward to understand visually as the devicebar would appear
> > only upon device activation, would stay only so long as there are
> active
> > devices, and extra devices clearly get added to it. Assuming it's
> > possible to grant permanent access to a page/origin, the devicebar
> would
> > reappear. The more I think of it the more that's actually something
> I'd
> > like to already have for Location.
> I'd be interested in hearing browser vendors' opinions on this.
> On Tue, 8 Dec 2009, Tran, Dzung D wrote:
> >
> > I don't think the user thinks in that way when it come to video chat.
> > Just take the example of Google Video Chat. The user knows that he is
> > going to video chat with his friend. He just click on his friend name
> > and the video window shows up with his friend and they start a
> > conversation.
> >
> > IMHO, All this with enable/disable microphone and webcam devices is a
> > user experience problem.
> I agree, but what UI would you propose to let the user distinguish
> Google
> Video Chat from Hostile Evil Corp?
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
>       U+263A                /,   _.. \   _\  ;`._
> ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'

IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.

Received on Wednesday, 9 December 2009 22:24:53 UTC