Re: gUM's optional constraints algorithm penalizes user-choice chasing best-match for webpage

This discussion should be on the public-media-capture list. I'll reply 
there.

On 08/31/2013 09:43 AM, Jan-Ivar Bruaroey wrote:
> In Firefox, we let users of gUM webpages choose which source to allow 
> from a subset dictated by the webpage, or choose to allow none.
>
> I believe this dictated subset is overly narrow when optional gUM 
> constraints are in play. To illustrate:
>
> Consider two phones A and B.
>
>     Phone A has both a front camera and a back camera.
>     Phone B has only a back camera.
>
>     A webpage C has this constraint = { optional: [{ facingMode:"user" 
> }] }
>
> Meaning the webpage prefers the front camera, but will work with any 
> camera.
>
> Result:
>
>     On Phone A, the webpage user may choose the front camera or nothing.
>     On Phone B, the webpage user may choose the back camera or nothing.
>
> I think instead it should be:
>
>     On Phone A, the webpage user may choose the front camera 
> (preferred), back camera, or nothing.
>     On Phone B, the webpage user may choose the back camera or nothing.
>
> Reason: From a permissions standpoint, I argue the user has as right 
> to withhold knowledge of Phone A's front camera, making it 
> indistinguishable from Phone B.
>
> Benefit: Lets a webpage affect which source is the default without 
> limiting choice.
>  e.g. lets pages on Firefox for Android default to front camera 
> without removing back option in dropdown.
>
> I believe a browser could implement this today without a webpage 
> knowing (and be blackbox spec-compliant):
>
>  1. Run the full set of tracks through the algorithm to arrive at the
>     "preferred" set (like today).
>  2. Run discarded tracks through algorithm again, but *individually*
>     and keep ones that now make it through as "non-preferred".
>  3. These tracks are valid from the webpage's point of view (it
>     doesn't know the size of the set)
>
> The reason this works is that our (unchanged) core "remove-from-list" 
> algorithm ignores zero-reducing optional constraints, which makes it 
> more lenient the smaller the starting set is.
>
> I'm curious what people think.
>
> .: Jan-Ivar :.
>