1752163 - Blocking microphone access on Windows allows for bugged stream through getUserMedia

Status: NEW

(Core :: WebRTC: Audio/Video, defect)

Description

[Akkuma]

Steps to reproduce:

Windows 10
Settings -> Privacy -> Microphone -> Allow apps to access your microphone -> Off

https://codepen.io/akkuma/pen/OJOPRjp?editors=0011

Actual results:

getUserMedia was able to successfully be called without any sort of system error resulting in a bugged stream

Expected results:

getUserMedia should have thrown an error with something like Permission denied by system

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Michael Froman [:mjf]]

Akkuma, thank you for your report! I'm unclear on what you mean by "bugged stream". Can you explain what is happening? Is audio being sent? Or just not showing an error in the console under developer tools?

Comment 3

[Akkuma]

(In reply to Michael Froman [:mjf] from comment #2)

Akkuma, thank you for your report! I'm unclear on what you mean by "bugged stream". Can you explain what is happening? Is audio being sent? Or just not showing an error in the console under developer tools?

By bugged stream I mean a MediaStream that is unusable. A MediaStream for an audio device that is blocked at the system level is a bugged stream as the stream is not usable in any form or fashion. Firefox should be throwing an error during a getUserMedia as it does on OS X for cameras and microphones and as it does for cameras on Windows. There are no errors as Firefox is not handling the OS level blocked device.

Comment 4

[Michael Froman [:mjf]]

Akkuma,

Thank you for the clarifications. I've tried to replicate on my Win10 machine, but I see an error in the Tools->Browser Tools->Web Developer Tools console. After resizing some of the panes on the codepen screen, I can see it there too. I'll attach screen shots of my results. Can you verify that you are not seeing that error in the console (not just in the codepen output)?

Comment 5

[Michael Froman [:mjf]]

Attachment: Error in the web developer tools console

Comment 6

[Michael Froman [:mjf]]

Attachment: Error showing in resized panes of codepen

Comment 7

[Michael Froman [:mjf]]

Sorry for the duplicate comment.

Comment 8

[Akkuma]

Did you block the microphone access at the OS level on Windows? This demos what I am seeing: https://app.usebubbles.com/rewXv1YAFzEqCVFhohP6cF/firefox-windows-mic-off

Comment 9

[Michael Froman [:mjf]]

Yes, I had turned off the microphone access at the OS level, but was then hitting block, not allow when prompted in the browser so I still saw the error. The video helped clarify your STRs, thank you!

:padenot, :jib, should we be showing an audio device in the permissions prompt that has been blocked in the OS level privacy settings?

Comment 10

[Paul Adenot (:padenot)]

Probably not, I'll have a look.

Thanks for the very detailed reproduction steps!

Comment 11

[Paul Adenot (:padenot)]

When this happens, cubeb_stream_init returns -1, because IAudioClient::Initialize returns E_ACCESSDENIED.

We probably want to signal this differently than a regular error. For this we might want a new error code in cubeb. This might well be useful for other OSes.

Jan-Ivar, do you know/remember how this is handled on macOS?

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

:padenot, :jib, should we be showing an audio device in the permissions prompt that has been blocked in the OS level privacy settings?

It looks like "Allow apps to access your microphone ON/OFF" in Windows 10 Settings (and per-app equivalents) applies to all microphones (and defaults to ON?), which suggests that when OFF, getUserMedia with audio: true should fail early with NotAllowedError ahead of any prompt or device selection.

We added infrastructure for this in Bug 1487204, where front-end will checkOSPermission ahead of prompting and bail with NotAllowedError if we implement an nsOSPermissionRequest overload for Windows (currently only macOS does this) that returns PERMISSION_STATE_DENIED.

On mac, front-end additionally has code to ask the OS (to prompt the user) for permission at this point, but I don't know if Windows 10 offers that.

When this happens, cubeb_stream_init returns -1, because IAudioClient::Initialize returns E_ACCESSDENIED.

Is there a cubeb API we could use here to probe for this E_ACCESSDENIED that doesn't open the device?

The issue here is some devices like the older Microsoft LifeCam series turn on the hardware light on microphone access, and some phones have motorized popout cameras that we've accidentally triggered in the past (though I forget if audio access alone triggered it).

Comment 13

[Paul Adenot (:padenot)]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #12)

:padenot, :jib, should we be showing an audio device in the permissions prompt that has been blocked in the OS level privacy settings?

It looks like "Allow apps to access your microphone ON/OFF" in Windows 10 Settings (and per-app equivalents) applies to all microphones (and defaults to ON?), which suggests that when OFF, getUserMedia with audio: true should fail early with NotAllowedError ahead of any prompt or device selection.

We added infrastructure for this in Bug 1487204, where front-end will checkOSPermission ahead of prompting and bail with NotAllowedError if we implement an nsOSPermissionRequest overload for Windows (currently only macOS does this) that returns PERMISSION_STATE_DENIED.

On mac, front-end additionally has code to ask the OS (to prompt the user) for permission at this point, but I don't know if Windows 10 offers that.

It doesn't look like it.

When this happens, cubeb_stream_init returns -1, because IAudioClient::Initialize returns E_ACCESSDENIED.

Is there a cubeb API we could use here to probe for this E_ACCESSDENIED that doesn't open the device?

This is while opening the device, the call fails instead of opening the device. I'm going to implement this in cubeb and then we can implement the interface above with cubeb (simply opening a device will succeed or error, we don't have to start it). I have a lifecam handy to check what you mention.

Windows doesn't have an API to check this permission, in any case.