Re: Output device enumeration

On 5 September 2013 15:45, Justin Uberti <juberti@google.com> wrote:
>> A site can train itself on what devices to use in various ways and
>> then remember user preferences.
>
> I was with you up until this point - can you explain more about what you had
> in mind here, and how the browser and application would interact to
> accomplish this?

Yeah, I thought that might stimulate an allergic reaction :)

The basic idea is that many applications are happy to defer to users
when it comes to picking which speakers they want to use, and in a lot
of those cases, it's pretty simple: use the same speakers as last time
(or perhaps the last time that the user was performing a particular
task).  For those applications, stash the value of audioTag.sinkId
somewhere safe and use it next time.  Easy.

This doesn't help advanced applications.  In the simplest case, they
can provide the user with helpful labels like "Speakers A" and
"Speakers B" and let users relabel them.

>> I'm open to suggestions on what event might be considered a
>> kimono-lifting event, such that the device information could be
>> augmented with labels and other such niceties.  I remain opposed to
>> doing the whole "ask the user" thing all over.  We know the quality of
>> the consent is poor, and it further trains users to click through
>> these things.
>
> For communication apps, the gUM kimono lift should be sufficient; it would
> be uncommon to set audio output separately from audio input (in fact, we
> should probably surface information about which output devices are paired
> with input devices, so switching to a USB headset only requires 1 click, not
> 2).

Tying output device to a gUM permission grant is probably OK.  At that
point, it's probably all hanging out anyway ...in the sense that the
fingerprinting thing is pretty easy when you have the user's face on
camera[1].

That pairing is a good idea.  Maybe you can use the same ID, or
perhaps that's crazy talk.

Maybe you only want to display the link in the one direction, once
permission is granted (the InputDevice could have a
'correspondingOutputDeviceId' attribute that is only).  After all, the
fingerprinting surface associated with knowing that you have a headset
is perhaps useful.

I'd favour same ID unless someone finds it objectionable.

> For advanced digital audio apps, we don't have the same escape hatch.
> However, I am inclined to punt on this particular problem for now. It might
> turn out that output devices by themselves don't add a significant amount of
> fingerprinting information.

I think that the extra information you get beyond the ID might not be
that useful in practice, particularly if you have the above
capabilities.

[1] Yes, I know, not all gUM requests will show the user, but it's
amazing what you can learn from whatever is on screen.

Received on Thursday, 5 September 2013 23:09:34 UTC