Re: Proposal: Constraints as dictionaries

Holy #@. Can it be? It sounds like we are finally in agreement on 
something! I sense a great disturbance in the force :)

+1. This is an interesting proposal, but we can do better.

Gili

On 26/11/2013 12:32 PM, Eric Rescorla wrote:
> I am not a big fan of this proposal.
>
> If we're going to reboot the existing design, I'd rather start from
> first principles
> and try to ask what we are trying to accomplish and only then design something
>
> This proposal  doesn't seem to do so.
>
> On Wed, Nov 20, 2013 at 4:30 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> I've been asked to make a concrete proposal to fix problems brought up with
>> constraints. There are three parts (ABC).
>>
>> A. Don't violate WebIDL
>>
>>
>> Constraints must be WebIDL dictionaries. We cannot afford to reinvent
>> dictionaries or webidl just for Constraints, at this point.
> Well, we've already done what we've done. It's this proposal which is a reboot,
> not the other way around.
>
>
>
>> WebIDL dictionaries ignore unknown keys. The following tweaks in our model
>> let constraints be dictionaries:
>>
>>   1. Conservative programmer calls if
>> (!getGumKnownConstraints().hasOwnProperty("3D")) then bail
>>   2. getUserMedia({ mandatory: { 3D: true } }, succ, fail); // where 3D is
>> ignored if unimplemented
>>   3. (minor) Remove limit of one key-value pair in dictionaries in optional
>> array (over-specified)
>>   4. Keep Constrainable as a pattern, but root it in actual gUM types (remove
>> abstractions, 'any' etc.)
>>   5. Change abstract PropertyValueRange to UnsignedLongRange, FloatRange etc.
>>
>> Most controversial difference: The API for detecting browser-support for a
>> constraint is now explicit, and gUM() itself only constrains by properties
>> it knows.
> I've read your arguments, but I don't think this is an advantage.
>
> I would be fine with having a design in which you could interrogate which
> constraints the browser knows and then yourself omit mandatory constraints
> it has never heard of, but this design seems to lead to a very confusing
> notion of what "mandatory" means, as well as violating POLA.
>
>
>> B. Don't leak
>>
>>
>> Stop returning ConstraintNotSatisfiedError, because it leaks information
>> about capabilities to the website without user consent, letting a malicious
>> website paint a full picture after a few visits.
> So? For reasons we have discussed ad nauseum, trying to minimize leakage
> here seems like a fools errand. If we are revisiting the privacy question,
> I would argue to go in the opposite direction, i.e., simply allowing the
> JS to ask what the system capabilities are. That would make much of this
> much easier.
>
>
>> Instead, always bring up the permission prompt, even when there is no match.
>> The UA MUST warn the user differently of such non-matches and offer the
>> Deny-equivalent choice only. The UA MUST NOT let the user grant access to a
>> camera in this case (not because of a leak, but to give webpages an
>> invariant for known properties).
> This seems like an awful user experience.
>
>> C. New syntax
>>
>>
>> A new syntax for Constraints only, is aimed at moving us away from the
>> mandatory/optional language to a model focused on expressiveness, and away
>> from Constraints being "things" to being dictionaries used in a pattern,
>> just like Settings and Capabilities are now.
>>
>> In this syntax, Constraints is an array of Settings (dictionaries) in
>> decreasing order of preference, where a set is accepted only if all its
>> specified keys are. The first accepted set is chosen.
>>
>> To describe your camera preferences in fine detail, you provide all the
>> combinations of settings you accept, specifying only the things you care
>> about, in all the combinations you accept.
> This seems massively overcomplicated for the programmer.
>
>
>> I show a width/height example here
>> http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html
>> which in turn has a link to the original post.
>>
>> Let me elaborate on the example in the original post (sans typo):
>>
>> Consider an alternative to:
>>
>>           { mandatory: { a, b }, optional: [ { c }, { d } ] }
>>
>> like this:
>>
>>         [ { a, b, c, d }, { a, b, c }, { a, b, d }, { a, b } ]
> Wow, even this makes it clear that this is worse. God forbid I have anything
> really complicated to express.
>
> -Ekr
>

Received on Tuesday, 26 November 2013 20:36:00 UTC