Re: Proposal: Time out for getUserMedia.

Hi,
It is not new to spec timers. Many network protocols specify timers.
May I know the reason for your dislike on this.

Thanks,
Kiran.


On Sun, Sep 8, 2013 at 5:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> On Mon, Sep 2, 2013 at 3:39 AM, 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).
>>
>
> I'm pretty un-fond of picking this sort of arbitrary values.
>
> -Ekr
>
>
>
>
>> 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.
>>>>
>>>>
>>>
>>>
>>
>