RE: The mandatory constraint is a footgun

The discussion is too nested at this point.  I can't follow it.

- Jim

-----Original Message-----
From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com] 
Sent: Wednesday, November 13, 2013 12:28 PM
To: Stefan Håkansson LK; public-media-capture@w3.org
Subject: Re: The mandatory constraint is a footgun

On 11/13/13 5:02 AM, Stefan Håkansson LK wrote:
> On 13/11/13 09:30, Jan-Ivar Bruaroey wrote:
>> On 11/12/13 8:09 PM, Stefan Håkansson LK wrote:
>>> On 12/11/13 07:05, Jan-Ivar Bruaroey wrote:
>>>> I've implemented a strict interpretation of the spec's mandatory 
>>>> constraint that treats unknown keys as unsupported, I've tried it, 
>>>> and I think it is wrong.
>>>>
>>>> Scripts should just work, so you mustn't use 'mandatory' unless you 
>>>> also code up a fallback, yet we've made it the thing people try 
>>>> first (with its marginally preferable syntax).
>>>>
>>>> With future constraints coming, 'mandatory' is an invite to fail on 
>>>> a subset of browsers, a honeypot for newbie webdevs who test only 
>>>> their favorite browser(s).
>>>>
>>>> At the same time, 'mandatory' is a sucky api for asking what the 
>>>> browser supports, because you can't just ask, you have to be 
>>>> prepared to do.
>>>>
>>>> So it is bad for simple devs who just want to do, and bad for 
>>>> advanced devs who just want to ask.
>>>>
>>>> It also goes against webidl (maybe even against the web), requiring 
>>>> implementers to circumvent dictionaries, which, as Travis points 
>>>> out, disallow detection of unknown keys for this very reason 
>>>> (future-proofing).
>>>>
>>>> ---
>>>>
>>>> Now, all this may be justified, if there were no other way.
>>>>
>>>> But I think there is another way:
>>>>
>>>> MINIMALLY:
>>>>
>>>> 1. Browsers must have a getCapabilities() query that returns which 
>>>> constraints it implements.
>>> Do you include the values as well (I mean: it is likely that width 
>>> and height will be supported, but do you include their respective 
>>> min and max values)?
>> We could do this any number of ways; reusing 
>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#dfn-capabiliti
>> es just avoids another construct. Say it returns dummy values, as the 
>> goal is just to learn, by inspecting the returned dictionary, which 
>> source settings the browser implements and which it does not.
>>
>>> I ask, because one argument against getCapabilities in the past has 
>>> been around fingerprinting. You can get info without the user at all 
>>> getting to know about it.
>> Sure, not an issue above though.
> Right.
>
>>> That is not a problem when using optional constraints with gUM 
>>> (because the user would be presented with the consent prompt). It is 
>>> a little problematic with mandatory constraints with gUM because the 
>>> app could repeat gUM with lower and lower reqs, but eventually the 
>>> user would get informed (because the constraints can be met).
>> Yes, it's 20 questions:
>>
>> "Do you have a back-facing camera?" - No "Do you have a front-facing 
>> camera with width=1920 and height=1080" - No "Do you have a 
>> front-facing camera with width=1600 and height=1200" - No "Do you 
>> have a front-facing camera with width=1280 and height=1024" - No "Do 
>> you have a front-facing camera with width=1024 and height=768" - No 
>> "Do you have a front-facing camera with width=800 and height=600" - 
>> No "Do you have a front-facing camera with width=640 and height=480"
>> - Yes You are a mountain lion!
> Exactly, that is what I meant.
>
>> Some might argue the purpose of mandatory is to discover these 
>> things, but lets assume it's value is just to limit the camera-picker 
>> list.
> That is what we're saying.
>
>> If we care about these leaks, then lets always launch the permission 
>> prompt or a button-less overconstrained prompt informing the user 
>> that they "don't have a front-facing camera" or whatever, and never 
>> return consent.
> That could be a solution.
>
> Just to be clear: I don't have the competence to judge if we should 
> care or not. I bring this up only to avoid forgetting this aspect 
> (that others have brought up in the past).

I think it makes sense to consider. Would anyone object? (Again my preference is the solution below)

>> Or, my preference, warn the user that their camera(s) may not 
>> suffice, but let them consent anyway. The webpage can then query 
>> capabilities and write "lame" in WebGL if it wants.
>>
>> .: Jan-Ivar :.

.: Jan-Ivar :.

Received on Wednesday, 13 November 2013 17:55:52 UTC