Re: Filtering of enumerateDevices() results

Not giving my opinion at the moment, I'd like to have other TF members'
voices heard, but one question for clarification below....

Den 19. mai 2015 16:29, skrev Joe Berkovitz:
> 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.

Query - are these distinct attributes or points on the same continuum?

ie will a monaural device always have channel count 1? Or is the
"binaural" flag specifically for the headphone case, with "each ear of
the listener hears one and only one channel"?

 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.

Query - do you think of these things as singular attributes or as a
range of possible values? IE some devices are capable of being
configured into multiple sample rates - what info would you want?

Also - what do you think of when you say "width" and "height" here? Are
you thinking of video sources, or is there something new here?

If we don't care about fingerprinting, exposing the result of calling
getCapabilities() on a device might be OK. Or not....

 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
> <mailto: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 <http://www.noteflight.com>
> "Your music, everywhere"

Received on Wednesday, 20 May 2015 08:01:15 UTC