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

Requiring HTTPS is fine, but I don't want to grant permanent permissions 
to the site (i.e. permissions that will apply if I revisit the site in a 
month).   I do want the permissions to survive a page reload.   Can't we 
make this distinction?  I don't think that "past the next page reload" 
should imply "until England wins the World Cup."

- Jim
On 6/2/2014 3:33 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Jun 2, 2014 at 12:01 PM, Jim Barnett <1jhbarnett@gmail.com 
> <mailto:1jhbarnett@gmail.com>> wrote:
>
>     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.
>
>
> The assumption was that apps who wanted this to work would get 
> persistent permissions.
>
> Is there any argument for this more expansive view of permissions 
> other than to spare
> sites from implementing HTTPS?
>
> -Ekr
>
>     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
>         <mailto: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
>
>

-- 
Jim Barnett
Genesys