W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

Re: Early Holiday Present: Settings API version 6

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 19 Dec 2012 09:29:28 +0100
Message-ID: <50D17AE8.7090608@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Travis Leithead <travis.leithead@microsoft.com>, Jim Barnett <Jim.Barnett@genesyslab.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2012-12-18 20:12, Martin Thomson wrote:
> I'm inclined to address this differently.  Either:
> 1. Provide a "file" device placeholder on all browsers (crappy user
> experience because now we get false positives when apps check to see
> if the user has devices)
> 2. Create a new device ID for files when the user opts to create the
> file, which to the app appears to be a new device that was "plugged
> in" in response to their request for a mic/camera.

I like your idea with a selected file being treated as a device that 
gets plugged in as a response to getUserMedia(). It might be quite 
common user behavior to plug in new a device when the preferred webcam 
doesn't show up in the list of available devices (because it's in your 
bag on the floor). With this solution we have the option to assign this 
particular file a unique id and let it show up in getDeviceIds() as a 
"readonly" source from that point.

This might satisfy both the cases where you don't want to show some UI 
because the user doesn't have any connected devices (Mathew's case from 
Lyon), but at the same it lets the user opt in with a file for privacy 
reasons and it's gets treated as a newly connected "real" (readonly) device.

> I prefer the second, which is very much like your fourth, with one
> difference: getDeviceIds() still works.  Apps can't enumerate files (a
> good thing), but that's OK.  There are several up-sides over what you
> suggest):
>   - apps can't request a specific file
>   - apps can still see what "real" devices are present prior to
> requesting permission (necessary for some use cases)
>   - users can choose a file if the app permits it, at which point we
> can decide how much to share with the app about that file

The fact that users only can select a file if the app permits it 
conflicts with the original idea with files as replacements for devices 
for user-empowerment (as Tim nicely describes it in [1]). I'm not saying 
that we can't relax that requirement, but we have to be aware that were 
doing it.


> I'm still in two minds as to whether there is one device ID for files
> altogether or whether there is a different device ID for each file.
> I'm leaning toward the former.
> I still believe that hiding device IDs until after consent is granted
> is overly cautious.  It prevents some application usage scenarios.

Received on Wednesday, 19 December 2012 08:29:52 UTC

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