See also: IRC log
<trackbot> Date: 17 September 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0016.html
<fjh> Updated Wake Lock API WD published, auto update enabled https://lists.w3.org/Archives/Public/public-device-apis/2015Sep/0008.html
<fjh> Approve minutes from 3 Sept 2015
<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
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
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
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
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 issues
... 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 standardization
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 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
<Zakim> 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
<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-state/#Sensors_and_hardware_integration
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
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)