Re: The mandatory constraint is a footgun

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.

>   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!

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.

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.

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 :.

Received on Wednesday, 13 November 2013 08:30:31 UTC