Re: Proposal: Constraints as dictionaries

On 21/11/2013 7:11 AM, Jan-Ivar Bruaroey wrote:
> On 11/20/13 8:43 PM, Gili wrote:
>> I guess I agree with Martin here. I don't mind A and C so much as B. 
>> There is a trade-off between troubleshooting and fingerprinting and I 
>> have yet to be convinced that the only solution is to remove 
>> important diagnostics information. WebRTC applications are already 
>> very difficult to troubleshoot, and this is going to make it even harder.
>
> Are you saying you need to probe the user's system without their 
> permission for diagnostic reasons?

Yes and no. If a tree falls in a forest and no one is around to hear it, 
does it make a sound? More on this below.

>
>> We need to find a solution that does not require us to choose one or 
>> the other. We should be able to get both.
>
> To me, gUM is about getting access, not probing. Get access first then 
> probe all you want. Anything else is a privacy intrusion IMHO.

I hope we can agree that there is no privacy concern in a developer 
probing their own system. I'll compare this to health care... Providing 
a mechanism for a user to detect their own medical conditions is a good 
thing (even if the webapp came off a remote server). No privacy 
violation takes place unless said data is shared with a 3rd-party 
without the user's permission.

I think someone mentioned in the past an example where the application 
didn't know what resources to access until it saw what was available. It 
went something along the lines of: "If earphones are plugged in, I want 
to open camera 1 but if earphones are not plugged in I want to open 
camera 2" or maybe it was "If a headset is plugged in, I want to use its 
microphone but if no headset is plugged in I'd like to use the default 
microphone". Having to specify this through a non-executable list of 
text constraints sounds difficult if not impossible.

Javascript is a great example of executing dynamic code within a sandbox 
to prevent it from (for example) accessing arbitrary files on disk. I'm 
advocating for a similar mechanism with an even more restrictive 
sandbox. The passed-in function that:

 1. Indicates which devices it is interested in, vs which should be
    filtered out.
 2. Log messages to the developer console for debugging purposes.

The dictionary approach is a fixed AND/OR structure. Dynamic code allows 
developers to express more sophisticated constraints in a more readable 
manner.

Gili