<trackbot> Meeting: Device and Sensors Working Group Teleconference

<trackbot> Date: 17 November 2016

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Nov/0018.html

<scribe> Chair: Frederick_Hirsch

Welcome, scribe selection, agenda review, announcements

Anssi regrets through new year

Battery

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

Wakelock

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

fjh: that sounds like a useful increase of scope

Coordination activities

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

Minutes Approval

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

Generic Sensor

<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

Generic Sensor Permission Issue 145

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

Upcoming calls

Next call 1 Dec, then 15 Dec

Other Business

none

Adjourn

S/Chair: FJH/Chair: Frederick_Hirsch

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/including/and also possible Web/
Succeeded: s/limites/limits/
Succeeded: s/need/need further/
Succeeded: s/chanbges/changes/
Succeeded: s/,,,//
Succeeded: s/ may/… may/
Succeeded: s/trackbot, start telecon//
Succeeded: s/also to system resources/also to system resources; discussed on last call/
Succeeded: s/ use long frequency/ use long frequency for case where single value needed?/
Found ScribeNick: fjh
Inferring Scribes: fjh
Present: Frederick_Hirsch Tobie_Langel Wanming_Lin Dominique_Hazael-Massieux
Regrets: Anssi_Kostiainen
Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Nov/0018.html
Found Date: 17 Nov 2016
Guessing minutes URL: http://www.w3.org/2016/11/17-dap-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.