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

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.