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

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

>  On 06/02/2014 05:51 PM, 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.
>
>
> But I don't see why this is a change to that paragraph - "for the lifetime
> of the page" is not "permanent".
>

Because the surrounding text makes clear that there are two types of
permissions,
one-time and permanent. This clearly isn't one-time. If you want to argue
that it's
some separate thing called semi-permanent, then fine, but it still doesn't
have
WG consensus.


 I may be dense.
>
>    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.
>
>
> Again, as shown near the beginning of the thread, Javascript that wants to
> retain permission for the lifetime of the page can do so by keeping a clone
> of the track open. How does relinquishing the grant improve security
> against malicious Javascript?
>
> I *must* be dense.
>

In the model where the JS has to explicitly hold on to the track, then when
the user clicks
"hang-up" he can verify for himself whether the various permissions indicia
go away, and therefore he can tell that *even if the JS was malicious* it
still can't
get access to the camera. By contrast, if you tie the permission to the
lifetime of
the page, no matter what the app tells the user, he cannot distinguish
between
the case where it might later decide to grab the device and the case where
it
might not and the only way he has to be absolutely certain is to close the
tab.

The basic problem is that you are designing a system in which the default
setting
will encourage the user to ignore the fact that the indicator which means
that the
page might later decide to reactivate the camera is showing a very large
fraction
of the time. That's bad.

-Ekr