- From: Eric Rescorla <ekr@rtfm.com>
- Date: Sat, 7 Sep 2013 17:24:45 -0700
- To: Kiran Kumar <g.kiranreddy4u@gmail.com>
- Cc: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CABcZeBOC78fH1GJSWs0z+zYpXHeVLyLP3mpDHkt815A5QjBCoQ@mail.gmail.com>
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. >>> >>> >> >> >
Received on Sunday, 8 September 2013 00:25:52 UTC