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

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".
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.
>
>
>
>>         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.

Yes, I agree that we disagree here, and I'm trying to understand the 
arguments.

With the scheme you're proposing, "temporary" permissions are tied to 
the lifetime of a track object - which, given Javascript's ability to 
hang onto objects, is identical to the lifetime of the page in the case 
of Javascript that wants to hang on to permissions.

With the scheme I'm proposing, the maximum permission lifetime is tied 
to the lifetime of the page.
When we consider the scheme without reload support, they seem to have 
identical lifetimes for the case of malicious Javascript. I'm trying to 
understand why (as it seems to me) we should inconvenience the user with 
more prompts when it doesn't inconvenience an attacker.

(I agree that allowing permissions across reloads is a different topic, 
but we haven't gotten down to arguments about that yet.)
>
> -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
>
>