Hints argument & privacy concerns

The current getUserMedia draft contains a very simple 'options' object 
passed as the first argument that allows the web application to simply 
specify whether it needs audio, video, or both.

Scenario 2.1 ("Check out this new hat!") in the document recently sent 
out by Travis can be better served if there was a way for the web 
application to specify that it needs a snapshot from the "front" camera. 
This is one example, and one can think of several other criteria that a 
web application would like to specify in advance, in order to provide a 
better user experience.

However, exposing fine grained control over media hardware to web 
applications has serious security and privacy implications. Enumeration 
of available devices, for example, will provide several bits of data 
that will allow third parties to more easily fingerprint users.

**

Tim proposed a "Hints" object as an argument to the addStream() method 
as a way for the application to specify what expectations it requests of 
the stream. 
http://lists.w3.org/Archives/Public/public-webrtc/2011Oct/0047.html

I propose that the same object be re-used as an (optional) argument to 
getUserMedia() to allow the application to *request* certain 
characteristics of the MediaStram it wants to receive. These are merely 
requests because the UA is not obligated to fulfill them, and of course, 
the user may over-ride them at any time. Thus the application cannot be 
guaranteed to receive a MediaStream with the same characteristics it 
asked for.

However, some applications will need a minimum set of requirements in 
order to be able to function. I propose that we leave it up to the 
application to detect if the resulting stream has the characteristics it 
wants, and provide the user with an appropriate message (and perhaps 
retry with another call to getUserMedia()) if it does not.

**

Further, I propose that there should be no differentiation between a 
user denying a request or a request failing because of unavailable 
hardware, or any other unexpected reason.  This should have a minimal 
impact on the user experience as the failure case for all of these can 
be handled in a similar manner by the application.

**

To put all of this concretely, the proposed getUserMedia remains the 
same as the existing signature:

void getUserMedia(MediaStreamOptions options, 
NavigatorUserMediaSuccessCallback? successCallback, optional 
NavigatorUserMediaErrorCallback? errorCallback);

The MediaStreamOptions object is a well-defined JavaScript Object:

{
   "audio": false,
   "video": false,
   "hints": {
     "audio": {
       "channels": "1 | 2"
       "application": "general | voip | music"
     },
     "video": {
       "orientation": "front | back"
     }
   }
}

Essentially, the "hints" property is the equivalent of the Hints object 
proposed earlier on the WebRTC list. I suggest we start with a minimal 
set of hints, two for audio and one for video; and derive a process for 
adding new property and hint types.

The reasoning for separating out the hints object into it's own property 
instead of in-lining it with the first two boolean properties is to 
simplify the common case of when the application does not want to 
provide any hints:

getUserMedia({"video": true});

as opposed to an application that specifically wants the front-facing 
camera with stereo audio:

getUserMedia({
   "audio": true,
   "video": true,
   "hints": {
     "audio": {"channels": 2},
     "video": {"orientation": "front"}
   }
});

The behavior in the latter case would be to have the UA present the 
front facing camera in the authorization screen by default, while 
allowing the user to over-ride it (i.e. by switching the preview to the 
back camera, or by only choosing to provide mono audio, or no audio at all).

The error callback would only be called if either video or audio were 
requested and could not be provided, but not if any of the requested 
properties in the hints object could not be met. The error code is 
always 'PERMISSION_DENIED' as currently specified in the spec 
irrespective of whether it was because of user action or hardware failure.

**

I look forward to your comments and critique!

Thanks,
-Anant

Received on Thursday, 19 January 2012 07:07:33 UTC