Re: UI for enabling webcam use from untrusted content

On Fri, Dec 11, 2009 at 8:40 AM, Ian Hickson <ian@hixie.ch> wrote:

> I think once we've given a site access to the bits coming from the camera,
> we've got no way of knowing what the site is doing with the data, so we
> have to treat them as equivalent.
>

Well, if there were a way for a script to be prohibited from communicating
with anything (remote servers, other processes on the system, etc.), then
you could safely give it access to the camera.  This could be a useful
security property it some cases, but probably isn't worth pursuing for the
moment.  This relates to the (un-Googlably-named) "*-Property":

http://en.wikipedia.org/wiki/Bell-La_Padula_model


> On Wed, 9 Dec 2009, Kenton Varda wrote:
> >
> > Whatever UI we end up with, I'd like to strongly suggest that it have
> > these important properties:
> >
> > A) It should be extensible to any device, including things we haven't
> > thought of.  This will allow the market to innovate and come up with new
> > and interesting devices without having to get support from us.  (Take
> > "us" to mean either w3c or browser vendors.)
>
> To some extent, yes. To some extent, this is impossible, though. For
> example, for some devices (video in particular) it makes sense to expose
> the device to the script as a stream of data, and in many cases it might
> make sense for the API to expose nothing in terms of control over the
> device (e.g. the UA or hardware can handle focus control). For other
> devices (e.g. a USB fishtank that can just be turned on or off) there's no
> return data; it's not a stream, and the only thing that the API would
> expose is a single boolean setter.
>
> I think it might make sense to user the same kind of UI for both, but I
> don't think it'd make sense to use the same API, and so the market can't
> automatically innovate without discussion.
>

Right, clearly different devices need different APIs.  But I think people
should be able to create new APIs and expose them without having to modify
their browser or talk to anyone about what they're doing.


>  5. Device Well
>
>   +-----------------------------------+
>   | [] [] [_http://www.example.c_] [] |
>   | +-------------------------------+ |
>   | |                               | |   Clicking the well shows:
>    | |  To start the video chat,     | |
>    | |  activate your camera:        | |     ## DEVICES ##
>   | |   _______                     | |     | () Webcam |
>   | |  | click |                    | |     | () Mic    |
>   | |  |_______|                    | |     +-----------+
>   | |                               | |
>   | +-------------------------------+ |
>   +-----------------------------------+
>

I imagined having two wells, one for the webcam and one for the microphone,
since these would be different capabilities with (logically, at least)
different APIs.  Having one well for both seems a little bit less intuitive
to me both on the UI side and on the scripting side, but it could work.