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

On Mon, Jun 2, 2014 at 8:39 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  On 06/02/2014 01:27 PM, Eric Rescorla wrote:
>
>
>
>
> 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"?
>
>
> 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"?
>

Well, for starters because we have had strong consensus on this point in
the IETF security document since 2012:

http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09#section-5.2

   Because HTTP origins cannot be securely established against network
   attackers, implementations MUST NOT allow the setting of permanent
   access permissions for HTTP origins.  Implementations MAY also opt to
   refuse all permissions grants for HTTP origins, but it is RECOMMENDED
   that currently they support one-time camera/microphone access.


Any change to this will require consensus in the IETF RTCWEB WG.


>From a technical perspective, the available user interface research

strongly indicates that users are banner-blind (and of course these

indicators are often hidden in mobile applications), so I expect them

to immediately forget that they have granted permissions to this

page. Effectively you have made it impossible to grant one-time

permissions and know with any real certainty that the site has

relinquished access to the device.


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

Yes, I already object to this. This is at the heart of the distinction
between persistent
permissions and temporary permissions. Pages which want to do this should be
hosted over HTTPS and ask for persistent permissions.

-Ekr


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