Re: Filtering of enumerateDevices() results

Harald,

Thank you for confirming and explaining.

So, accepting the current decisions about what device info is revealed and
under what circumstances, I'd like to explore two more points with you.
With your responses, the Audio WG should hopefully be in a position to know
what to ask the group for re: discovery/enumeration of output devices.

1. For audio devices, channel count and a binaural (essentially,
speaker-vs-headphone) flag are important attributes. The Audio WG thinks of
these properties as fundamental -- comparable in importance to width/height
or echo cancellation. Is there a reason they cannot be included in the set
of standard MediaTrackConstraints and in MediaTrackSettings? Section 4.1
says that channel information "might be exposed through other APIs such as
Web Audio", but the lack of exposure in Media Capture API does complicate
things for developers. If one can't use constraint queries based on channel
count or binaural, then how can getUserMedia() return a reasonable default
device? The need to call getUserMedia() before enumerating devices makes
the need for a good default even more important than it might be otherwise.

2. How would the WG feel about including more "filtered" information in the
MediaDeviceInfos returned by enumerateDevices(), other than the device
label -- information that the application can use to restrict or augment
the list of devices displayed to a user (since constraints are not accepted
by enumerateDevices())? Ideally channel count, binaural, sample rate and
other attributes such as width and height could be exposed here. This
should not pose a fingerprinting risk above and beyond the exposure of
device labels, which would already permit very specific fingerprinting.
Another approach would be to permit MediaDeviceConstraints to be submitted
to enumerateDevices() if the UA has granted permission to at least one
local device.

Thanks for your continued effort in thinking this through with the Audio
WG, it's very helpful.

...Joe

On Mon, May 18, 2015 at 4:57 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 18. mai 2015 22:48, skrev Joe Berkovitz:
> > Hi Media Capture folks,
> >
> > I am trying to confirm the intent of the MC spec with respect to the
> > filtering of device information in the result from enumerateDevices().
> > This is a prelude to the AudioWG getting back to you with a more
> > carefully thought out set of requests, as Harald requested. We want to
> > ask for things that will be easy for you to add and generate the minimum
> > of discussion and debate.
> >
> > It appears that the result is "censored" to remove user-readable device
> > names unless there is permission granted to access at least one local
> > device. I presume this has an anti-fingerprinting purpose.
> >
> > It also seems that the only way to get such permission granted is to
> > call getUserMedia() and get permission to access some device matching
> > some constraints -- which might not be the one the user actually wants
> > to use -- in order to obtain a list of alternatives.
> >
> > Now, the user might decline that permission request, but perhaps might
> > have allowed access to one of the alternative devices -- if only the app
> > could have presented a choice. However, it couldn't, because
> > enumerateDevices() wasn't allowed to offer that information yet.  This
> > seems like a Catch-22 type of situation.
> >
> > Is my understanding of the spec correct, and can you provide any
> > guidance to the situation in which an app would like to present choices
> > before asking for permission on a specific device? Is there some way
> > that the UA can ask the user for permission to share the names of
> > devices with the application, to avoid this chicken-and-egg situation?
>
> Yes, this is a correct understanding of the situation.
>
> The information available includes the device IDs, which are stable for
> a given origin (unless the user wants to reset memory to prevent
> tracking), so the API supports "give me the same device as last time",
> and the number of devices is revealed, so the JS can know if there are
> choices or not.
>
> The WG has rejected proposals to allow the client to request access to
> the information by an explicit access-granting call, preferring to bind
> the notion of getting access to information about devices tightly to
> actually asking to use a device.
>
> Harald
>
>


-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

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