- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Aug 2016 22:33:49 +0000
- To: public-media-capture-logs@w3.org
(I think you'll find that "stored permission" meant "persistent permission to origin across sessions" in those days. I think there's evidence of that in the spec. I don't think anyone considered realm). I agree staring at the camera light on mute is undesirable, and simultaneously I think we'd ideally want `track.enabled` to be viable here (because that's the right API). The [mediacapture spec](https://w3c.github.io/mediacapture-main/getusermedia.html#life-cycle-and-media-flow) actually says that *"When all tracks connected to a source are muted or disabled, the "on-air" or "recording" indicator for that source can be turned off; when the track is no longer muted or disabled, it MUST be turned back on."* No browser seems to implement this today. For us, there's a UX challenge in showing that the microphone is off, yet the site still has permission to turn it back on (most cameras have lights that can be turned off while leaving the in-browser recording indicator intact, but mics have no light). The purpose of "revoke-on-stop" was to guarantee that when the indicator went out, it couldn't come back on, as opposed to "blindly trusting" it wouldn't, so I'd still like to see that guarantee for that the spec. I wouldn't rule out (2) as entirely undesirable in a privacy-obsessed browser/browsing mode, but I'd nonetheless like to see us converged on `track.enabled` as the API for this use-case. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/387#issuecomment-243603052 using your GitHub account
Received on Tuesday, 30 August 2016 22:33:56 UTC