RE: Why ignoring unknown mandatory constraints is not stupid

Gili,
  Every time this has been discussed, the group has decided to minimize information leakage to avoid fingerprinting.  It's certainly easier for the app if it can find out everything about the available devices up front, but our conclusion has always been to provide as little information as possible  before the user grants consent.

- Jim

-----Original Message-----
From: cowwoc [mailto:cowwoc@bbs.darktech.org] 
Sent: Friday, November 15, 2013 10:34 AM
To: public-media-capture@w3.org
Subject: Re: Why ignoring unknown mandatory constraints is not stupid

Jim,

Maybe I'm missing something, but it sounds to me like we're jumping through hoops to avoid some theoretical problem. I don't understand why this needs to be expressed in terms of a constraint. Just provide the application with a mechanism to enumerate all cameras, prompt the user for said permission, and be done with it.

I am specifically against "avoid information leakage by not saying which constraint could not be satisfied in the failure case". WebRTC is already hell to troubleshoot. I'm in favor of keeping as much diagnostics information as possible.

Gili

On 15/11/2013 9:34 AM, Jim Barnett wrote:
> Harald,
>    I take the argument to be the following:  The app really wants a 3D camera.  If the UA doesn't understand the constraint at all, is it better that it call the failure callback, saying "No there is no device that meets your constraints", or to let it return something that might be a 3D camera.
>
> Remember that the new proposal, which I support, is to avoid information leakage by not saying which constraint could not be satisfied in the failure case.
>
> I think that at the very least we need to handle the case of unknown mandatory constraints differently.  There's a difference between knowing something is not true, and not knowing whether it's true.  Furthermore, I think we may want to prompt the user differently in the presence of an unknown mandatory constraint.   In the case of known constraints, we're saying "The app wants this camera, do you give permission?".  In the other case, it's more "This camera may not be what the app needs.  Do you want to try anyway?".
>
> The presence of an unknown mandatory constraint should be signaled to the app somehow, so it knows to examine the device to see if it's usable.  There are various ways to do this.
>
> - Jim
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Friday, November 15, 2013 5:59 AM
> To: public-media-capture@w3.org
> Subject: Re: Why ignoring unknown mandatory constraints is not stupid
>
> On 11/15/2013 01:31 AM, Jan-Ivar Bruaroey wrote:
>> On 11/14/13 12:01 PM, Silvia Pfeiffer wrote:
>>> On Thu, Nov 14, 2013 at 6:36 PM, Jan-Ivar Bruaroey <jib@mozilla.com>
>>> wrote:
>>>> B) getUserMedia({ optional: [{ 3D: true }]}, success, fail); ->
>>>>                                                        Firefox 28:
>>>> something
>>>>                                                        Firefox 29: 
>>>> 3D
>>>>
>>>> It's B, because the user wants this to work, and will try to pick 
>>>> the right camera when his browser and/or camera driver are clueless.
>>>>
>>>> Reaction card (check one):
>>>>
>>>>     [  ] But he may pick the wrong thing!! Burn! 404!
>>>>     [  ] Let him play. The goal is not to control, but to make the 
>>>> experience work seamlessly or work.
>>>>
>>>> So why not:
>>>>
>>>> C) getUserMedia({ mandatory: { 3D: true } }, success, fail);->
>>>>                                                        Firefox 28:
>>>> something
>>>>                                                        Firefox 29: 
>>>> 3D
>>>>
>>>> Because Firefox 28 doesn't know it's NOT a 3D camera...
>>> So your argument is: the browser doesn't understand the constraint, 
>>> so should pass the camera through because it could potentially be 
>>> the correct device.
>> Yes, well said. Thanks for that.
>>
>> For example, if the new 3D camera also has an extremely high 
>> resolution you want, then the width/height constraints you'd add 
>> (mandatory or optional) increase the likelihood of finding this 
>> camera even on a system with an old browser and multiple cameras.
> I don't understand this argument at all.
>
> The JS programmer says "I want a 3D camera. If I can't get a 3D camera, I don't want any camera".
>
> Firefox 28 says "I have no idea whether this is a 3D camera or not. I'll pass it up just in case it's usable."
>
> I don't see how this can be constructed as acting in accordance with the programmer's wishes. If he was willing to accept a camera that was not a 3D camera, he would not have specified a mandatory constraint.
>
> Mandatory constraints guarantee that the resulting object is something that satisfies the constraints.
>
> If they don't give such a guarantee, the JS script has to recheck all the properties it depends on after it gets the device, just in case the browser chose to ignore some of them.
>
> I don't see how this makes the JS programmer's life easier.
>
>
>
>
>
>

Received on Friday, 15 November 2013 15:42:36 UTC