13:37:57 <RRSAgent> RRSAgent has joined #dap
13:37:57 <RRSAgent> logging to http://www.w3.org/2015/09/17-dap-irc
13:37:59 <trackbot> RRSAgent, make logs world
13:37:59 <Zakim> Zakim has joined #dap
13:38:01 <trackbot> Zakim, this will be DAP
13:38:01 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:38:02 <trackbot> Meeting: Device APIs Working Group Teleconference
13:38:02 <trackbot> Date: 17 September 2015
13:52:46 <fjh> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0016.html
13:52:56 <fjh> fjh has changed the topic to: agenda https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0016.html webex - dap
13:53:20 <fjh> Chair: Frederick_Hirsch
13:53:31 <fjh> Present+ Frederick_Hirsch
13:53:51 <fjh> Topic: Welcome, scribe selection, agenda review, announcements
14:00:25 <dom> Present+ Dominique_Hazael-Massieux
14:01:38 <tobie> Present+ Tobie_Langel
14:02:05 <fjh> present+ Anssi_Kostianen
14:02:47 <anssik> anssik has joined #dap
14:02:50 <fjh> Present+ Dapeng_Liu
14:02:59 <anssik> zakim, who's here
14:02:59 <Zakim> anssik, you need to end that query with '?'
14:03:04 <anssik> zakim, who's here?
14:03:04 <Zakim> Present: Frederick_Hirsch, Dominique_Hazael-Massieux, Tobie_Langel, Anssi_Kostianen, Dapeng_Liu
14:03:06 <Zakim> On IRC I see anssik, Zakim, RRSAgent, fjh, dom, tobie, mounir_, slightlyoff, Josh_Soref, trackbot
14:03:34 <anssik> Present+ Anssi_Kostiainen
14:03:49 <anssik> Present- Anssi_Kostianen
14:04:26 <fjh> Updated Wake Lock API WD published, auto update enabled https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0008.html
14:05:25 <Dapeng_Liu> Dapeng_Liu has joined #DAP
14:06:45 <anssik> Topic: Minutes approval
14:06:55 <fjh> Approve minutes from 3 Sept 2015
14:06:56 <fjh> proposed RESOLUTION: Minutes from 3 Sept 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/att-0005/minutes-2015-09-03.html
14:07:03 <anssik> RESOLUTION: Minutes from 3 Sept 2015 are approved, https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/att-0005/minutes-2015-09-03.html
14:07:10 <anssik> Topic: Generic Sensor API
14:07:15 <anssik> Update and discussion of use cases and API, relationship with chartered APIs
14:07:36 <anssik> tobie: a bit behind the schedule, now settled on the UCs
14:07:44 <anssik> ... the most interesting ones to cover
14:08:01 <anssik> ... the UC doc is informing decisions around the API
14:08:24 <anssik> ... quite a bit time spent on one of the UC, head tracking
14:08:33 <anssik> ... happy to share the concerns related to this UC
14:08:51 <anssik> ... API design, performance considerations looked at
14:09:20 <tobie> https://www.youtube.com/watch?v=C7JQ7Rpwn2k
14:09:33 <anssik> ... AR, VR have high performance requirements, must address the motion sickness problem -- requires very low latency
14:09:41 <tobie> http://msl.cs.uiuc.edu/~lavalle/papers/LavYerKatAnt14.pdf
14:10:02 <anssik> tobie: Device Orientation couples many low-level sensors
14:10:59 <anssik> ... for serious head tracking you have to have access to the low-level sensors
14:11:07 <fjh> need to have vertical integration to make this work, not ready for modularization yet
14:11:31 <anssik> ... for example, v1 Oculus Rift was limited in a sense that the user had to be stationary
14:11:40 <anssik> ... v2 allows the user to move a bit
14:12:01 <fjh> q+
14:12:49 <anssik> ... accelerometer, gyro, magnetomer are the low-level sensors with their own issues
14:12:56 <fjh> q-
14:13:17 <fjh> q+ to ask if this means aggregate sensors not ready for standardization
14:13:43 <anssik> ... question is what level of these sensors we expose
14:13:58 <anssik> ... and can we do it fast enough in JS
14:14:00 <dom> q+ to ask about privacy impact of low-latency / high-accuracy sensor data
14:14:07 <fjh> ack fjh
14:14:07 <Zakim> fjh, you wanted to ask if this means aggregate sensors not ready for standardization
14:15:28 <anssik> fjh: things are often not good enough in the beginning, can be modularized at a later stage and standardized
14:15:59 <fjh> ack dom
14:15:59 <Zakim> dom, you wanted to ask about privacy impact of low-latency / high-accuracy sensor data
14:16:35 <anssik> tobie: Mozilla is working on WebVR
14:16:46 <anssik> ... a high level head tracking specific API
14:16:55 <anssik> ... that's a solution to a specific problem
14:16:59 <fjh> as a spec that doesn't build on lower level standards, thus able to get performance, I believe
14:17:41 <anssik> ... seems logical to give the lowest primitives
14:17:50 <anssik> ... e.g. lowest level sensors
14:18:07 <anssik> ... concerns whether aggregating this data in web code is possible
14:18:14 <anssik> q+
14:18:19 <fjh> q+ dom
14:18:34 <anssik> ... is de/serializing going to be a bottleneck
14:18:49 <fjh> ack anssik
14:19:18 <fjh> anssik: take device orientation example, know there are issues with aggregation, so now exposing lower levels
14:19:33 <fjh> anssik: is that valid statement
14:19:35 <fjh> tobie: yes
14:20:25 <anssik> tobie: by themselves, these sensors are not very useful, sensor fusion makes them useful
14:20:52 <anssik> ... given domain specific knowledge, you can do proper sensor fusion
14:21:00 <fjh> need to do this at app level, since app knows needed constraints for performance etc
14:21:07 <anssik> ... if you cannot get to the data fast enough, fusion is not meaninful
14:21:12 <anssik> q+
14:21:26 <fjh> ack anssik
14:21:40 <fjh> this is hardest aspect, maybe will not resolve easily by talking
14:21:56 <fjh> anssik: maybe start with simpler first
14:22:00 <fjh> +1
14:22:19 <fjh> tobie: need to think ahead
14:22:58 <fjh> anssik:  maybe moore's law will save us
14:23:46 <anssik> dom: an interesting recent development has been asm.js, WebAssembly etc.
14:24:26 <anssik> ... we're heading toward a future where we see higher performance on the Web
14:24:34 <fjh> q?
14:24:41 <fjh> ack dom
14:24:48 <anssik> ... agree simpler use cases to be addressed first
14:25:36 <fjh> q+
14:25:38 <anssik> ... Battery Status API provide fingerprinting surface due to high accuracy of information exposed
14:25:47 <anssik> ... does this apply to sensors
14:26:27 <anssik> tobie: similar concerns apply to sensors as well
14:26:38 <anssik> ... keylogging, fingerprinting are valid concerns
14:27:09 <anssik> dom: some sensors to require user consent gating
14:27:21 <anssik> ... should document these concerns and requirements
14:27:35 <anssik> ... must be adapted on case by case basis
14:27:54 <anssik> q+ to note sensor fusion has its own privacy concerns
14:28:16 <fjh> ack fjh
14:28:17 <fjh> q+
14:28:21 <fjh> ack anssik
14:28:21 <Zakim> anssik, you wanted to note sensor fusion has its own privacy concerns
14:29:23 <fjh> sensors are a huge privacy and security concern, both individually and aggregate, related to user control, surveillance etc
14:30:26 <fjh> getUserMedia has dealt with similar issues
14:31:10 <fjh> q?
14:31:16 <fjh> ack fjh
14:31:39 <anssik> tobie: one can possibly reverse engineer the fusion process
14:32:40 <anssik> fjh: privacy issues around gUM are still being discussed in PING
14:33:00 <fjh> having a lower level API is more risky in that there is more detail than a higher level API that hides info
14:33:12 <fjh> better to match API to use case, hiding more information
14:33:18 <anssik> tobie: should note in the spec, the lower you go, the more security and privacy issues and unknowns
14:34:04 <anssik> q+ to ask about entropy
14:34:49 <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
14:34:55 <anssik> tobie: in geolocation API there's a highAccuracy boolean
14:34:59 <anssik> ... could have something like that
14:35:12 <fjh> note that fingerprinting is not the only issue - misuse of the API for various purposes can be even more concerning
14:35:32 <anssik> ... if the use case is about figuring out if the device is oriented in landscape or portrait, less precision needed
14:37:20 <fjh> tobie: saw at facebook higher bounce rate of apps asking for more permissions, so incentive to ask for fewer permissions
14:37:46 <anssik> ... could allow prompt-less access for less precision, require prompt for high precision
14:39:09 <anssik> fjh: fingerprinting, misuse of information, a lot of issues we cannot solve ourselves
14:39:18 <anssik> ... have to figure out the aggregation issue
14:39:36 <anssik> ... how much the head tracking will influence the work
14:39:48 <anssik> tobie: two big issues, 1) discovery
14:40:23 <anssik> ... no good real life example how to pick the right sensor to use
14:40:33 <anssik> ... 2) rel head tracking
14:40:51 <anssik> ... the speed and quantity or the actual data reading that you pass
14:41:02 <anssik> ... how that is exposed to the application-level code
14:41:02 <fjh> q+
14:41:17 <fjh> ack anssik
14:41:17 <Zakim> anssik, you wanted to ask about entropy
14:41:23 <anssik> ... head tracking is a good use case, has high latency and perf requirements
14:41:33 <fjh> ack fjh
14:41:47 <anssik> fjh: dave might be able to help us with the discovery problem
14:41:59 <fjh> s/dave/dsr
14:42:08 <anssik> tobie: finding a solution that works with the WoT folks
14:42:12 <anssik> ... makes sense
14:42:34 <anssik> dom: I'd not like to put that on our critical path
14:42:38 <fjh> +1
14:42:44 <fjh> research means it is hard
14:42:51 <anssik> ... since this is on the research phase
14:43:10 <anssik> ... sensors can be assumed to be always present
14:43:18 <anssik> ... thus no discovery needed
14:43:19 <anssik> q+
14:43:37 <fjh> August 2015 edition of the roadmap for mobile Web apps standards
14:43:53 <fjh> http://www.w3.org/2015/08/mobile-web-app-state/#Sensors_and_hardware_integration
14:43:56 <anssik> fjh: should publish even if the discovery is not addressed
14:45:07 <anssik> dom: people would be happy if we'd have a blueprint to fast track new sensors to the Web Platform
14:45:41 <anssik> ... we should be able to recast ambient light, proximity, device orientation
14:46:17 <anssik> fjh: would like to publish something soon
14:46:37 <anssik> tobie: my goal is still to look at the UCs and spec and have them published before TPAC
14:47:10 <anssik> ... similarly with the spec, a lot of this work is informing the API design
14:47:40 <fjh> q+ to note that we need CfC for FPWD of spec due to IPR reasons etc
14:48:04 <anssik> ... no concerns shipping the documents soon
14:49:57 <anssik> https://github.com/w3c/deviceorientation/issues/21
14:50:03 <anssik> Absolute-only DeviceOrientationEvents are bad for head tracking in VR
14:50:24 <fjh> ack anssik
14:51:43 <fjh> tobie: not a great design but attempt to solve problem, talking with Rich Tibbett
14:52:04 <anssik> another recent and related development is the iOS 9 Safari firing the deviceorientation event at 60 Hz
14:53:29 <fjh> ack fjh
14:53:29 <Zakim> fjh, you wanted to note that we need CfC for FPWD of spec due to IPR reasons etc
14:54:14 <anssik> fjh: I need a draft two week before publishing the FPWD
14:54:40 <anssik> dom: for CfC we do not need ready to publish doc, but ready to review, so ED is fine
14:54:59 <anssik> ... more important we don't delay stuff
14:55:25 <anssik> ... thus does not have to be the FPWD snapshot exactly
14:56:00 <anssik> tobie: what is the timeline if we want to be sure we published before TPAC
14:56:09 <anssik> fjh: pub on Tue or Thu
14:56:19 <anssik> ... latest 15th Oct for publishing
14:56:37 <anssik> team should have the pub ready FPWD by 8th Oct
14:56:50 <anssik> s/ team should have the pub ready FPWD by 8th Oct/...  team should have the pub ready FPWD by 8th Oct/
14:57:34 <anssik> ... should have two week CfC
14:57:46 <anssik> dom: week is enough for a CfC
14:59:18 <anssik> ... so draft must be available by 5th Oct
14:59:28 <anssik> ... to get to FPWD before TPAC
15:00:00 <anssik> tobie: can publish UCs and the API at the same time
15:00:41 <fjh> Summary - docs ready for call on 1 Oct, send CfC next week, 1 CfC, publish Oct 15
15:01:18 <fjh> plan to publish use cases as Note, need to be clear whether to publish as NOTE or WD (need to indicate Note track)
15:01:22 <fjh> Topic: Adjourn
15:01:25 <fjh> rrsagent, generate minutes
15:01:25 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/17-dap-minutes.html fjh
15:27:43 <fjh> rrsagent, generate minutes
15:27:43 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/17-dap-minutes.html fjh
17:08:34 <Zakim> Zakim has left #dap