Re: The mandatory constraint is a footgun

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

>
> 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 10:02:37 UTC