W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2015

Re: Filtering of enumerateDevices() results

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 18 May 2015 22:57:52 +0200
Message-ID: <555A5250.3020006@alvestrand.no>
To: Joe Berkovitz <joe@noteflight.com>, public-media-capture@w3.org, Stefan HÃ¥kansson <stefan.lk.hakansson@ericsson.com>
CC: Audio Working Group <public-audio@w3.org>
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.

Received on Monday, 18 May 2015 20:58:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC