Sangwhan: design flaw - this belongs to navigator. this assumes that there is only one gyroscope on the given device - or one sensor.

Travis: that's true in 99% of cases

Sangwhan: it's true in mobile cases but not with gaming headset e.g.

Travis: but those would be exposed through e.g. webvr input controllers...

Sangwhan: but these accelerometers ... ... also privacy issue which is a double-edged sword. if you reduce the amount of frequency you can sample it makes it's less useful for a lot of use cases... but at high frequency then you expose private info to the web. Where do we draw the line? The privacy concern is very valid and needs to be addressed but at the same time how do we make it useful where you do need high-frequency?

Travis: the high-frequency scenarios required permissions from the user.

Sanwhan: yes. Martin Thompson raised an issue on fingerprinting related to existence ...

Alex: from a fingerprinting perspective - we want developers who do the right thing not to create supercookies... [I think this meets that test.]

Sangwhan: question for the first part: how do we expect other specs to be able to use these as components on controlers that may contain these things? Should I bring that up or let it slide?

David: example?

Sangwhan: gamepad for example... the compoents are not easily attachable because of the way the spec is defined - as it's attached to the window.

Travis: i think it's good insight. the 99% use cases for mobile devices, etc... that have one primary gyroscope will be sufficient for a lot fo cases but ... if it's a generic interface that could be applied to headmounted controllers, etc... that could be useful. It sounds nice, but practically speaking we tend to do discoverability on top of objects poorly in the web platform.

Sanwhan: can i bring this up as an issue.

[consensus yes]

Travis: yes

David: yes

Sangwhan: even stuff like you start a game with one gamepad and then swich - that doesn't work well.

David: Some APIs that try to be general to multiple things tend to be awful, and people just make guesses/assumptions.

Travis: conversely we could way over-engineer it. (cite MediaStream camera selection ;-)

David: the other thing that can happen for taking care of new things the user plugged in is that the user agent takes care of it. That can be different from the gamepad case where you expect sensors on the gamepad.

Sangwhan: yes I will do that -

Alex: we should have concrete advice for them - e.g. use of promises

Sangwhan: I will bring that up. Could do things like request a specific granularity/frequency, and the UA chooses whether to ask the user for consent based on that.

--