Re: comments on sensor API draft (2nd set) - resent due to format problem

I realize that this is the standard copout in W3C for privacy issues. 
However, I suspect that people will get annoyed being asked to choose 
which illumination sensor to use (when there is only one). I'm assuming 
that no prompt would be made if there were no sensors of a specific type.

Philip

On 2/14/2012 7:25 AM, Carr, Wayne wrote:
>
> Another comment – this was raised earlier on the list, but not fixed.
>
> Section 4.2 SensorRequest returns a list of available sensors.As 
> someone suggested earlier, this raises privacy issues.Specifically, a 
> list of sensors is like returning a list of codecs supported or a list 
> of fonts installed.It gives a good deal of information that could be 
> used in fingerprinting (uniquely identifying the user/device).It would 
> be better to require a match to sensor type information, have it show 
> the user the options without making them available to JavaScript code 
> and then to return to JavaScript only the single one identified and 
> approved by the user.A list of all available sensors should not be 
> returned to JavaScript.It is too much fingerprinting information.
>
> *From:*Carr, Wayne [mailto:wayne.carr@intel.com]
> *Sent:* Monday, February 13, 2012 11:22 AM
> *To:* public-device-apis@w3.org
> *Subject:* comments on sensor API draft (2nd set) - resent due to 
> format problem
>
> Passing on comments from others on sensor API draft 10 November 2011 
> version, http://dev.w3.org/2009/dap/system-info/Sensors.html
>
> 1. Section 6.1.1 lists for Attribute status: “disconnected” – this 
> state is not used. I suggest to remove it or define its use.
>
> 1.2. Section 6.1.2 functions endWatch, read and startWatch refer to 
> ILLEGAL_STATE exceptions, which are not defined. In my opinion, this 
> should probably be INVALID_STATE_ERR 
> (http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-INVALID_STATE_ERR 
> <http://www.w3.org/TR/DOM-Level-3-Core/core.html> )
>
> 2.
>
> 3.3. Section 8.1 Sensor Error defines the PERMISSION_DENIED error code 
> to be a negative -100 value even though the type is unsigned short.
>
> 4.
>
> 5.*4. **Important:*Section 6.1.2 [Constructor(SensorOptions options)]:
> This paragraph describes the algorithm for sensor lookup at 
> construction time of the object.
> From an implementer’s perspective, this requires a DOM implementation 
> to wrap a potentially asynchronous operation (cmp. findSensors()) into 
> a synchronous constructor.
> I think this should be rewritten to queue a sensor lookup task and 
> always return a SensorConncetion object in state new. When the lookup 
> task completes, state transitions should occur which are signaled 
> through “onstatuschange” or “onerror”. In  the case of a successful 
> lookup, the state should change to open. In the case of failure, it 
> should transition to error. As mentioned: Both signaled through the 
> corresponding status change handlers.
>
> 6.
>
> 7.5. In the implementation it has been useful to add a return code 
> NO_SENSOR_FOUND = 101 to section 8.1 in cases where a lookup didn’t 
> come back with any sensor result but no unforeseen error occurred.
>
>
> -- 
> Philip Gladstone
> Distinguished Engineer
> Product Development
> pgladstone@cisco.com
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ

Received on Tuesday, 14 February 2012 17:53:25 UTC