See also: IRC log
<fjh> GitHub digest: https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/0004.html
<fjh> ScribeNick: anssik_
<fjh> Approve minutes from 9 February 2017
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/att-0003/minutes-2017-02-09.html
<fjh> proposed RESOLUTION: Minutes from 9 February 2017 are approved
RESOLUTION: Minutes from 9 February 2017 are approved
<fjh> Andrey not on call, but noted on email “I have integrated the comments into the spec, including the Privacy & Security section. My plan is to move on with the implementation in Chromium."
<fjh> see https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/0008.html
fjh: I don't understand the frequency thing, need to look at privacy papers
<fjh> papers https://arxiv.org/abs/1602.04115 and https://arxiv.org/abs/1611.03748
tobie: frequency, implementers and security teams at implementers tell us the higher the freq, the more privacy and security risks
... consider if you have high freq, can figure out what someone is typing on their (onscreen) keyboard
... want to strike a balance between features and security and privacy risks
... extra point to make, contrary to what opening access to mic or camera, the understanding of the user is not yet there what the risks are for the motion sensor
... more responsibility on the user agent vendors
... if they expose too high a frequency, may expose users to risks they're not aware of
... question, can we find a frequency that strikes the balance, after which things would pivot
... answer seems to be, not much research done on that specific area
... no single paper focusing on how the increasing frequency impact threats
... already pretty bad risks at around 20 Hz
... hope we're able to allow higher frequency than 60 Hz, because it opens up important use cases
... spec makes a distinction between polling frequency and reporting frequency
... reporting freq more problematic
... one solution to say, you can increase polling frequency, but you still won't provide more than 60 samples / second
... caters for the low latency use case, VR and AR
... Navisense folks we're talking to doing indoor position with sensors, they actually need more than 60 samples / second
... examples use case 60 samples per second on very low latency, poll 120 times a second but report only 60 samples when reaching rAF
... reduce latency without exposing more data
... that's what VR typically does
... or that was the state of the art (in VR) in 2016
... it seems from what I'm looking at, VR is moving to more complex approaches, for neck position, for example
... steps 1) identify use cases and requirements
... 2) take them to browser security folks
<fjh> ScribeNick: fjh
tobie: could also use permissions API to set levels, but that might be very hard to explain to end users
mikhail: event performance matters so too high a frequence would break things
tobie: need to discuss use cases, e.g. indoor navigation, VR, all ok with tying reporting of data to animation frames, so never get higher frequency of polling
... get 2-4 samples with every animation frame
mikhail: animation rate can also be flexible
tobie: another issue
... buffer question - what if buffer is ready to accept 2 readings, but get 5 readings during that time - more to figure out
<scribe> ScribeNick: anssik_
tobie: all use cases point it is OK to funnel all readings through rAF
... polling freq you provide to the underlying layers
... reporting freq, is freq at what point you bring this information to the JS layer
... given these things happen on separate threads and you don't want to block
... must poll super fast
<fjh> ScribeNick : fjh
tobie: webVR has similar issue, original occulus paper
... using off the shelf sensors
... key problem was tatency, since people get sick from latency, traditionally combo of gyroscope and others, different values
... use 3D vector + acceleration, only data points used in v1
... calculate where head would be positioned in next frame
... issue is gyroscope drift over time
... correct with magneometer which is slow and imprecise
... poll gyroscope at 1kHz and poll magnetometer at 200Hz and combine to fix drift when fast head movement
... now can also track movement in room, using external sensors in room
... polling at 1000 per sec, using 60 per sec, to get low latency
<scribe> ScribeNick: anssik_
tobie: want to create dedicated MotionSensor spec, collect use cases for it
... derive requirements, and design an API that works for the security people
... key use cases are WebVR and AR, indoor navigation using motion sensors
... input from people doing pedometers would be useful, also audio
... report at rAF max frequency, and complement it with buffering system
mikhail: experimenting with Orientation sensor that provides alternative representations quaternion and matrix, to simplify use, avoid mathematics in Javascript
tobie: agree that's a good direction
https://lists.w3.org/Archives/Public/public-device-apis/2017Feb/0009.html
<fjh> ScribeNick: fjh
anssik_: people wanted to be able to use front or rear camera, added, reviewed by implementers
... in process of updating test suite and implementations
... implementation reviews from google and apple implementers
<anssik_> (none)