Where did "speaker" feature policy go?

[jan-ivar]

I wrote #90 before realizing "speaker" was removed in w3c/webappsec-permissions-policy#360 and in Chrome. @alvestrand what happened to it?

Concerns:

1. Without it, people may permission-escalate with allow="microphone" or allow="camera" in order to use this feature. While it's true you need those permissions today to use this feature in Chrome, this may not always be so. E.g. API to request audio output device selection #86
2. There's still a "speaker" permission. Without a corresponding feature-policy, it's unclear whether this feature is available in iframes by default or not (whether you have cam/mic or not).
3. It removed consent in iframes by default, which seemed desirable.

cc @alvestrand, @guidou, @achronop

[youennf]

It would be good to decide whether this permission is for "speaker use" or "speaker selection".
I guess "speaker use" is interesting so that top level frames could mute iframes.
If you have permission to use speaker, it makes sense to allow selecting speaker for each media element of the iframe. But I am not sure it means it would grant permission to set speaker selection for the whole page (#87).

[guidou]

Chrome has never implemented a speaker permission, understood to mean an explicit permission specifically for nondefault speakers. Chrome allows setSinkId to succeed if the microphone permission has previously been granted and fails otherwise.

We have considered adding a speaker-only permission for setSinkId (to better support the non-communications cases that don't require a mic), but there has been little demand for it and an there have been concerns that an UI prompt just for speakers might be confusing to users since the default speaker does not require authorization.

The speaker feature policy code that was written in Chrome was removed because there was no implementation of a speaker permission, no mention of it in this spec, and, since the microphone permission is currently used for setSinkId, the microphone policy should work too.

[guidou]

If we add text to the spec explaining how a speaker feature policy should work, it can be brought back in Chromium, of course.

[bradisbell]

but there has been little demand for it and an there have been concerns that an UI prompt just for speakers might be confusing to users since the default speaker does not require authorization.

@guidou It's far more confusing now where users have to allow microphones when they're just choosing what soundcard to play music on. I have to do a getUserMedia() request, hope they actually have an audio input device so they can accept, then immediately stop the the tracks on the captured stream. Only then can I enumerate output devices. Even once that's done, the URL bar shows a little camera icon (additionally confusing) with a note that says, "this page is accessing your microphone."

If there is a better thread to discuss this specific issue, could you please point me to it?

[jan-ivar]

for "speaker use" or "speaker selection"

The latter. Accessing a user's non-default speakers is a "powerful feature", and would be OFF in iframes by default.

A "speaker use" permission defaulting to OFF in iframes wouldn't be web compatible, so that's a different thing. Most people have some default audio output, and there's "Block Autoplay" for that.

If you have permission to use speaker, it makes sense to allow selecting speaker for each media element of the iframe. But I am not sure it means it would grant permission to set speaker selection for the whole page

To the page being iframed, I don't see much difference, since that seems easy to work around, as I mention in #87 (comment).

[youennf]

The latter. Accessing a user's non-default speakers is a "powerful feature", and would be OFF in iframes by default.

Right, this makes sense in the context of the audio output spec, but in general, the name is misleading to me.

Allowing or not camera/microphone access is probably something much more easy to decide than allowing or not access to non-default speakers.
As a web developer, what are the guidelines to allow/disallow 'speaker' selection? What am I trying to protect the user from?

A "speaker use" permission defaulting to OFF in iframes wouldn't be web compatible, so that's a different thing. Most people have some default audio output, and there's "Block Autoplay" for that.

Sure, I was meaning a feature policy which would be ON by default and pages could explicitly set it to off.

To the page being iframed, I don't see much difference, since that seems easy to work around, as I mention in #87 (comment).

I was thinking of third-party iframes.

[jan-ivar]

What am I trying to protect the user from?

@youennf This is covered under § 3.1 Consent.

Sure, I was meaning a feature policy which would be ON by default and pages could explicitly set it to off.

I think that's a separate issue, #63 maybe.

[jan-ivar]

The speaker feature policy code that was written in Chrome was removed because there was no implementation of a speaker permission, no mention of it in this spec, and, since the microphone permission is currently used for setSinkId, the microphone policy should work too.

@guidou I think the web compat question here is did Chrome ever used to require

<iframe allow="camera; microphone; speaker">

...in order for the site to change audio output during a WebRTC call? Or did this always suffice:

<iframe allow="camera; microphone">

?

If we go back to requiring the former, what sites might break?

[youennf]

What am I trying to protect the user from?

@youennf This is covered under § 3.1 Consent.

I am not sure feature policy is really about user consent.

User agent may always control this API by advertising or not deviceIds, this is what happens with currently needing to call getUserMedia before using this API.
AFAIK, other APIs like presentation API or webkitShowPlaybackTargetPicker do not have a dedicated feature policy (maybe they should). webkitShowPlaybackTargetPicker gets consent from a device picker.

[guidou]

@guidou I think the web compat question here is did Chrome ever used to require

<iframe allow="camera; microphone; speaker">

No, it never required this.

...in order for the site to change audio output during a WebRTC call? Or did this always suffice:

<iframe allow="camera; microphone">

This always sufficed.

If we go back to requiring the former, what sites might break?

Not clear to me how to answer this, but I guess some sites might break if we start requiring the former.

[jan-ivar]

I am not sure feature policy is really about user consent.

@youennf It's Permissions Policy now, and seems explicitly about user consent. Specifically: it solves the question of to whom consent is to be granted.

Most browsers have adopted a top-level domain trust model by now, putting the onus on sites to delegate user trust to iframes. If we don't require explicit delegation of said trust, that doesn't work.

other APIs like presentation API or webkitShowPlaybackTargetPicker do not have a dedicated feature policy (maybe they should).

I'd say yes they should. Otherwise who's asking?

webkitShowPlaybackTargetPicker gets consent from a device picker.

What origin does it say is asking? Even if it doesn't say, I think most users would assume it's from the top-level domain they're on. I don't think users are well-served if we let any drive-by ad-frame masquerade as the top-level domain (when requesting user consent).

[jan-ivar]

<iframe allow="camera; microphone">

This always sufficed.

@guidou Yeah we're looking at breakage then if we introduce a "speaker" policy.

We can play web compat games like "microphone" > "speaker", but I'd hoped we wouldn't be here already. Doing so means we lose the ability to share microphone and not speaker.

Presumably someone thought having some granularity of control here made sense, hence why we have camera and microphone and not e.g. mediadevices.

[youennf]

I'd say yes they should. Otherwise who's asking?

The html video element that the user is seeing on the screen.

A "speaker-selection" policy makes sense to me when we get to a more flexible API: page wide setting, prompt user to select device, explicit values.
"microphone" inducing "speaker-selection" is not great in theory but would limit the compat risks.
In practice, the most interesting case where you want one but not the other is an iframe that gets "speaker-selection" but not "microphone".

[guest271314]

@bradisbell While the topic is actually being discussed, your feedback will be helpful at w3c/mediacapture-main#703. Have filed too many issues and bugs to list here re this subject matter, in pertinent part see w3c/mediacapture-main#650. Perhaps additional feedback, or as put, demand, will overcome the evaluation

but there has been little demand for it

[jan-ivar]

It would be good to decide whether this permission is for "speaker use" or "speaker selection".

From editors' meeting two weeks ago: landed on "speaker-selection"

[guest271314]

We have considered adding a speaker-only permission for setSinkId (to better support the non-communications cases that don't require a mic), but there has been little demand for it and an there have been concerns that an UI prompt just for speakers might be confusing to users since the default speaker does not require authorization.

"demand" for "it" (where it is capturing audio output to speakers, headphones, "What-U-Hear", and "demand" is are feature requests)

• Support capturing audio output from sound card mediacapture-main#629
• Clarify getUserMedia({audio:{deviceId:{exact:<audiooutput_device>}}}) in this specification mandates capability to capture of audio output device - not exclusively microphone input device mediacapture-main#650
• Extending Media Capture and Streams with MediaStreamTrack kind TTS mediacapture-main#654
• Either fully support or remove audio capture entirely: "MAY" re audio capture is ambiguous mediacapture-screen-share#140

Chromium issues

• https://bugs.chromium.org/p/chromium/issues/detail?id=1013881
• https://bugs.chromium.org/p/chromium/issues/detail?id=1032815

Firefox and Nightly implementation of getUserMedia() prompt, which lists Monior of <device> at Linux is not confusing.

Chromium implementation just asks for microphone permission, confusion at Chromium can arise because the user does not select any particular device and enumerateDevices() does not list the correct device if or when the default microphone is changed by the user.

• enumerateDevices() should print correct MediaDeviceInfo mediacapture-main#693

From the results of various experiments and tests it is currently impossible to capture speaker output at Chromium within the confines of the implementation of getUserMedia().