W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

RE: UI for enabling webcam use from untrusted content

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 9 Dec 2009 14:15:11 -0800
To: Ian Hickson <ian@hixie.ch>, Robin Berjon <robin@robineko.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D312CB3D4994@orsmsx501.amr.corp.intel.com>
> 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 http://seemingly-innocent.example.com really  
>   belongs to http://sneaky-industrial-espionage.example.com 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 [mailto:ian@hixie.ch] 
Sent: Wednesday, December 09, 2009 02:43 AM
To: Robin Berjon; Tran, Dzung D
Cc: public-device-apis@w3.org
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
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 December 2009 22:16:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:03 GMT