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

Quite true, but there's no requirement that the app close the stream 
during this time, is there?  So the app could retain the device even 
under your model.  Isn't it more a question of the circumstances/events 
under which the app must relinquish the device, rather than length of time?

On 6/2/2014 11:57 AM, Eric Rescorla wrote:
> Except that there are plenty of pages that people leave open more or
> less indefinitely.
>
> -Ekr
>
>
>
> On Mon, Jun 2, 2014 at 8:55 AM, Jim Barnett <1jhbarnett@gmail.com 
> <mailto:1jhbarnett@gmail.com>> wrote:
>
>     Do we mean different things by "persistent"?  I would think of a
>     persistent permission as one that applied every time I went to the
>     site (i.e. over many days, weeks, months.)  What Harald is
>     describing is more what I would call "session permission" - it
>     lasts until I close the page.
>
>     - Jim
>
>     On 6/2/2014 11:51 AM, 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.
>>      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
>>
>>
>
>     -- 
>     Jim Barnett
>     Genesys
>
>

-- 
Jim Barnett
Genesys

Received on Monday, 2 June 2014 16:05:26 UTC