AW: Filtering of enumerateDevices() results

Hello all,

 

many USB headsets nowadays include a HID device for media control and for sensor information such as whether the headset is worn or not.

 

Is here any way to relate the enumerateDevices entry to the HID events of the same device such as key pressed, mouse moved and/or gamepad used?

 

BTW, if I look at the gamepad API, they do list the type and name of device explicitly. 

 

Thus, I would recommend to list the type and name of audio device optionally. It would be then for the browser to decide whether this data should be revealed or not.

 

With best regards,

 

 Christian Hoene

 

 

Von: Joe Berkovitz [mailto:joe@noteflight.com] 
Gesendet: Dienstag, 19. Mai 2015 16:30
An: Harald Alvestrand
Cc: public-media-capture@w3.org; Stefan Håkansson; Audio Working Group
Betreff: 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 <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"