W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

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

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Sat, 31 Aug 2013 03:43:59 -0400
Message-ID: <52219EBF.4070908@mozilla.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 :.
Received on Saturday, 31 August 2013 07:44:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC