13:52:41 RRSAgent has joined #dap 13:52:41 logging to http://www.w3.org/2017/05/18-dap-irc 13:52:43 RRSAgent, make logs world 13:52:43 Zakim has joined #dap 13:52:45 Zakim, this will be DAP 13:52:45 ok, trackbot 13:52:46 Meeting: Device and Sensors Working Group Teleconference 13:52:46 Date: 18 May 2017 13:56:07 Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017May/0022.html 13:56:11 fjh has changed the topic to: das https://lists.w3.org/Archives/Public/public-device-apis/2017May/0022.html 13:56:36 Chair: Frederick_Hirsch 13:56:50 Present+ Frederick_Hirsch 13:57:04 Topic: Welcome, scribe selection, agenda review, announcements 13:57:31 shalamov has joined #dap 13:58:43 github digest (16 May) https://lists.w3.org/Archives/Public/public-device-apis/2017May/0019.html 13:59:02 github digest (9 may) https://lists.w3.org/Archives/Public/public-device-apis/2017May/0008.html 13:59:03 mail list spam removal? 13:59:04 Orientation Sensor First Public Working Draft and Motion Sensors Explainer W3C Note were published 13:59:05 https://lists.w3.org/Archives/Public/public-device-apis/2017May/0012.html 13:59:06 HTML Media Capture CR published 4 May, https://www.w3.org/TR/html-media-capture/ 14:01:18 Present+ Riju_Bhaumik 14:01:38 Present+ 14:01:39 Present+ Mikhail_Pozdnyakov 14:01:51 Present+ Alexander_Shalamov 14:01:58 Present+ Anssi_Kostiainen 14:02:25 ScribeNick: dom 14:04:34 Topic: Minutes approval 14:04:35 Topic: Minutes approval 14:04:44 Approve minutes from 4 May 2017 14:04:45 https://lists.w3.org/Archives/Public/public-device-apis/2017May/att-0004/minutes-2017-05-04.html 14:04:46 proposed RESOLUTION: Minutes from 4 May 2017 are approved 14:04:47 RESOLUTION: Minutes from 4 May 2017 are approved https://lists.w3.org/Archives/Public/public-device-apis/2017May/att-0004/minutes-2017-05-04.html 14:04:53 Topic: HTML Media Capture 14:04:59 Chromium implementation https://lists.w3.org/Archives/Public/public-device-apis/2017May/0011.html 14:05:07 Test results 14:05:07 http://w3c.github.io/test-results/html-media-capture/20170428.html 14:05:15 FJH: anything needed on this? 14:05:16 Analysis of failures 14:05:38 anssik: my assessment is that the identified failures are false negatives 14:05:43 capture_audio-manual.html 14:05:47 capture_audio_cancel-manual.html 14:05:53 audio capture via not implemented, not a normative spec requirement since accept attribute defined in HTML spec 14:06:10 ... the first 2 failures (referenced above) are due to the fact that audio capture is not implemented - but that's not a normative requirement 14:06:16 ... I think the test cases can be dropped 14:06:20 capture_fallback_file_upload-manual.html 14:06:25 iOS unable to upload files other than media types, unable to test 14:06:51 ... the 3rd failure on ios is specific to the lack of support of upload on that platform 14:07:19 s/of upload/non-media upload/ 14:07:28 ... this means we have fairly widespread adoption of that feature 14:07:38 FJH: that means once the test results are updated we can exit CR 14:07:59 "This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 6 July 2017" 14:08:29 https://github.com/w3c/html-media-capture/issues/12 14:08:31 anssi: there is one thing about how we reflect enum types in IDL attributes 14:08:56 ... but riju doesn't think that's a blocker; we will investigate this 14:09:34 riju: the support for enum for attribute reflection was removed; implementations are using DOMString 14:10:08 Anssi: one approach would be re-import the definition of enum into the spec 14:10:16 ... or we could change the IDL to DOMString 14:10:22 ... we will investigate and report back 14:12:47 Dom: might be worth bringing change soon so that we can stick with the current PR entrance date of July 6 14:12:53 dom: publish CR before 6 June would not need to change PR schedule 14:13:51 Topic: Magnetometer 14:14:05 I provided a synthesis of the discussion in: 14:14:05 https://github.com/w3c/magnetometer/issues/16#issuecomment-302066759 14:15:22 anssik: there are use cases both calibrated & uncalibrated magnetometer 14:15:54 Editor's conclusion: There are key use cases for both calibrated magnetometer and uncalibrated magnetometer, as well as various native apps that make use of both of these capabilities. This suggests we should consider uncalibrated magnetometer of similar importance to the existing (calibrated) magnetometer. 14:16:54 fjh: some of the concerns are around usability / understanding from developers 14:17:11 ... we need to straighten up how this gets presented 14:18:24 anssik: a separate constructor (rather than a parameters-based approach) was the one that seemed to gain consensus 14:18:30 ... remains to find the right naming 14:19:18 Editor's conclusion: Consensus on the API design emerged, exact naming of the interfaces remains an issue. In the interest of focusing the energy of the participants on more burning issues than naming things, the editor merged the PR inviting further feedback regarding naming of the interfaces to be provided in issue #16. 14:19:47 fjh: a process issue around how pull requests get merged before consensus is clear 14:19:54 ... seems to have happened a couple of times now 14:20:38 anssik: the pull request just landed a proposal in the editors draft, which seems OK as editors draft aren't expected to reflect consensus all the time 14:21:42 ... the other case was around use cases for ambient light which I landed as non-normative content 14:21:47 ... I didn't see that as controversial 14:22:03 FJH: it's probably ok; we should hear from tobie if he feels otherwise 14:23:51 Anssik: this pull request that I landed was open 7 months ago, so it's good to get preliminary closure on this (although naming isn't done yet) 14:23:53 Topic: Ambient Lights 14:24:18 FJH: apparently we're not auto-publishing updates to that one? 14:24:44 anssik: bikeshed + echidna is still not completely solved 14:25:00 https://github.com/w3c/sensors/issues/74 14:25:49 dom: can use bikeshed command line to publish WD 14:26:54 anssik: I can do the "manual" thing 14:26:56 dom: thought the integration was working, that Tobie had something working, need to find out from Tobie what is not working or status 14:27:04 dom: not clear what's blocking the automated approach 14:27:16 anssik: I'll publish an updated WD of ALS 14:27:30 Security and Privacy considerations for ALS 14:27:30 https://github.com/w3c/ambient-light/issues/13#issuecomment-302393458 14:28:13 Anssi: Alex can show that we can mitigate the threats in the article 14:30:32 Alex: in normal conditions, rounding to 50 lumen would enough to mitigate this risk 14:30:36 alex: hard to reproduce vulnerability without creating unrealistic conditions of screen brightness, flashing, wake lock etc 14:30:37 ... (in our test setup) 14:31:39 anssik: we can leave the exact rounding to implementors 14:32:05 q+ 14:32:25 ack dom 14:33:23 dom: are there more threats related to light? do we have a general theory? 14:33:51 dom: can we model concerns, so we can mitigate more in advance 14:34:20 alex: I tried formalizing the threats, but there are too many variables in the real world 14:34:28 alex: tried to model considering reflectivity of surfaces etc but too hard to do for variety of surfaces 14:34:31 ... (e.g. reflection from real wordl objects) 14:34:38 ... it's not a linear problem 14:34:49 ... so it's very difficult to model the attack vector 14:35:33 fjh: it feels already good that we can solve that already hard-to-exploit case 14:36:16 anssik: so we should update the ALS spec privacy & security section with rounding - would it be normative? 14:36:49 alex: this research is just a first step to initiate a conversation with Google security team, & Lukasz 14:37:01 ... I think we need to wait for that discussion to settle before changing the spec 14:37:33 anssik: that makes sense, but I was wondering if we should be put a normative minimum rounding threshold 14:38:10 Topic: Generic Sensor API 14:38:33 Rewrite Abstract Operations 14:38:33 https://github.com/w3c/sensors/pull/197 14:38:39 anssik: I've identifed 3 issues that can be worth an overview 14:39:26 Mikhail: we were advised by Chrome engineers to decouple change notification from sensors & requestAnimationFrame 14:39:51 ... coupling in the real world creates disadvantages as it reduced the FPS 14:40:10 ... this is important as Tobie was planning to integrate the concept of rAF in the specs 14:41:15 ... the pull request brings consistency between implementation & spec 14:41:27 ... I've restructed the abstract operations so that they match with the real world 14:41:33 ... and dropped unneeded operations 14:41:39 ... it also fixes some pending issues 14:42:28 ... incl the fact that sensor objects can influence each other (where two sensors with different options influence each other) 14:42:38 q+ 14:42:43 ack dom 14:43:33 mikhail: I tried to make the execution flow more consistent by setting up a common structure for the algo 14:44:14 dom: aliigning with implementations can be good or bad depending on the circumstances, is this only for chrome or is it general enough 14:44:27 mikhail: it's general 14:44:41 anssik: yes, it's implementation agnostic 14:46:34 Add Input Elements to Mitigation Strategies 14:46:34 https://github.com/w3c/sensors/pull/190 14:47:14 https://github.com/w3c/sensors/issues/189 14:48:47 alex: the proposal is to stop all sensors that can interact with touch - i.e. currently motion sensors and ambient light 14:49:19 s/with touch/with touch when an element has focus/ 14:49:38 anssik: this would mean stopping sensors when using a third-party payment system in a game for instance 14:49:38 are there any unexpected consequences? 14:49:51 ... that sounds reasonable 14:50:03 alex: another approach is to reduce the polling frequency in these conditions 14:50:24 ... the point of this issue is that we can use focus state to enforce different security policies that affect sensors 14:50:46 anssik: I think this is breaking new ground - we haven't found other features in the platform using this for security/privacy 14:51:01 ... alex can help push this forward if tobie can't 14:51:07 ... this feels pretty important to have in the spec 14:51:13 would be good to note this in the spec 14:51:44 Take into account user gestures as an input for security policy enforcement #196 14:51:44 https://github.com/w3c/sensors/issues/196 14:52:43 good idea to use user actions 14:52:54 we discussed in privacy discussions earlier 14:52:55 Alex: the idea is to take into account trusted events for sensors privacy & security 14:54:03 FJH: how would this work at the generic sensor level? 14:54:21 dom: I assume you would only get access to a sensor object out of a trusted event callback 14:54:48 Topic: Battery Status API 14:54:56 https://github.com/w3c/battery/issues/10 14:54:56 https://github.com/w3c/battery/pull/11 14:55:03 anssik: the spec was updated 14:55:19 riju: implementation is done, missing just test cases 14:56:10 anssik: question is what next step - do we need an updated CR? 14:56:12 fjh: +1 14:56:49 ... I'll do a CfC once the document is ready 14:57:30 ACTION: Anssi to prepare a new CR draft for battery 14:57:34 Created ACTION-799 - Prepare a new cr draft for battery [on Anssi Kostiainen - due 2017-05-25]. 14:58:18 dom: impact on Firefox? 14:59:03 https://github.com/w3c/battery/issues/5#issuecomment-257617533 15:01:06 RRSAgent, draft minutes 15:01:06 I have made the request to generate http://www.w3.org/2017/05/18-dap-minutes.html dom 15:01:17 Topic: Other Business 15:01:45 dom: Vibration API will not be shipping in Safari 15:02:06 anssik: doesn’t affect anything, dead code removal 15:02:25 anssik: looked into hosting but Newcastle might offer more space 15:02:49 fjh: thanks, now we need to consider whether we have resources to put together a workshop 15:03:00 fjh: thanks everyone 15:03:04 Topic: Adjourn 15:03:07 rrsagent, generate minutes 15:03:07 I have made the request to generate http://www.w3.org/2017/05/18-dap-minutes.html fjh 16:40:06 shalamov has joined #dap 16:51:17 s/we discussed in privacy discussions earlier/we discussed such an approach in privacy discussions earlier/ 16:51:55 s/fjh: thanks,/thanks,/ 16:52:09 s/fjh: thanks everyone/thanks everyone/ 16:52:14 rrsagent, generate minutes 16:52:14 I have made the request to generate http://www.w3.org/2017/05/18-dap-minutes.html fjh 17:04:32 Zakim has left #dap 17:48:21 zkis has joined #dap 18:22:02 zkis has joined #dap