- From: Dan Burnett <dburnett@voxeo.com>
- Date: Thu, 29 May 2014 11:09:29 -0400
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On May 27, 2014, at 4:32 PM, Martin Thomson wrote: > On 27 May 2014 12:33, Harald Alvestrand <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 abhor the notion that access to one camera would automatically give access to all cameras, but given the many discussions we've heard about real estate limitations for indicators, I suspect that in practice we will only have two: one to indicate that some device is being accessed, and one to indicate that any device could be accessed. Whether we end up with separate sets for audio and video I don't know, but I don't think I've heard strong support for a separate pair of indicators for each device. Given that, in practice users may learn that "indicator on" means that any device could be turned on. By the way, single-use permissions surviving a page reload bugs me even more. One of the characteristics (call it a "feature") that I like the best about most WebRTC video calling apps is that reloading the page starts over. > > 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. >
Received on Thursday, 29 May 2014 19:28:32 UTC