Re: [mediacapture-main] Allow device capabilities to be discoverable via enumerateDevices (#211)

Just to add a couple of reminders of the context for this:

- The reason this change is contentious at all is because of concerns over
fingerprinting using the device characteristics of output devices. The MCTF
is not going to approve any un-gated access to the signatures of output
devices, even if the devices themselves are in fact accessible.

- The MCTF chairs are not OK with opening up questions about how the
gatekeeping on output devices would work, as these belong to the Audio
Output API which is in a different scope of work from the MC API that they
are trying to lock down. We've been invited to amend the Audio Output API
and I owe the MCTF a pull request proposing how we'd like that to look.

(If you ask me, the entire Audio Output API represents a missed opportunity
for WebRTC. However, that API is deeply flawed right now and bringing any
nontrivial output device issue into scope -- like this one -- seems to
result in a yarn-pulling effect of dragging in the whole raft of output
issues.)

...Joe

On Fri, Aug 7, 2015 at 9:52 AM, Hofmann, Bill <bill.hofmann@dolby.com>
wrote:

> Hmmm.  A couple of thoughts:
>
>
>
> The spec does have some significant symmetry and consistency issues.  It
> seems well-adapted to support conferencing solutions – allowing selection
> of one or more input devices (mic, camera) with constraints, and giving _
> *implicit*_ support for access to an associated output device.  But not,
> as you noted in your comment, for more general web audio solutions, where
> output devices are as important (if not more) than input devices.
>
>
>
> There is no matching call to getUserMedia() for output devices – it’s not
> needed, since there is implicit permission granted – if the user allows use
> of a mic with a headset, the user agent can assume they’re OK with using
> the headset’s speakers.  From an architectural point of view, this feels
> like a partial solution to the general problem of audio input and output,
> and it feels like the solution does not horribly complicate the
> specification.
>
>
>
> The spec is fairly far down the road, but this feels like a real missed
> opportunity for either our WG or the Device/WebRTC WGs to properly consider
> the full set of use cases related to both input and output of media.  As a
> W3C process newbie – do others have suggestions about the right approach
> here?
>
>
>
> -Bill
>
>
>
>
>
> *From:* Joe Berkovitz [mailto:joe@noteflight.com]
> *Sent:* Thursday, August 06, 2015 9:58 AM
> *To:* Audio Working Group
> *Subject:* Fwd: [mediacapture-main] Allow device capabilities to be
> discoverable via enumerateDevices (#211)
>
>
>
> FYI -- output device characterization is not looking so good for inclusion
> in the final Media Capture spec, though input devices look likely to be
> covered by my earlier proposal, with some modification. This may have to
> wait for the Audio Output API to take shape, unless others have better
> ideas than I on how to proceed.
>
>
>
> Please see the github PR for more details:
>
>
>
> https://github.com/w3c/mediacapture-main/pull/211#issuecomment-128408222
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Dmain_pull_211-23issuecomment-2D128408222&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=12YiGsqeUAeKV0V8ml4qb0q2YsTAAaRbRtZ4FCXdtLc&e=>
>
>
>
> ---------- Forwarded message ----------
> From: *jan-ivar* <notifications@github.com>
> Date: Thu, Aug 6, 2015 at 10:18 AM
> Subject: Re: [mediacapture-main] Allow device capabilities to be
> discoverable via enumerateDevices (#211)
> To: w3c/mediacapture-main <mediacapture-main@noreply.github.com>
> Cc: Joe Berkovitz <joe@noteflight.com>
>
> @burnburn
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_burnburn&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=C63OsLLhfK5stesyliELqhk-wiPeJHhL5ovQ-XKT9Qs&e=>
> thanks for explaining the reason for the exception.
>
> Having an Audio Output spec add this makes sense to me FWIW. It might be
> worth pondering whether such a spec would be likely to extend (with the
> partial webidl keyword) either MediaTrackCapabilities or MediaDeviceInfo.
> If the latter, we may want to rename info.capabilities to
> info.inputCapabilities now to anticipate this (assuming we're still going
> ahead). *
>
> *) Because (MediaTrackCapabilities or OutputCapabilities) capabilities
> wont work, as two dictionaries are not distinguishable
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__heycam.github.io_webidl_-23dfn-2Ddistinguishable&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=YXJUFa1LoQ5Xit8KoZvb0JMbS2_2oDbtQmF-ozwZKQU&e=>
> from each other in webidl today.
>
> —
> Reply to this email directly or view it on GitHub
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Dmain_pull_211-23issuecomment-2D128408222&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=12YiGsqeUAeKV0V8ml4qb0q2YsTAAaRbRtZ4FCXdtLc&e=>
> .
>
>
>



-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"