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

On 06/02/2014 01:27 PM, Eric Rescorla wrote:
>
>
>
> On Sun, Jun 1, 2014 at 11:13 PM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     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".
>
>
> And how is that different from "persistent"?

Sorry, I spoke confusingly - I've been using "long-lived" as a synonym 
for "persistent", so I was a bit confused when trying to parse your 
comment on #2.

back to your comment: I still want to understand this - given that we 
are showing an indication as long as permissions persist, why do you say 
"it's not at all OK to have them involve a long-lived permission"?

>
>     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.
>
>
> I'd like to see a precise description of what you're proposing here.

I find it easiest to describe the proposal in terms of the sequence of 
things I want to happen:

<http page loads>
getUserMedia() -> user prompt
stream is returned via success callback
stream is closed

getUserMedia() -> no user prompt
stream is returned via success callback (connected to device(s) for 
which permission was granted)

<http page reloads>
getUserMedia() -> no user prompt
stream is returned via success callback (connected to device(s) for 
which permission was granted)

<another http page loads>
getUserMedia() -> user prompt

Is there a scenario not described here that matters?




>
> -Ekr