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

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.


On 6/2/2014 12:19 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Jun 2, 2014 at 9:04 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto: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 <mailto: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 <mailto: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
>>>>             <mailto:martin.thomson@gmail.com>> wrote:
>>>>
>>>>                 On 27 May 2014 12:33, Harald Alvestrand
>>>>                 <harald@alvestrand.no
>>>>                 <mailto: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

Received on Monday, 2 June 2014 16:25:03 UTC