Re: Hints argument & privacy concerns

On 01/19/2012 11:12 AM, Robin Berjon wrote:
> Hi Anant,
>
> On Jan 19, 2012, at 08:06 , Anant Narayanan wrote:
>> 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.
> Yes, we should definitely not support device characteristics enumeration.
I'll just raise a dissenting voice .... I think the concern here (and 
the cost of addressing that concern) is out of proportion with the 
threat; the mechanisms available for distinguishing users are so legion 
that the additional bits available from knowing that there are two 
cameras on the device, one of which supports HD quality video, is 
microscopic in comparision.

>> 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.
> Just to be clear, I presume you mean intrinsic properties of the produced stream that would apply if the stream came from somewhere else. In other words, an application can complain that it's not getting stereo sound because it needs it, but it shouldn't be able to complain that it was given the back camera when it wanted the front, right?
I think this example is limiting enough to be misleading. If we break 
the bond between "camera" and "physically part of the device on which 
the user is performing the UI interaction", categories like "front" or 
"back" become fully misleading.

For instance, conferencing units may have a room camera, a document 
camera and a lectern camera, neither of which is attached to the 
physical box; which one of these is "front"?
(this illustrates the need for SOMEONE - either browser chrome or JS API 
- to enumerate cameras, btw)
>> 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.
> +1, detailing errors is futile when the code can't do anything much about them anyway.
>
>> 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"
>>     }
>>   }
>> }
> This is borderline bikeshedding so I won't insist, but it seems to me that if you pick the right names you can avoid those two levels of nesting:
>
> {
>      "audio": false
> ,   "video": false
> ,   "channels": "2"
> ,   "quality": "voip"
> ,   "camera": "back"
> }
Minor return bikeshed: you have now assumed that there is a single 
namespace for both audio hints and video hints. I can easily imagine 
"quality" being relevant for both audio and video, but with incompatible 
semantics.

I'd prefer the two-dictionary solution. But like Robin, not strongly.

Received on Thursday, 19 January 2012 13:12:09 UTC