- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 21 Nov 2013 17:28:40 -0500
- To: Gili <cowwoc@bbs.darktech.org>, public-media-capture@w3.org
- Message-ID: <528E8918.2050305@mozilla.com>
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