Re: [w3ctag/spec-reviews] Generic Sensor API (#110)

Overall, very polished and complete document!

The use cases for the feature nicely setup the case for the spec: 
* Restrictive or Too-Specific use cases for previously defined sensor APIs (for example, some APIs are very "high level" -- not bad in themselves, but may not address other potential "low level" uses of the sensor)
* Fragmentation on the ways sensors are exposed (e.g., various API proposals of different shapes/forms)

Scoping seems appropriate:
* Scoped to local sensors (not remote or network-based)
* No sensor discovery mechanism (limited number of sensors does not warrent it--usually only one sensor in a device per type)
  * Feature detection is the discovery mechansim for now.
* What are the scope/extents of what are considered local sensors?
  * Would be nice to see a few specifics in the Scope section. (Hinted in some examples, like Geolocation, Automotive--Ex.2, Ambient light--Ex.3, Proximity--Ex.3, Gyroscope--Ex.3)

General Thoughts:
* (plus) Unification of exposure to the web platform. Brings consistency and cohesiveness to the developer experience.
* (concern) Would it be enough motivation to transition from legacy APIs like legacy geolocation? Has this come too late?

Feature detection section was very nice! 
* Expand on the example here! Add more examples. I was confused at first since it's not clear what might be throwing and why, which let me to think it was the constructor (still not sure about that). 
  * On throwing in general: does it really help with the problems described? E.g., status of underlying hardware changing over time? Try/catch seems a pretty heavy-handed detection model compared to notification via events, but perhaps there some other reason why?

Note about Fingerprinting:
* On mitigating fingerprinting risk by limiting event rates: May not be necessary. Might be nice to suggest that the UA offer a user-control to disable the sensor for privacy reasons? 
* See: section 4 of [Unsanctioned Tracking](http://www.w3.org/2001/tag/doc/unsanctioned-tracking/#limitations-of-technical-solutions):

> In this environment, it is impractical for specification design to eliminate fingerprinting; not only would such restriction severely hobble the capability of the Web, it would also break a substantial amount of existing content. Moreover, theory confirms that we cannot expect to eliminate these problems on a general-purpose system: From a theoretical perspective, eliminating browser fingerprinting is essentially the same problem as eliminating covert channels [confinement].
>
> As a result, we cannot solve the issues that unsanctioned tracking raises through solely technical means. At times, they may be more appropriately addressed through policy (e.g., legislation and/or regulation).

Section 5.1:
* Limitation to top-level browsing context. Is this overly constrained?

Nice work and good taxonomy of low-level vs high-level (described by their readings [high level] or by their implementation [low level] )

Section 8.2 SensorReading
* DOMHishResTimeStamp -- this is generally useful for other web performance metrics... we should consider adding this to Event().

Section 8.4 SensorErrorEvent
* Should Error type rather be DOMException? (https://github.com/w3ctag/spec-reviews/issues/88)?

Section 9.1
* Incumbant Settings Object should not be used (see big red note in the link to it in HTML) and https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603.



---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/110#issuecomment-212600253