- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Mon, 02 Jun 2014 11:55:11 -0400
- To: public-media-capture@w3.org
- Message-ID: <538C9E5F.8010809@gmail.com>
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
Received on Monday, 2 June 2014 15:55:53 UTC