Closed Bug 1493982 Opened 6 years ago Closed 3 years ago

SetSinkId: Implement authorization mechanism

Categories

(Core :: Audio/Video: Playback, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: achronop, Assigned: karlt)

References

Details

Attachments

(10 files, 2 obsolete files)

48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
We need a way to authorize an application to play audio through the requested output device. 

One idea is to create something similar to the gUM  authorization model for the output device (prompt the user to allow or deny the access to a device).

Chrome's authorization model is to allow any device that has been previously allowed a gUM call. Note that Chrome prompt only once, the first time, after that it remembers the answer for that site until permission is being revoked explicitly .
Blocks: 934425
Priority: -- → P3
(In reply to Alex Chronopoulos [:achronop] from comment #0)
> One idea is to create something similar to the gUM  authorization model for
> the output device (prompt the user to allow or deny the access to a device).
why not use the gUM itself? for example, the current standard allows following MediaTrackConstraints:

{audio: {deviceId: [d1.deviceId, d2.deviceId]}}

where

d1.kind == d2.kind == 'audiooutput'

> Chrome's authorization model is to allow any device that has been previously
> allowed a gUM call.
this is ugly authorization model:
1) not all devices have audio input (microphone is not connected, blocked for privacy, etc).
2) audio input is much more dangerous than audio output.
We could use something similar to gUM. The difference here is that the device is selected in advance so we want a doorhanger to allow or not the selected device.
Blocks: 1498512

Chrome's authorization model is to allow any device that has been previously allowed a gUM call.

According to crbug.com/865799 this is a bug and they are planning to create an authorization prompt for output devices.

Tried this just now on meet.google.com with the pref media.setsinkid.enabled set to true on MacOS 10.15.3 (19D76) with Firefox Nightly 76.0a1 (2020-03-29) (64-bit)

It does not work for WebRTC during the call but does work for the 'Test' audio bit (likely a local file)

What's the status?

An application will be authorized to change the sink device (execute setsinkid) if a getUserMedia with the microphone permission has been accepted. This is not the best thing to do but Chrome has been doing the same for some time now thus if we were more restrictive fewer users would use it. In addition to that, the authorization model of setsinkid is discussed actively in the spec so we will update it when a decision has been taken.

Assignee: nobody → achronop
Status: NEW → ASSIGNED
Assignee: achronop → nobody
Status: ASSIGNED → NEW

The current plan is to implement the new selectAudioOutput API for obtaining a deviceId to use with setSinkId which solves authorization.

Depends on: 1698238
Depends on: 1709474
Depends on: 1712898
Depends on: 1715419

Hi Karl, this patch adds the "speaker-selection" permissions policy which we're still missing AFAICT. Wanna commandeer it and repurpose it for selectAudioOutput, or do you have a patch in the works for this elsewhere?

Flags: needinfo?(karlt)
See Also: → 1577199

Thanks. I'd forgotten that this patch included feature policy checks for bug 1577199, which is still missing. I'll sort something out for that, but it is likely to be different enough that it may be preferable to start a new revision rather than to commandeer this patch for bug 1577199.

Flags: needinfo?(karlt)
Assignee: nobody → karlt
Status: NEW → ASSIGNED

Without this change, enumerateDevices() always returns no audiooutput devices
since https://github.com/w3c/mediacapture-output/pull/109

Mozilla will usually run the test without media.navigator.streams.fake because
fake input devices are in different groups to the output devices. The
exception is Mozilla's Mac test machines because they have no real audio input
device. With fake input devices, there are no exposed output devices to test.
Another test will be added separately to expose an output device via
selectAudioOutput().

Depends on D118438

This will be used to limit exposure of audio output devices by group id.
Exposure of microphone devices is not yet limited but covered by bug 1528042.

Depends on D118441

selectAudioOutput() grants are per-device, but getUserMedia() grants expose all
speakers associated with any microphone.

When exposed, speaker devices have labels even when there is no active capture device.

Depends on D118442

and reject with NotFoundError otherwise.

Depends on D118444

Thanks Karl, do you need me to approve Alex's patch here, or do you plan on gating this on the "speaker-selection" permissions policy in a different bug?

It might be good to land that at the same time, to not expose this API in all iframes.

Flags: needinfo?(karlt)
Blocks: 1704335
Attachment #9228256 - Attachment description: Bug 1493982 test a different device in each iteration r?jib → Bug 1493982 test a different device in each iteration r=jib
Attachment #9160390 - Attachment is obsolete: true

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

Thanks Karl, do you need me to approve Alex's patch here, or do you plan on gating this on the "speaker-selection" permissions policy in a different bug?

I have abandoned Alex's patch, thanks, and plan to cover that in bug 1577199.

It might be good to land that at the same time, to not expose this API in all iframes.

Changes here are strictly reducing the exposure of devices currently being exposed, but "speaker-selection" shouldn't take long to add if there's a good reason to wait for that.

Flags: needinfo?(karlt)
Keywords: leave-open
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/171787d11d24
remove declaration of missing EnumerateDevices() method r=jib
https://hg.mozilla.org/integration/autoland/rev/e2902ed93301
don't catch exceptions thrown by testharness asserts r=jib
https://hg.mozilla.org/integration/autoland/rev/b720ac41da2c
test a different device in each iteration r=jib
https://hg.mozilla.org/integration/autoland/rev/b10f8d05a934
use getUserMedia() to expose some output devices r=jib
https://hg.mozilla.org/integration/autoland/rev/799062439b47
Test setSinkId() before and after selectAudioOutput() r=jib
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/29498 for changes under testing/web-platform/tests
Attached file Bug 1493982 remove trailing whitespace (obsolete) —
Pushed by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/65fdb9177835
Fix trailing whitespace lint failure in setSinkId-with-selectAudioOutput.https.html
Attachment #9228926 - Attachment is obsolete: true
Upstream PR merged by moz-wptsync-bot
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d386961b7c3c
track explicitly granted audio output devices r=jib
https://hg.mozilla.org/integration/autoland/rev/a4f134902b8e
add mCanExposeMicrophoneInfo and set from getUserMedia() r=jib
Keywords: leave-open
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/35d3a828f598
limit speaker exposure in enumerateDevices() to those granted by selectAudioOutput() and getUserMedia() r=jib
https://hg.mozilla.org/integration/autoland/rev/08db56e52b6d
move GetSinkDevice() to MediaDevices for access to device exposure history r=jib
https://hg.mozilla.org/integration/autoland/rev/83c72e4bcbfe
accept only sinkIds exposed via enumerateDevices() r=jib
Regressions: 1726728
Regressions: 1731076
Blocks: 1743524
Regressions: 1719578
No longer regressions: 1719578
See Also: → 1769985
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: