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

On Mon, Jun 2, 2014 at 9:24 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:

>  I'm undoubtedly dense, too, but I thought that the proposal was that the
> permission would persist until the page was closed _unless_ the user
> explicitly revoked it.   I think of  a 'hang up' command as revocation, but
> I see that might not be what others expect
>

"Hang-up" is just clicking some button in the content. How does that tell
the browser that
permissions have been revoked.

-Ekr


>
>
> On 6/2/2014 12:19 PM, Eric Rescorla wrote:
>
>
>
>
> 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
>
>
>
> --
> Jim Barnett
> Genesys
>