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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:27 UTC