Re: Proposal: Time out for getUserMedia.

Dear Harald,

To avoid the small time periods specified by the application, we can
specify min and max limits for gUM timers. (Only between those timers, the
application can specify its time out value, otherwise gUM will not consider
the user input and gets timed out after max time expiry).

And this time out will always return to error callback only, the indication
is time_out instead of permission_denied (just like permission_denied and
remaining everything is same).
If we are returning these errors through an enum then both are same.
enum {
permission_denied,
time_out,
closed_pop_up,
.....
};

If the app is able to hack the camera in this case (with time_out error),
then I expect it can implement a similar kind of mechanism in
permission_denied case also.

Thanks,
Kiran.



On Mon, Sep 2, 2013 at 3:31 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> I worry somewhat about the security aspects of letting getUserMedia time
> out.
>
> In particular, if the prompt goes away when the timeout is done, does
>
>    getUserMedia(timeout=0.00001, success, error)
>
> give scripts an invsible way to probe for whether or not they have camera
> permission, and grab the camera if they can - something we have before said
> constitutes a security risk we don't want to provide for?
>
>          Harald
>
>
> On 08/31/2013 07:30 PM, Martin Thomson wrote:
>
>> On 31 August 2013 00:49, Kiran Kumar <g.kiranreddy4u@gmail.com> wrote:
>>
>>> I don't mean that application want complete control over this
>>>
>> Then perhaps you can explain what control you do want more precisely.
>> Otherwise, this is looking very much like a Chrome feature request to
>> me.
>>
>> I didn't find Gili's argument particularly interesting, because
>> applications can always just immediately close any granted track.
>> Also, if we ever decide to actually allow the construction of tracks
>> directly, you could close a track to cancel the associated gUM
>> request.
>>
>>
>
>