- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Nov 2019 19:31:22 +0000
- To: public-webrtc-logs@w3.org
> A web page can set enabled to false and set it back to true whenever it wants.
For instance when the page is in the background, which might be hard to notice especially in case of microphone.
@youennf Thanks for catching that! I've filed [bug 1598374](https://bugzilla.mozilla.org/show_bug.cgi?id=1598374) on Firefox. We plan to mitigate this by firing the [muted](https://w3c.github.io/mediacapture-main/getusermedia.html#track-muted) event until page receives focus. Seems within the realm of what UAs are allowed.
> On the contrary, if a web page stops capture, the web page will not be able to restart capture in the background. If the web page stops capture for a long time, Safari will also for instance trigger a reprompt.
Recall Firefox's prompt includes camera/mic selection; horribly misplaced on unmute, and semantically different unless the app remembers
```js
{video: {deviceId: {exact: track.getSettings().deviceId}}}
```
Poorly written apps may forget chosen cam/mic on unmute, bc they didn't test w/multiple devices.
Safari uses timed permissions. The spec works hard to not mandate a singular permission model. This accommodates UA differentiation in this still evolving space, which I think is good. Had we mandated one 7 years ago, it likely would have been Chrome's. I'm glad that didn't happen.
One-off permission, like Firefox's, is [expressly permitted](https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-and-security-considerations) and follows the spec closely. For instance, look how [track stop](https://w3c.github.io/mediacapture-main/getusermedia.html#source-stopped) ties into the *Accessible* [privacy indicator](https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-indicator-requirements) (distinct from *Live*), e.g. gray vs red in Firefox.
One-off permissions are not possible without a semantic difference between *disabled* and *ended*.
The [priority of constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) suggests the spec's job is to define the best API abstraction for app writers and end-users, regardless of user agent.
Do web authors find semantic value in using `track.enabled` as the API meant to successfully implement _mute/unmute_ in all browsers? In a way that turns off the hardware light? wo/prompt?
Will end-users be able to temporarily turn off/on their camera/mic in conference calls without a prompt in all browsers? Will indicators give them confidence they're not being watched?
There is nothing preventing Safari from muting on `track.enabled = true` if too much time has passed, and prompt the user for confirmation that they're still there before unmuting.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/642#issuecomment-557237369 using your GitHub account
Received on Thursday, 21 November 2019 19:31:29 UTC