[![W3C][1]][2] # Device APIs Working Group Teleconference ## 17 Sep 2015 See also: [IRC log][3] ## Attendees Present Anssi_Kostiainen, Dapeng_Liu, Dominique_Hazael-Massieux, Frederick_Hirsch, Tobie_Langel Regrets Chair Frederick_Hirsch Scribe anssik ## 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] * * * Date: 17 September 2015 Agenda: [https://lists.w3.org/Archives/Public/public-device- apis/2015Sep/0016.html][10] ### Welcome, scribe selection, agenda review, announcements Updated Wake Lock API WD published, auto update enabled [https://lists.w3.org/Archives/Public/public-device- apis/2015Sep/0008.html][11] ### Minutes approval Approve minutes from 3 Sept 2015 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][12] **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][12]** ### 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 [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 [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 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 issues ... question is what level of these sensors we expose ... and can we do it fast enough in JS fjh, you wanted to ask if this means aggregate sensors not ready for standardization fjh: things are often not good enough in the beginning, can be modularized at a later stage and standardized 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 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 anssik: take device orientation example, know there are issues with aggregation, so now exposing lower levels anssik: is that valid statement 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 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 this is hardest aspect, maybe will not resolve easily by talking anssik: maybe start with simpler first +1 tobie: need to think ahead 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 anssik, you wanted to note sensor fusion has its own privacy concerns sensors are a huge privacy and security concern, both individually and aggregate, related to user control, surveillance etc 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 having a lower level API is more risky in that there is more detail than a higher level API that hides info 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 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 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 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 ourselves ... 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 anssik, you wanted to ask about entropy tobie: head tracking is a good use case, has high latency and perf requirements 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 +1 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 August 2015 edition of the roadmap for mobile Web apps standards [http://www.w3.org/2015/08/mobile-web-app- state/#Sensors_and_hardware_integration][15] 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 [https://github.com/w3c/deviceorientation/issues/21][16] Absolute-only DeviceOrientationEvents are bad for head tracking in VR 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 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 Summary - docs ready for call on 1 Oct, send CfC next week, 1 CfC, publish Oct 15 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 log][18]) $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- apis/2015Sep/0016.html [11]: https://lists.w3.org/Archives/Public/public-device- apis/2015Sep/0008.html [12]: https://lists.w3.org/Archives/Public/public-device- apis/2015Sep/att-0005/minutes-2015-09-03.html [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- state/#Sensors_and_hardware_integration [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/