W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2015

Draft Minutes 2015-09-17 teleconference

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 17 Sep 2015 11:31:16 -0400
To: W3C Device APIs WG <public-device-apis@w3.org>
Message-Id: <9D5D287C-BF48-42A6-B97D-219C93277ED4@fjhirsch.com>
attached are Draft Minutes from today's teleconference, 2015-09-17. Thanks Anssi for scribing.

Please note the advance plans to publish a draft of the Use Cases and Generic Sensor API, 15 October.

regards, Frederick

Frederick Hirsch
Chair, W3C Device APIs WG (DAP)



# Device APIs Working Group Teleconference

## 17 Sep 2015

See also: [IRC log][3]

## Attendees


    Anssi_Kostiainen, Dapeng_Liu, Dominique_Hazael-Massieux, Frederick_Hirsch,






## Contents

  * [Topics][4]

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

    2. [Minutes approval][6]

    3. [Generic Sensor API][7]

    4. [Adjourn][8]

  * [Summary of Action Items][9]

* * *

<trackbot> Date: 17 September 2015

<fjh> Agenda: [https://lists.w3.org/Archives/Public/public-device-

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

<fjh> Updated Wake Lock API WD published, auto update enabled

### Minutes approval

<fjh> Approve minutes from 3 Sept 2015

<fjh> proposed RESOLUTION: Minutes from 3 Sept 2015 are approved,

**RESOLUTION: Minutes from 3 Sept 2015 are approved,

### Generic Sensor API

Update and discussion of use cases and API, relationship with chartered APIs

tobie: a bit behind the schedule, now settled on the UCs

... the most interesting ones to cover

... the UC doc is informing decisions around the API

... quite a bit time spent on one of the UC, head tracking

... happy to share the concerns related to this UC

... API design, performance considerations looked at

<tobie> [https://www.youtube.com/watch?v=C7JQ7Rpwn2k][13]

tobie: AR, VR have high performance requirements, must address the motion
sickness problem -- requires very low latency

<tobie> [http://msl.cs.uiuc.edu/~lavalle/papers/LavYerKatAnt14.pdf][14]

tobie: Device Orientation couples many low-level sensors

... for serious head tracking you have to have access to the low-level sensors

<fjh> need to have vertical integration to make this work, not ready for
modularization yet

tobie: for example, v1 Oculus Rift was limited in a sense that the user had to
be stationary

... v2 allows the user to move a bit

... accelerometer, gyro, magnetomer are the low-level sensors with their own

... question is what level of these sensors we expose

... and can we do it fast enough in JS

<Zakim> fjh, you wanted to ask if this means aggregate sensors not ready for

fjh: things are often not good enough in the beginning, can be modularized at
a later stage and standardized

<Zakim> dom, you wanted to ask about privacy impact of low-latency / high-
accuracy sensor data

tobie: Mozilla is working on WebVR

... a high level head tracking specific API

... that's a solution to a specific problem

<fjh> as a spec that doesn't build on lower level standards, thus able to get
performance, I believe

tobie: seems logical to give the lowest primitives

... e.g. lowest level sensors

... concerns whether aggregating this data in web code is possible

... is de/serializing going to be a bottleneck

<fjh> anssik: take device orientation example, know there are issues with
aggregation, so now exposing lower levels

<fjh> anssik: is that valid statement

<fjh> tobie: yes

tobie: by themselves, these sensors are not very useful, sensor fusion makes
them useful

... given domain specific knowledge, you can do proper sensor fusion

<fjh> need to do this at app level, since app knows needed constraints for
performance etc

tobie: if you cannot get to the data fast enough, fusion is not meaninful

<fjh> this is hardest aspect, maybe will not resolve easily by talking

<fjh> anssik: maybe start with simpler first

<fjh> +1

<fjh> tobie: need to think ahead

<fjh> anssik: maybe moore's law will save us

dom: an interesting recent development has been asm.js, WebAssembly etc.

... we're heading toward a future where we see higher performance on the Web

... agree simpler use cases to be addressed first

... Battery Status API provide fingerprinting surface due to high accuracy of
information exposed

... does this apply to sensors

tobie: similar concerns apply to sensors as well

... keylogging, fingerprinting are valid concerns

dom: some sensors to require user consent gating

... should document these concerns and requirements

... must be adapted on case by case basis

<Zakim> anssik, you wanted to note sensor fusion has its own privacy concerns

<fjh> sensors are a huge privacy and security concern, both individually and
aggregate, related to user control, surveillance etc

<fjh> getUserMedia has dealt with similar issues

tobie: one can possibly reverse engineer the fusion process

fjh: privacy issues around gUM are still being discussed in PING

<fjh> having a lower level API is more risky in that there is more detail than
a higher level API that hides info

<fjh> better to match API to use case, hiding more information

tobie: should note in the spec, the lower you go, the more security and
privacy issues and unknowns

<fjh> suggestion to also add privacy note to generic sensor API draft that
specs that build on it can address privacy by limiting information, generic
sensor api is not used directly

tobie: in geolocation API there's a highAccuracy boolean

... could have something like that

<fjh> note that fingerprinting is not the only issue - misuse of the API for
various purposes can be even more concerning

tobie: if the use case is about figuring out if the device is oriented in
landscape or portrait, less precision needed

<fjh> tobie: saw at facebook higher bounce rate of apps asking for more
permissions, so incentive to ask for fewer permissions

tobie: could allow prompt-less access for less precision, require prompt for
high precision

fjh: fingerprinting, misuse of information, a lot of issues we cannot solve

... have to figure out the aggregation issue

... how much the head tracking will influence the work

tobie: two big issues, 1) discovery

... no good real life example how to pick the right sensor to use

... 2) rel head tracking

... the speed and quantity or the actual data reading that you pass

... how that is exposed to the application-level code

<Zakim> anssik, you wanted to ask about entropy

tobie: head tracking is a good use case, has high latency and perf

fjh: dsr might be able to help us with the discovery problem

tobie: finding a solution that works with the WoT folks

... makes sense

dom: I'd not like to put that on our critical path

<fjh> +1

<fjh> research means it is hard

dom: since this is on the research phase

... sensors can be assumed to be always present

... thus no discovery needed

<fjh> August 2015 edition of the roadmap for mobile Web apps standards

<fjh> [http://www.w3.org/2015/08/mobile-web-app-

fjh: should publish even if the discovery is not addressed

dom: people would be happy if we'd have a blueprint to fast track new sensors
to the Web Platform

... we should be able to recast ambient light, proximity, device orientation

fjh: would like to publish something soon

tobie: my goal is still to look at the UCs and spec and have them published
before TPAC

... similarly with the spec, a lot of this work is informing the API design

... no concerns shipping the documents soon


Absolute-only DeviceOrientationEvents are bad for head tracking in VR

<fjh> tobie: not a great design but attempt to solve problem, talking with
Rich Tibbett

another recent and related development is the iOS 9 Safari firing the
deviceorientation event at 60 Hz

<Zakim> fjh, you wanted to note that we need CfC for FPWD of spec due to IPR
reasons etc

fjh: I need a draft two week before publishing the FPWD

dom: for CfC we do not need ready to publish doc, but ready to review, so ED
is fine

... more important we don't delay stuff

... thus does not have to be the FPWD snapshot exactly

tobie: what is the timeline if we want to be sure we published before TPAC

fjh: pub on Tue or Thu

... latest 15th Oct for publishing

... team should have the pub ready FPWD by 8th Oct

... should have two week CfC

dom: week is enough for a CfC

... so draft must be available by 5th Oct

... to get to FPWD before TPAC

tobie: can publish UCs and the API at the same time

<fjh> Summary - docs ready for call on 1 Oct, send CfC next week, 1 CfC,
publish Oct 15

<fjh> plan to publish use cases as Note, need to be clear whether to publish
as NOTE or WD (need to indicate Note track)

### Adjourn

## Summary of Action Items

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][17] version 1.135 ([CVS

$Date: 2009-03-02 03:52:20 $

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

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

   [3]: http://www.w3.org/2015/09/17-dap-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #ActionSummary

   [10]: https://lists.w3.org/Archives/Public/public-device-

   [11]: https://lists.w3.org/Archives/Public/public-device-

   [12]: https://lists.w3.org/Archives/Public/public-device-

   [13]: https://www.youtube.com/watch?v=C7JQ7Rpwn2k

   [14]: http://msl.cs.uiuc.edu/~lavalle/papers/LavYerKatAnt14.pdf

   [15]: http://www.w3.org/2015/08/mobile-web-app-

   [16]: https://github.com/w3c/deviceorientation/issues/21

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

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

Received on Thursday, 17 September 2015 15:32:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC