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

On Sun, Jun 1, 2014 at 11:13 PM, Harald Alvestrand <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>
> wrote:
>
>> On 27 May 2014 12:33, Harald Alvestrand <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"?



>  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.

-Ekr