Re: Constraints 2014

On 3/23/14 8:27 PM, Martin Thomson wrote:
> (No argument with the rest of it.  However...)
>
> On 23 March 2014 14:52, Jim Barnett <1jhbarnett@gmail.com> wrote:
>> The lengthiest dispute/discussion was over whether the application should be
>> notified which mandatory constraints failed.  Some people felt this made
>> fingerprinting too easy, others felt that information was important for
>> intelligent applications.   The latter group has prevailed.
> I have no idea about what is the prevailing attitude here.  However, I
> will observe that if we permit the use of immediate errors that
> include information on what mandatory constraints could not be met,
> then the difference between that and a complete enumeration of device
> capabilities is effectively nil [1].
>
> If we do provide an error indication like this, then I will - again -
> repeat that we should instead be enumerating device capabilities
> completely.  That enumeration should expose capabilities as affected
> by other users of the system.  (For the fingerprinting averse, this
> means that you get to learn about some combination of the system, and
> the other users of the system, probably both over time.)
>
> [1] If you are clever, you can almost protect a single capability by
> ordering enforcement, forcing the app to risk asking the user to probe
> its state, though that's also trivial to avoid.  For instance, if you
> a protecting resolution by enforcing its constrain last, the app can
> ask for something implausibly large.  This allows it to safely probe
> all other capabilities.  Then, if the app is willing to take the
> chance that the browser asks the user, it can reduce resolution one
> pixel at a time until the user prompt appears, thus revealing
> resolution capabilities precisely.  Protecting an unordered capability
> with many states could reduce the chance that the app successfully
> probes its state without triggering a user prompt.

Thanks Martin for this observation.

Based on this - since I am not in favor of complete enumeration before 
prompt - I vote we remove the recent addition of constraintName to 
MediaError in 
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#error-handling , 
which, incidentally, means we can use DOMError directly again.

The whole premise used to further the mini-language we've had to 
construct here, was that apps could describe their needs abstractly. I 
would like to hear the use-case that can't make due with this.

.: Jan-Ivar :.