Re: Proposal: Constraints as dictionaries

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 17:33:13 UTC