Re: [w3ctag/design-reviews] Sensor APIs (#207)

We apologize for taking so long to get back to this - the thread on privacy expanded beyond what normally happens in a normal review, so we had to spend some time combing through that so we don't end up saying the same thing again.

Overall, we are happy with the spec as it stands. The bits that are of concern are obviously the privacy bits above - and could be unclear in the minutes, but the sensors (at least in the current spec) being a top level global, singular object could be improved - the implicit implication from what I understand is that this is due to the background of where this comes from, and considering the background was an understandable decision. However, from a extensibility perspective we are not entirely sure this is the best way forward.

An additional remark would be on making these sensors embed friendly components, which allow other hardware API interfaces to drag and drop them into their APIs as they wish, which the current spec doesn't seem to allow due to the limitation noted above. This mostly comes from usecases such as WebVR controllers and expanding gamepad API to accommodate sensors within a gamepad.

Following the game controller use case..

Most of the privacy concerns we had have been covered above, so we won't repeat those remarks -  aside from the remark that the concerns discussed above should be addressed. We would like to see if there is a way to avoid downsampling frequency in contexts where this would make the sensor unusable, as @annevk noted above. Putting high frequency polling behind a flag would address some level of the privacy concerns.

Aside from that, apologies for the delayed review, and thank you for bringing this up with us. We look forward to sensors becoming a first class citizen of the web.

-- 
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/design-reviews/issues/207#issuecomment-358006106