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

On 06/02/2014 05:04 AM, Eric Rescorla wrote:
>
>
>
> On Tue, May 27, 2014 at 1:32 PM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 27 May 2014 12:33, Harald Alvestrand <harald@alvestrand.no
>     <mailto:harald@alvestrand.no>> wrote:
>     > The discussion I heard at the Media Capture TF meeting was
>     approximately
>     > between two alternatives:
>     >
>     > 1) Permission persists until the device is released by all
>     tracks sourced
>     > from it.
>     >
>     > 2) Permission persists until the page is closed. (This may allow
>     permissions
>     > to survive a page reload.)
>
>     The way we communicate with users is with indicators.  From that
>     perspective, either approach works.
>
>     I tend to prefer the former.  In the case where an application is
>     granted access to camera 1, we don't want to also enable access to
>     camera 2.  I think that the latter implies a greater scope to consent
>     than a single one-off interaction.
>
>     I'd also like to keep this open to a degree of interpretation.  Not
>     all browsers will reach the same conclusions.  Already, Chrome and
>     Firefox are demonstrably different and I think that the current
>     variation is within reasonable bounds.
>
>
> #2 seems to clearly violate the requirement that we only allow
> persistent permissions when the page is loaded over HTTPS.
> There are plenty of long-lived HTTP pages and it's not at all
> OK to have them involve a long-lived permission after the
> camera is closed.

That depends on the definition of "long-lived"; the interpretation I had 
earlier was "long-lived" = "survives navigating away and coming back".

Our recent Google-internal discussion about "reload" involves the 
realization that reloading a HTTP resource doesn't seem to invite any 
attack that couldn't be performed against the original connection - 
which seems to indicate that while it's an expansion of the attack 
surface, it's a small one.

The argument in favour of "reload" is that users have been taught for a 
while by state-keeping applicatios that "if anything goes wrong, hit 
reload and it will sort itself out" - and inserting a new permission 
prompt in that flow disrupts that illusion.

>
> Frankly, I thought we had resolved this point in the interim and I'mn
> quite surprised to see it re-raised here.
We had no sense of resolution after 10 minutes of discussion, so we 
deferred it to the list.