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

Re: DeviceID - reserved values, how to express? (#173)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 12 Jun 2015 10:34:38 -0700
Message-ID: <CABkgnnV=f9ckYMY=tayFQcarkUsP0qQ6OyAuWPuCkBm0D8Axrg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 12 June 2015 at 01:28, Harald Alvestrand <harald@alvestrand.no> wrote:
> - Drop the idea of predefined DeviceIDs and ban it forevermore.

After some consideration, I think that this is the right answer.

We have to consider the use case that is raised by the audio output
API before we can decide this.  The use case audio output is
addressing is a good one, one that I believe the main spec should
handle.  That is: sites just want a way to select the configured
default.  And there are different defaults sometimes.

The model there basically assumes a pseudo-device that maps to each of
these two defaults.  That has some advantages:
 - you can actually have the browser change out a device seamlessly
 - you don't need new identification mechanisms
 - it is marginally more privacy-preserving because sites don't learn
which device is default

It also has some real disadvantages:
 - changing devices seamlessly isn't guaranteed to work
 - changing devices seamlessly isn't needed if the application watches
for ondevicechange events
 - changing devices seamlessly might result in surprising outcomes,
like resolution (or more likely) sample rate changes
 - even if we deal with this issue, the potential for confusion is greater

On balance, I think that the right answer to this is to add a new
constraint that is driven by a new enumeration:

    navigator.mediaDevices.getUserMedia({audio: {default: "communications"}})

We could also expose a new property on the enumerateDevices output to
report what the browser understands about devices.  We don't need to
expose that always, since the set of values is well known; that
eliminates the (trivial) privacy advantage of the alternative that
audio output proposes.

We need a rule for what to do with unknown or unsupported values here
(map to "multimedia" might be sensible, or maybe we can define a new
"system" value for the enum).  That's an inherent shortcoming with the
audio output proposal as it stands.
Received on Friday, 12 June 2015 17:35:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 June 2015 17:35:07 UTC