[![W3C][1]][2] # Device and Sensors Working Group Teleconference ## 09 Feb 2017 [Agenda][3] See also: [IRC log][4] ## Attendees Present Frederick_Hirsch, Dominique_Hazael-Massieux, Andrey_Logvinov, Tobie_Langel, Wanming_Lin, Anssi_Kostiainen, Mikhail_Pozdnyakov Regrets Chair Frederick_Hirsch Scribe dom, fjh ## Contents * [Topics][5] 1. [Welcome, scribe selection, agenda review, announcements][6] 2. [Minutes approval][7] 3. [Wake Lock API][8] 4. [Generic Sensor API][9] 5. [HTML Media Capture][10] 6. [Naming in Generic Sensors][11] 7. [Other Business][12] 8. [Adjourn][13] * [Summary of Action Items][14] * [Summary of Resolutions][15] * * * ### Welcome, scribe selection, agenda review, announcements ScribeNick: dom ### Minutes approval Approve minutes from 26 January 2017 [https://lists.w3.org/Archives/Public/public-device- apis/2017Jan/att-0012/minutes-2017-01-26.html][16] proposed RESOLUTION: Minutes from 26 January 2017 are approved **RESOLUTION: Minutes from 26 January 2017 are approved [https://lists.w3.org/Archives/Public/public-device- apis/2017Jan/att-0012/minutes-2017-01-26.html][16]** ### Wake Lock API close ACTION-784 Closed ACTION-784. Frederick: we've received new input from the TAG on the updated Wake Lock Use cases could be improved to include system lock use cases and comment on the RioRun scenario (eg describe scenarios in which developers might be tempted to use a wakelock but should not) We'd like the security and privacy implications to acknowledge the information leakage risk if wakelocks are denied when battery level is low. You might want to say you're happy with that leakage but it's worth acknowledging it. Specify how wakelocks interact with the user manually activating the hardware lock mechanism of the device [https://github.com/w3ctag/spec-reviews/issues/126][17] Frederick: Andrey already replied to one of the comments ... any thoughts about the other comments? Andrey: only received feedback very recently; useful feedback on the privacy section ... re manual lock, seems reasonable too ... will work on integrating those - no specific help needed at this point Frederick: we seem to be getting there, thanks Andrey for your continued work on this! Andrey: will fix the privacy/security section in the upcoming week ### Generic Sensor API Frederick: anything that needs discussion on this? Tobie: I set up a meeting with the folks of the company that had sent feedback and of which we talked about last time ... with a proposed addition of "bring your own buffer" API, probably only for motion sensors ... the best path forward is to combine all the mention sensors in a single spec ... subclass the generic sensor API with a MotionSensor interface ... that all the motion sensors would inherit from ... which would allow us to move the Generic Sensor stuff faster ... and focus on the MotionSensor separately, and as it matures, determine what might migrate back to Generic Sensor over time fjh, you wanted to ask about buffer overflow security concern Frederick: does this create any buffer overflow risk? Tobie: I haven't thought about this, but I don't see how that would be a concern at our layer in the platform, but I could be wrong ... Ambient Light & Proximity are very different from the Motion Sensors Anssi: re Motion Sensors spec - would DeviceOrientation as fusion of Magnetometer be part of this? ... both low level and fusion sensors Tobie: absolutely ... the point is to have the stuff in the same place to reduce boilerplate, but also use it as an opportunity to better explain the platform to developers ... also might help avoid having implementors implement only a subset of the motion sensors Mikhail: a couple of questions ... would it mean that there would be some common APIs uniting all the motion sensors together? Tobie: to move forward more quickly, I'd like to avoid the trouble we've had with the different reporting mode ... a MotionSensor subclass would be very useful ... re high-level vs low-level motion sensors, whether they should inherit from the same subclass, I'm not sure yet ... will be able to know once I dig into it Mikhail: some platforms have different reporting modes among motion sensors, so that's a potential concern tobie: OK, so we will have to deal with this; but at least we'll know what outcome we want, and it will scope down the conversation some what ... (I hope!) Mikhail: the dedicated motion sensor spec - any thought about how the common interface will differ from the Generic Sensor API? Tobie: not at this time; it would inherit from Generic Sensor ... it might be that the "bring your own buffer" thing is specific to motion sensor ... can't imagine it be useful e.g. for geolocation Mikhail: so a more sophisticated API for buffering tobie: exactly; we might backport it to generic sensor later if we find that's more broadly useful ... it will help with moving forward with the work Frederick: can you send a note to the list with your plans? Tobie: I can do that Gyroscope pull request to sync up with Generic Sensor API has completed update to align with Generic Sensor API ### HTML Media Capture VideoFacingModeEnum as the capture attribute's value [https://github.com/w3c/html-media-capture/issues/4][18] Frederick: there has been a suggestion to add the VideoFacingModeEnum to our capture attribute Anssi: it was initially in upstream HTML ... the idea is to provide more finegrained hint - right now it's a boolean to switch from file picker to camera ... this would allow to pick a specific camera ... I've been awaiting implementors interest before proceeding dom: how would it apply to audio picker? dom: can be used for audio, video, still images, so not sure how this would work for audio or other media types anssi: it would only work with some media types dom: enum might issue if want to select a specific microphone dom: might be ok if the enum only applies to video; not sure if there is a need to pick a specific microphone for this API upstream issue: [https://github.com/whatwg/html/issues/1102][19] frederick: so overall low priority, waiting for signs of interest ### Naming in Generic Sensors Tobie: on naming - since we moved the connection to the underlying sensor to the sensor instance, we needed a new state ... the object is initially not connected to a sensors (which is different from not listening) ... we had a bunch of conversations on the state machine and ended up with being happy with "activation" as a concept ... first "unactivated", then "activating", "activated", "deactivated", "errored" ... would everyone be happy with moving to that scheme? [https://github.com/w3c/sensors/issues/160][20] [https://github.com/w3c/sensors/issues/160#issuecomment-275716147][21] ScribeNick: fjh tobie: created diagram ... inconsistent naming ... should we rename start stop method to match activate approach, which seems to have support ... looking for input from Rick ... so we match what Javascript developers like ... so may delay this decision since he is on leave now, but please comment on the issue if you have opinions ... would like consistency in state names, and short method names, not sure that this is too important Mikhail: connected sounds like physical, so a bit confusing, so happier with activated, not misleading ### Other Business tobie: added to wakelock TAG issue list, agree with Andrey, not wakelock issue but generic sensor API ScribeNick: dom Anssi: I closed a bunch of issues that had been settled (as seen in the weekly digest) [http://www.w3.org/mid/E1cb97g-0007oQ-Un@uranus.w3.org][22] Anssi: from a sensor perspective, only ALS needs to be rebased to updated Generic Sensor ### Adjourn Thanks ## Summary of Action Items ## Summary of Resolutions 1. [Minutes from 26 January 2017 are approved https://lists.w3.org/Archives/Public/public-device- apis/2017Jan/att-0012/minutes-2017-01-26.html][23] [End of minutes] * * * Minutes formatted by David Booth's [scribe.perl][24] version 1.144 ([CVS log][25]) $Date: 2015/11/17 08:39:34 $ [1]: https://www.w3.org/Icons/w3c_home [2]: http://www.w3.org/ [3]: https://lists.w3.org/Archives/Public/public-device- apis/2017Feb/0000.html [4]: http://www.w3.org/2017/02/09-dap-irc [5]: #agenda [6]: #item01 [7]: #item02 [8]: #item03 [9]: #item04 [10]: #item05 [11]: #item06 [12]: #item07 [13]: #item08 [14]: #ActionSummary [15]: #ResolutionSummary [16]: https://lists.w3.org/Archives/Public/public-device- apis/2017Jan/att-0012/minutes-2017-01-26.html [17]: https://github.com/w3ctag/spec-reviews/issues/126 [18]: https://github.com/w3c/html-media-capture/issues/4 [19]: https://github.com/whatwg/html/issues/1102 [20]: https://github.com/w3c/sensors/issues/160 [21]: https://github.com/w3c/sensors/issues/160#issuecomment-275716147 [22]: http://www.w3.org/mid/E1cb97g-0007oQ-Un@uranus.w3.org [23]: #resolution01 [24]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [25]: http://dev.w3.org/cvsweb/2002/scribe/