[![W3C][1]][2]

# Device and Sensors Working Group Teleconference

## 23 Feb 2017

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Mikhail_Pozdnyakov, Tobie_Langel, Anssi_Kostiainen,
Wanming_lin

Regrets

    Dominique_Hazael-Massieux

Chair

    Frederick_Hirsch

Scribe

    anssik_, fjh

## Contents

  * [Topics][5]

    1. [Welcome, scribe selection, agenda review, announcements][6]

    2. [Minutes approval][7]

    3. [Wake Lock API][8]

    4. [Generic Sensor API][9]

    5. [HTML Media Capture][10]

    6. [Other Business][11]

  * [Summary of Action Items][12]

  * [Summary of Resolutions][13]

* * *

### Welcome, scribe selection, agenda review, announcements

<fjh> GitHub digest: [https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0004.html][14]

<fjh> ScribeNick: anssik_

### Minutes approval

<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][15]

<fjh> proposed RESOLUTION: Minutes from 9 February 2017 are approved

**RESOLUTION: Minutes from 9 February 2017 are approved**

### Wake Lock API

<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][16]

### Generic Sensor API

fjh: I don't understand the frequency thing, need to look at privacy papers

<fjh> papers [https://arxiv.org/abs/1602.04115][17] and
[https://arxiv.org/abs/1611.03748][18]

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

### HTML Media Capture

[https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0009.html][19]

<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

### Other Business

<anssik_> (none)

## Summary of Action Items

## Summary of Resolutions

  1. [Minutes from 9 February 2017 are approved][20]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][21] version 1.144 ([CVS
log][22])

$Date: 2015/11/17 08:39:34 $

   [1]: https://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0006.html

   [4]: http://www.w3.org/2017/02/23-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #ActionSummary

   [13]: #ResolutionSummary

   [14]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0004.html

   [15]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/att-0003/minutes-2017-02-09.html

   [16]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0008.html

   [17]: https://arxiv.org/abs/1602.04115

   [18]: https://arxiv.org/abs/1611.03748

   [19]: https://lists.w3.org/Archives/Public/public-device-
apis/2017Feb/0009.html

   [20]: #resolution01

   [21]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [22]: http://dev.w3.org/cvsweb/2002/scribe/