See also: IRC log
<trackbot> Meeting: Device and Sensors Working Group Teleconference
<trackbot> Date: 17 November 2016
Anssi regrets through new year
dom: only on critical path for Battery, also awaiting decision from Chromium whether to retain, also need to know about Microsoft implementation
<scribe> scribeNick: fjh
dom: Andrei has action to update based on TAG and github comments - major revision to address concerns about attribute on doc object
... may also change to be applicable not only to screens but also to system resources; discussed on last call
https://lists.w3.org/Archives/Public/public-device-apis/2016Nov/0009.html
fjh: that sounds like a useful increase of scope
dom: Geolocation working group needs to decide whether and when to start v2, likely plan is to wait for other sensor work first
... also during TPAC there was interest from the Web Bluetooth Community Group (and also possible Web NFC) to bring work to DAS
... to do so will require re-chartering, but with the new process that limits review to new deliverables
Approve minutes from 6 October 2016
https://lists.w3.org/Archives/Public/public-device-apis/2016Oct/att-0004/minutes-2016-10-06.html
proposed RESOLUTION: Minutes from 6 October 2016 are approved
RESOLUTION: Minutes from 6 October 2016 are approved
<tobie> https://github.com/w3c/sensors/milestone/2
tobie: triaged issues left on generic sensor API for level 1 release
... tagged and ordered
... many privacy and security related (about 1/2)
... some refactoring of API, talked with Intel implementers
... need to rethink core principles in spec
... leading to better design
... fingerprinting issue will require a decision
fjh: which core principles
tobie: for current sensors two requirements - 1 for small set of sensors for motion, set polling frequency, control data received
... for other sensors, only new requirement beyond existing specs, on change sensors, don’t get data until data changes despite initial request
... so have frequency based, or implementation dependent for others
... feedback for implementers to provide frequencies in both cases, but need to figure out how to present to developers
fjh: use long frequency for case where single value needed?
tobie: not so simple, don't get at requested frequency if OS considers no change in data
... can request a frequency but can get lower frequency, how often data changes is tied to how accurate sensor is
... makes sense
... e.g. light sensor that distinguishes light and day versus sensitive sensor
... not a problem if data provided whether or not data has changed, but becomes a problem for platforms where it is an issue
... so is this important, how to surface to developers
... need to clarify for developers the relationship of the API to the underlying platform
... extent of issue is not clear
... gaming experience is to run test to see if it works to know what to do
... not clear that there is a problem or not
... will work on modeling this week and next to make sense of it, then will go there
fjh: that sounds useful
tobie: we have questions about whether we have requirements that only work on some platforms
... quality of implementation versus hard requirement for frequency
fjh: graceful degradation
tobie: not sensible for virtual reality if person is vomiting
<tobie> https://github.com/w3c/sensors/issues/145
fjh: true
permissions
tobie: have 28 issues
... 6 issues need further research
... 11 privacy or security related issues
... rest are part of refactoring or small changes
... closing small issues while also working on bigger issues
https://github.com/w3c/sensors/issues/145
tobie: do we ask for permission before checking whether a sensor exists or not
... problem if have 15 sensors on device - finger printing issue
fjh: maybe ask higher level question, e.g. if need 5 sensors ask only one question
tobie: right
... different question - developer wants to use 5 sensors, ask for permisison to use gyroscope, vs asking if gyroscope is available
... risks include fingerprinting, knowing whether expensive device etc
... need to think this issue through
fjh: next steps beyond your work
tobie: would like input on github. Will have to make decisions, but we need more data to make good decisions.
... may want to give some implementer choice in spec - write as most useful to developers, add caveats for fingerprinting and security risks, allow implementers to make privacy/security aware choices
fjh: seems good approach, get implementer experience
tobie: also TAG review
... need usability
... getting close, have implementations
Next call 1 Dec, then 15 Dec
none