- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Mon, 02 Jun 2014 12:24:22 -0400
- To: public-media-capture@w3.org
- Message-ID: <538CA536.6020108@gmail.com>
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