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

On 02/06/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?
>

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?

Thanks,
Gili

Received on Monday, 2 June 2014 16:20:16 UTC