UI for getUserMedia()

Changed title; see below for why.

On 10/19/2011 7:06 AM, Tim Panton wrote:
>
> On 19 Oct 2011, at 08:13, Randell Jesup wrote:
>> This example you give raises some security issues based on the current proposals.  We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user.
>>
>> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until<something>, across multiple individual connections.
>>
>> So is this outside of the current security model, since it seems to bring in a number of new requirements?  To support this, we would need:
>>
>> 1) pre-authorization of camera/mic access
>> 2) authorization continues until a particular active state with the server ends (leaving the game)
>
> Oh, I thought that there had been some discussion on preserving authorization for a site - so that I can mark a site as
> 'trusted' and not have to see the permission request again. Without that sort of feature, rtcWEB/webRTC will get annoying _really_ fast.
> Once it is 'trusted' the game can create and tear down calls at will, with no need to fork anything.
> (I have to authorize each call separately in the current model ?!?)

This has not yet been decided; people have certainly talked to wanting 
to find ways to minimize or avoid user authorizations for certain 
classes of services, and I have also pushed such efforts, both here and 
within Mozilla.

However, at this point, no clear solution has been proposed; there are 
several ideas in play (leveraging "installed webapps", etc), but without 
some decision to modify the threat model it's tough.

Without that, the app will probably want to use UI generated by 
getUserMedia() as part of their UI.  That would also mean that the app 
would want to be able to present some indication as to *why* they're 
being asked to enable (incoming caller id, name of application since 
they may have many tabs open, etc), since they don't control the UI for 
getUserMedia() itself.  This is W3C territory, so I'm cc'ing this to 
that list.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 19 October 2011 15:04:56 UTC