- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 02 Jun 2014 18:42:14 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <538CA966.7040500@alvestrand.no>
On 06/02/2014 06: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. OK. Now I get your argument (I think). The WG has repeatedly rejected having more API surface to manipulating permissions, so "getUserMedia" and "track.close" are the two controls we have; my proposal would be making the last one a no-op, permission-wise. I think I'd like to hear what others think, but I understand what you're saying now. > > -Ekr > >
Received on Monday, 2 June 2014 16:42:51 UTC