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-capabilities
>> 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:28:14 UTC