Re: Proposal: Time out for getUserMedia.

Hi,
Are there any objections on this proposal.
Can we add this to bugzilla/bug tracker, to discuss further and spec it ?

Thanks,
Kiran.


On Mon, Sep 2, 2013 at 4:09 PM, Kiran Kumar <g.kiranreddy4u@gmail.com>wrote:

> 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.
>>>
>>>
>>
>>
>