Re: [Bug 22214] How long do permissions persist?

Didn't we have discussions in the past about 're-hydrating' sessions 
upon page reload?  I don't think the discussions ever got anywhere, but 
it certainly sounded at the time like we were assuming that the app 
could keep using the device without an additional prompt.

I think Harald is right that users won't expect to be reprompted after a 
page reload.  It may well be that the security issues that ekr has 
raised means that they must be, but I think that they will be 
surprised/annoyed when it happens.   (Along the lines of:  "I already 
told  you that you could use the camera.  I just reloaded the page 
because the video was looking weird  now you throw everything out and 
ask me a question that I already answered.")

On 6/2/2014 2:51 PM, Martin Thomson wrote:
> On 2 June 2014 09:42, Harald Alvestrand <harald@alvestrand.no> wrote:
>> The WG has repeatedly rejected having more API surface to manipulating
>> permissions, so "getUserMedia" and "track.close" are the two controls we
>> have; my proposal would be making the last one a no-op, permission-wise.
> Yes, I object to this.
>
> I think that this more easily leads to the surprising situation where you can:
>
> a) have the camera turn on at some future point in time
>
> and perhaps more seriously:
>
> b) have a different camera turn on
>
> Both of which I find highly objectionable.
>
> I understand that you would have the "passive" indicator present for
> the duration, but that's still pretty surprising.
>
> I need to understand how you might need this capability.  I understood
> Justin's mute scenario well enough.  Can you actually make a case for
> this?
>
> --Martin
>
> p.s., track.close() releasing permissions is a perfectly good API
> surface.  Why would you suggest that we need a different surface?
>

-- 
Jim Barnett
Genesys

Received on Monday, 2 June 2014 19:02:37 UTC