allow="microphone" should authorize setSinkId

[guidou]

We have implicit consent via getUserMedia to get access to output devices. Arguably, that implicit consent should also apply to the microphone permission policy.

Chrome supports this, assetSinkId predates the speaker-selection permission policy in the spec.

The setSinkId steps currently mention only the speaker-selection policy and the selectAudioOutput steps do not mention any policy. I think both of them should mention both speaker-selection and microphone.

[jan-ivar]

This isn't about consent.

"speaker-selection" is a permission-policy which only affects iframes. Policies need to be discrete to let web developers delegate powerful features only to those iframes that should have them, because policies in allow-lists are cumulative:

<iframe src="iframe1.html" allow="camera;microphone"></iframe>
<iframe src="iframe2.html" allow="camera;microphone;speaker-selection"></iframe>

Here, only iframe2 can emit sound through non-default speakers. This discrete control seems valuable to web developers.

What's proposed here would remove web developers' ability to prevent iframe1 from emitting sound through non-default speakers if iframe1 needs the ability to ask for microphones. That seems bad for web developers.

Firefox already follows the spec here. I'd prefer if Chrome fixed crbug 388544214 to do the same.

[jan-ivar]

... the selectAudioOutput steps do not mention any policy.

They do in step 5.2: "Let descriptor be a PermissionDescriptor with its name set to "speaker-selection". ... If descriptor's permission state is "denied", reject p..."

The policy check is in permission state: "4. If there exists a policy-controlled feature for feature ... If document is not allowed to use feature, return "denied"."

[guidou]

What's proposed here would remove web developers' ability to prevent iframe1 from emitting sound through non-default speakers if iframe1 needs the ability to ask for microphones. That seems bad for web developers.

It's a valid point, but many applications are already written assuming that allow="microphone" also authorizes output devices in the iframe, based on:

1. the rationale that authorized microphones on the main frame result in implicitly authorized output devices on the main frame, so authorized microphones in the iframe should also implicitly authorize output devices in the iframe.
2. setSinkId predates the speaker-selection policy

You are right about selectAudioOutput, so we can keep it as is. Should we use permission descriptor for setSinkId as well?

[guidou]

Firefox already follows the spec here. I'd prefer if Chrome fixed crbug 388544214 to do the same.

I'd prefer if we change the spec to match Chrome's behavior, which has been in place for nearly 10 years and is what most applications on the Web have been using during that time.

[jan-ivar]

... many applications are already written assuming that allow="microphone" also authorizes output devices in the iframe,

Which applications are these? Such applications would not work in Firefox so I highly doubt there are many of them or we would have heard about it.

[guidou]

... many applications are already written assuming that allow="microphone" also authorizes output devices in the iframe,

Which applications are these? Such applications would not work in Firefox so I highly doubt there are many of them or we would have heard about it.

Last year Chromium landed a change requiring the speaker-selection policy and we got numerous breakage reports immediately. I don't remember all the applications that were affected, but enterprise users who had systems that embedded VC functionality in iframes were affected and IIRC also Google Meet. See https://issues.chromium.org/issues/331226135.
You even asked about the issue in that bug, but I missed your message at that time because it was a couple of months after that bug was closed.

[youennf]

IIRC, codepen.io is an example.

If it proves difficult to align with the spec, the best option seems to have the default value of speaker-selection policy be the value of the microphone policy. This leaves the ability for websites to explicitly set speaker selection to whatever deemed appropriate.