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

RE: Hints argument & privacy concerns

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Fri, 20 Jan 2012 08:08:15 +0000
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381F3DA2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
>-----Original Message-----
>From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>Sent: Thursday, January 19, 2012 8:41 AM
>To: public-media-capture@w3.org
>Subject: Re: Hints argument & privacy concerns
>On 01/19/2012 04:14 PM, Randell Jesup wrote:
>> On 1/19/2012 9:17 AM, Stefan Hakansson LK wrote:
>>> On 01/19/2012 02:53 PM, Robin Berjon wrote:
>>>> Option B. Having "front" and "back" is a sufficient ontology for the
>>>> 80% case. Given that users can *always* choose which device they want
>>>> to use (i.e. if the request hint is for "front" because that makes
>>>> sense to a conferencing scenario, I can still pick "back" because I'm
>>>> setting up conferencing for someone else, or I can still pick "room"
>>>> if I want to - the app doesn't need to know) it doesn't break the
>>>> remaining 20%, or in fact make them substantially less usable.
>>>> I like option B best :) It works for the more common cases, and it
>>>> doesn't break the less common ones.
>>> I have basically the same view. But what is needed in the less common
>>> cases is that the browser can show a pre-view to the user of all cameras
>>> in some kind of selector so that the user can pick the right view
>> We've been assuming that the typical implementation of GetUserMedia
>> would be to show the user all the cameras -- preferably with a preview
>> of each if possible, though lower resolution and perhaps low frame rate,
>> or if that's infeasible just a list and a preview pane -- and let them
>> choose.  (Similar for audio, though with a different mechanism for
>> preview.)  The hint could control which is the defaulted selection.
>Matches my view exactly!

It turns out that figuring out front vs back is also a hard problem for User Agents because (at least in Windows) the OS can only provide this information if the hardware device encodes it -- which means that only devices with built-in cameras can be identified as such.

Another creative option that I've heard suggested is a simple "next" or "swap" API on the MediaStream that just cycles through the available cameras/mic. As was mentioned--the best way to reliably select the desired camera is to see the camera's preview. If the user wants the "other" one, they can just "swap" the MediaStream over to it.

Food for thought.

Regarding the fingerprinting issue with enumeration of devices/characteristics--I understand that the risk of enumeration is in providing it _before_ user approval, right? So, what if it's available only _after_ user approval? (e.g., first the developer hints at what they want, then the user selects a device, then the developer can verify if the user's choice is suitable for the application and fail/succeed at that point?)
Received on Friday, 20 January 2012 08:09:32 UTC

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