RE: Revised Constraints modification API proposal

> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> On 08/22/2012 08:44 PM, Travis Leithead wrote:
> >> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> >>
> >>> From: Dan Burnett [mailto:dburnett@voxeo.com] On Aug 21, 2012, at
> >>> 4:56 PM, Travis Leithead wrote:
> >>>> As a reminder, the goal of this proposal is to facilitate "informed
> >>>> constraints" (i.e., allow constraints to be applied after existing
> >>>> client capabilities are known) in order to avoid potential pitfalls
> >>>> of blindly over-constrained use of getUserMedia across a range of
> >>>> different
> >>> devices.
> >>>
> >>> I always wanted to have capabilities along with constraints, and I'm
> >>> pleased to see (finally) a realistic capabilities proposal.  Given
> >>> that we will not always have capabilities available for privacy
> >>> reasons, I'd like to understand better these "potential pitfalls of
> >>> blindly over-constrained use".  I have heard that mentioned but have
> >>> not yet seen enough evidence to convince me that this is a real problem.
> >> Could you point me to some examples?
> >
> > Well, there have been a few discussions on this in the past. The big
> > hangup I have with it, is the ability to make pretty much any optional
> > constraint a mandatory constraint.
> >
> > This, in theory, leads to potentially goofy mandatory constraints like
> > "must have a flash" which causes every device without a flash to be
> > flat-out rejected. My general belief is that while the developer is
> > trying to be helpful, it's really up to the user to determine what is
> > acceptable. If the video appears too dark, then try to turn on the
> > flash, but don't have the UA enforce that constraint before giving the user
> a chance to try it out.
> >
> > Obviously, I'm OK with video/audio as mandatory constraints. This is
> > because those are really not constraints, but device selection
> > criteria. Perhaps there's some room here for compromise, but as the
> current design stands, I'm not comfortable with it.
> >
> >
> And if the application is one like my "Android "Search Light"
> application, where the whole, only, and complete point of the application is
> to turn on the flash?
> 
> I wouldn't like to constrain applications to only those that use devices in the
> ways we expect.

It sounds like the concern is one of the UX for consent every time your "Search Light" app runs. I would expect "an app" (versus a web page) to persist permissions and not ask every time (or not to ever ask for permission, if that's the design of the app model). This is more a question of trusted vs. untrusted environments.

Received on Thursday, 23 August 2012 17:52:13 UTC