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

On Mon, Jun 2, 2014 at 9:19 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 02/06/2014 11:51 AM, Eric Rescorla wrote:
>
>
>
>
> 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?
>>
>>
> Excuse me for jumping into the middle of this discussion, but... if an
> application uses HTTPS with a certificate that covers multiple sub-domains
> and the user grants permission to one of them, does the permission extend
> over the same scope of the certificate (all sub-domains) or only the
> initial (sub-)domain?
>

It's scoped to Web origin.
http://tools.ietf.org/html/rfc6454

-Ekr