Re: Proposal: Constraints as dictionaries

On 11/21/13 2:54 PM, Gili wrote:
> 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.

You lost me at healthcare. :-) Seriously, I'm interested in the use-case 
that didn't work if you can recall why it made sense.

> 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.
>

Yeah, but declaratively it is a nightmare. The webpage's general needs 
are opaque to the browser. Without legitimate use-cases we can't do now 
it seems overkill.

.: Jan-Ivar :.

Received on Thursday, 21 November 2013 22:29:08 UTC