05:00:55 RRSAgent has joined #dap 05:00:55 logging to https://www.w3.org/2021/04/08-dap-irc 05:00:58 RRSAgent, make logs Public 05:00:59 please title this meeting ("meeting: ..."), anssik 05:00:59 Meeting: Devices and Sensors WG - 2021 Q2 virtual meeting - Sensors 05:01:05 Chair: Anssi, Reilly 05:01:15 Agenda: https://www.w3.org/events/meetings/25801de1-caf6-434c-b20c-6ed1819cbe90 05:01:16 arno_ has joined #dap 05:01:27 Present+ Anssi_Kostiainen 05:01:29 Present+ Reilly_Grant 05:01:35 Present+ Kenneth_Christiansen 05:01:41 Present+ Lars_Knudsen 05:01:47 Present+ Marcos_Caceres 05:01:57 Present+ Raphael_Kubo_da_Costa 05:02:06 Present+ Arnaud_Mandy 05:02:14 Present+ Vincent_Scheib 05:02:22 RRSAgent, draft minutes 05:02:22 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 05:04:13 wanming has joined #dap 05:05:57 scribeNick: reilyg 05:06:00 scribeNick: reillyg 05:06:38 Scribe: Reilly 05:06:45 RRSAgent, draft minutes 05:06:45 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 05:06:56 kenchris has joined #dap 05:07:06 Present+ Kenneth_Christiansen 05:07:06 Present+ Will_Morgan 05:08:05 Topic: Accelerometer 05:08:54 Anssi: Raphael will update us on what is happening in Gravity Sensor-land. 05:09:31 Raphael: In terms of specifications there hasn't been much going on but from an implementation perspective the Gravity Sensor is going to be shipping in Chrome 91. 05:10:02 Raphael: We didn't need to make any specification changes in order to ship but we did write an explainer. 05:10:15 -> https://github.com/arskama/GravitySensor/blob/main/explainer.md GravitySensor explainer 05:10:26 RRSAgent, draft minutes 05:10:26 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 05:10:42 ... The use cases section of the explainer can be merged back into the main spec. 05:10:53 ... WPT tests were already present. 05:11:25 Kenneth: It makes sense for Gravity Sensor to be part of the Accelerometer specification because it is a derived sensor from the accelerometer. 05:11:43 scribeNick: reillyg 05:11:48 Raphael: This work is a testament to how well the Generic Sensors framework works. 05:12:18 Anssi: I'm happy to see a well-known customer ask for this feature. 05:12:21 Scribe: reillyg 05:12:24 ... This was a request from Unity. 05:12:38 RRSAgent, draft minutes 05:12:38 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html marcosc 05:12:48 ... It would be useful now to try to get reactions from other browsers. 05:13:17 ... Have there been formal signals from other browsers? 05:13:22 Raphael: I don't think so. 05:13:40 ... I think it would be useful to complete the S&P review work discussed yesterday before reaching out again. 05:14:01 Anssi: What's interesting about the Gravity Sensor is that this is a new surface. 05:14:15 ... You could polyfill it using the existing API but it wouldn't be very efficient. 05:14:29 Kenneth: It would drain your battery. 05:15:08 ... You can do a low-pass filter, or subtract the linear accelerometer from the accelerometer. That is a lot of processing per event. 05:15:25 Anssi: Are there any general thoughts? 05:16:42 proposed ACTION: Arno to Merge GravitySensor explainer back to the master explainer and/or spec 05:17:01 proposed ACTION: Arno to Merge GravitySensor explainer and its use cases back to the master explainer and/or spec 05:17:10 ACTION: Arno to Merge GravitySensor explainer and its use cases back to the master explainer and/or spec 05:17:27 -> https://github.com/w3c/accelerometer/pull/60 Permissions Policy Integration 05:17:54 Anssi: Next topic, Permissions Policy integration. 05:18:16 Scribe: marcosc 05:19:17 anssik: Mike Smith proposed to add Permission Policy policy specifically to accelerometer. 05:19:52 anssik: there is some boilerplate text for how specs do this. Because this spec is new, it needs to be done differently. I made some comments to that regard. 05:19:58 The current integration is through https://w3c.github.io/sensors/#check-sensor-policy-controlled-features that is called into from https://w3c.github.io/accelerometer/#construct-an-accelerometer-object (and other sensor APIs that inherit from Sensor). 05:19:58 05:19:58 The feature strings are defined in https://w3c.github.io/permissions/#permission-registry 05:20:30 It seems if we'd make the following default allowlist normative in the Generic Sensor API (from https://w3c.github.io/sensors/#permissions-policy-api): 05:20:31 The features' default allowlist is ["self"]. 05:20:46 anssik: I proposed that if we want to make permission policy integration part of the Generic Sensor API, we would need to just add the "allow list" 05:20:54 anssik: as "self" 05:21:11 anssik: reillyg, what do you think... should we make it generic? 05:22:17 reillyg: I'm trying to understand Mike's request... we have the default allow list in Generic sensor, and we have the "check if allowed to use" in the Generic spec, and we have it in the other specs too. Maybe we need more non-normative text explaining how the policy integration works? 05:22:27 reillyg: but it seems "technically" all the right bits are there 05:23:02 anssik: the problem might be that it was currently non-normative. So I was proposing to make the permission policy stuff to be normative. 05:23:08 q+ 05:23:55 reillyg: it seems like a bug in the spec that the permission and the permission policy was in the extensibility section and not in the main body of the spec 05:24:23 ack marcosc 05:25:11 reillyg: I think what we've done here is defined the permissions stuff both normatively and non-normatively, so we should make everything normative. 05:25:52 anssik: Yes, that would give us more control over things. But in general, we should be strict about the permission policy stuff 05:26:05 q? 05:27:00 Extensibility section notes: "Note: This section and its subsections provide guidance to extension specification authors using normative language. From implementers' point of view, this section and its subsections are considered non-normative." 05:27:26 https://w3c.github.io/sensors/#extensibility 05:27:33 reillyg: the scribe made a mistake , for permission policy, it's currently non-normative - so we need to fix that to be normative. 05:28:42 anssik: the architecture is somewhat unique, with base classes etc... so it makes things a little bit confusing. But it's all fixable. 05:29:41 reillyg: the Generic sensor spec defines the "default default allow list", but other specs might be able to override that allow list. 05:30:19 marcosc: would it be a good a idea to allow that? 05:30:42 reillyg: maybe not. Maybe we should lock it down until someone needs to override it 05:31:18 anssik: reillyg, what is your resolution... is it to make allow list "self" for Generic Sensor API? 05:31:25 proposed RESOLUTION: Make default allowlist "self" for the Generic Sensor API 05:33:08 proposed RESOLUTION: Make default allowlist "self" for the Generic Sensor API, include non-normative language in concrete sensor specs to make it clear the feature is Permissions Policy controlled feature 05:33:10 reillyg: The problem with generic Sensor API is that it might be hard for developers to know what's going on with regards to permissions... so we could add a non-normative note in each spec to make it clear. 05:33:34 proposed RESOLUTION: Make default allowlist "self" for the Generic Sensor API, include non-normative language in concrete sensor specs to make it clear those features are Permissions Policy controlled features 05:33:53 +1 05:33:57 +1 05:34:07 RESOLUTION: Make default allowlist "self" for the Generic Sensor API, include non-normative language in concrete sensor specs to make it clear those features are Permissions Policy controlled features 05:34:26 anssik: next topic, Proximity 05:34:32 TOPIC: Proximity 05:35:05 anssik: I want to bring in feature request/clarification from an ECMA for embedded systems 05:35:07 -> https://www.ecma-international.org/technical-committees/tc53/ TC53 ECMAScript modules for embedded systems 05:35:25 s/an ECMA for embedded/an ECMA-53 group for embedded 05:35:30 -> https://github.com/w3c/proximity/issues/44 Behavior of distance attribute when sensor cannot provide distance measurements? (issue #44) 05:36:59 anssik: the way the spec is currently defined is incompatible with the stuff that TC53 is doing. The spec is a bit confused around the behavior of distance attribute when sensor cannot provide distance measurements. 05:37:15 https://github.com/w3c/proximity/issues/44#issuecomment-803227496 05:37:49 anssik: And proposes that the behavior should return `undefined` 05:38:01 s/And/Andy 05:38:05 q+ 05:38:51 -> https://w3c.github.io/proximity/#proximity-sensor-distance The distance attribute 05:39:19 marcosc: it seems strange to return `undefined` 05:39:25 q? 05:39:56 scribeNick: scheib 05:39:58 scribenick: scheib 05:40:18 reillyg: 3 states 05:40:42 reillyg: No capability 05:40:47 reillyg: No object detected 05:41:09 reillyg: TC53 proposing using undefined 05:41:22 marcosc: undefined is concerning 05:41:27 marcosc: Geolocation uses: 05:41:28 Example from Geo: "Initialize coord's heading attribute in degrees, or null implementation cannot provide heading information. If the hosting device is stationary (i.e. the value of the speed attribute is 0), then initialize the heading to NaN." 05:42:30 reillyg: NaN used for heading when an object is not moving, it is mathematically undefined. 05:42:40 reillyg: many specs use 'null' for can not provide. 05:42:52 reillyg: need another number for 'distance undetermined' 05:43:06 anssik: Or, infinity 05:43:37 anssik: But, TC53 is concerned about these values. 05:44:05 reillyg: From issue comment, "desire to avoid special values that still satisfy the condition typeof value === 'number', out of concern that anything that is a number might be interpreted as a valid distance reading. This lead our discussion away from using positive infinity as a special signal value." 05:44:25 anssik: This is a recommendation from TC53, but we should work to be consistent with web platform APIs 05:44:59 reillyg: What about 'undefined', false, or number? 05:45:48 q+ 05:46:19 reillyg: Want to satisfy javascript 'truthiness', e.g. an object at a distance or just present 05:47:32 q+ to note there should perhaps be a general best practice for this API design consideration to ensure consistency on the web platform, is there a TAG position? 05:47:38 ack marcosc 05:47:39 reillyg: For 'falsy' there are object not present or capability not present 05:48:10 q+ 05:48:23 q? 05:48:32 reillyg: Wait -- if no capability, should sensor creation fail? 05:48:38 ack anssik 05:48:38 anssik, you wanted to note there should perhaps be a general best practice for this API design consideration to ensure consistency on the web platform, is there a TAG position? 05:49:01 anssik: Issue seems larger than just this specific API. Should have a general best practice for this situation for consistency on web APIs. 05:49:22 kenchris: File an issue for TAG 05:50:02 https://w3ctag.github.io/design-principles/ 05:50:24 q? 05:50:26 marcosc: Ping Domenic Denicola 05:51:48 proposed ACTION: Anssi to ping Domenic to seek guidance on API design consideration for distance attribute 05:51:51 reillyg: One more proposal for behavior: 05:52:10 ... null for no capability or no object 05:52:30 ... check 'near' attribute to distinguish 05:52:33 proposed ACTION: Anssi to ping Domenic to seek guidance on API design consideration for distance attribute considering consistency with the web platform 05:52:57 s/null for/null 'distance' for/ 05:53:46 https://github.com/w3c/proximity/issues/44#issuecomment-815469205 05:54:40 marcosc: [called for Domenic's help on issue] 05:55:50 larsgk: Browser implementers unlikely to have devices with proximity only with no distance measurement. 05:57:02 s/Browser implementers/Web app developers/ 05:58:20 larsgk: Perhaps a set of states instead of 'near' 'distance', similar to Geolocation. 05:58:24 q+ 05:58:50 anssik: e.g. 'near', 'not so near', 'far'? 05:59:51 ... would allow a state 'we don't know', e.g. in the TC39 situation 06:00:14 q? 06:00:20 ack larsgk 06:00:25 ack reillyg 06:00:30 reillyg: No implementation so far. 06:00:51 reillyg: The 'near' attribute not well defined, because developer can't communicate what 'near' means. 06:01:06 ... constructor could take parameter for what is considered near 06:01:28 ... For sensors that can only detect a boolean presence, the parameter would be ignored 06:01:49 ... Sensors with range proximity could use the parameter as the threshold for the results. 06:02:14 ... Might make this parameter mandatory to avoid web-app developers not planning for the various sensor types. 06:03:04 reillyg: Either a single threshold. Or a 'rising' and 'falling' threshold for which range the object is considered present 06:03:39 ... only applications that need measured distance would use it 06:04:13 anssik: This would be a simple javascript adapter 06:05:14 anssik: Fundamental considerations are raised by this topic. 06:07:11 reillyg: Lack of interested web platform clients limits our understanding of requirements. 06:07:22 https://github.com/w3c/proximity/issues/44 06:07:58 -> https://github.com/w3c/screen-wake-lock/issues/300 "near" and "user presence state" interaction 06:08:35 anssik: Noting that recent devices have more sophisticated detection sensors. 06:08:57 ... e.g. knowing that the object in proximity appears to be human 06:09:42 RRSAgent, draft minutes 06:09:42 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 06:22:42 present+ Andy_Carle 06:24:38 reillyg: [summarized previous discussion] 06:24:48 RRSAgent, draft minutes 06:24:48 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 06:25:04 Andy: Was discussed, but not clear what to do with 'distance' 06:25:37 reillyg: Dictionaries can return undefined in web, but attributes don't typically do this 06:25:57 Andy: Trying to work with 'dictionaries in' 'dictionaries out' 06:26:29 reillyg: Another option to have return type be a union, returning number or bool, etc. 06:27:26 reillyg: And, highlighting larsgk concern of libraries attempting to work in both situations. Hence our possible near state being 3 enum states. 06:27:38 q? 06:29:07 Andy: Common scenarios likely to match that proposal. E.g. applications that simply want an interrupt situation. 06:29:45 ... e.g. configure sensor with a value and have a pin value be triggered by that. 06:30:03 reillyg: Current spec supports both polling and event API usecases. 06:30:45 ... guessing that DOM / event style events not adopted in TC53 06:31:23 Andy: Planning to do a first pass on sensor types as generic as possible 06:32:07 ... e.g. temp sensor only has a temp sensor and it can be sampled. But no thresholds or interrupts, or unit conversions. 06:32:41 Andy: Assumes the developer knows the exact sensor under the API 06:32:56 ... opposite of web platform approach which is abstracting the sensors. 06:33:41 ... Have a document type which allows injecting callbacks for particular sensors. 06:34:14 ... As more manufactures get involved with ECMA we hope to abstract out of specific parts. 06:35:46 anssik: Need to wrap discussion for time. Let's continue discussion on issue. (others agree) 06:35:59 ... Pleased to see TC53 engaging on this API. 06:36:12 q 06:36:39 anssik: Spec should be consistent with web platform standards 06:37:25 scheib: How soon does TC53 want this? 06:37:36 Andy: First version of spec is frozen and being reviewed 06:37:54 ... v1 working to go through ECMA now 06:38:02 ... improvement planned though mid-summer 06:39:34 proposed RESOLUTION: Continue work with TC53 Committee to learn from their Proximity sensor implementation experience and refine the spec accordingly 06:40:13 RESOLUTION: Continue work with TC53 Committee to learn from their Proximity sensor implementation experience and refine the spec accordingly 06:40:25 Topic: Ambient Light Sensor 06:41:11 -> https://github.com/w3c/ambient-light/issues/64#issuecomment-738213220 MVP requirements for ALS and Screen Brightness 06:41:14 Subtopic: Screen Brightness API 06:41:39 RRSAgent, draft minutes 06:41:39 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 06:42:28 Will: Company desires to understand if the person using hardware is a human, not a deep fake etc. 06:42:40 Using light to determine if the person is real. 06:42:49 Flashing different colors. 06:43:02 Predicting first if operation will be successful. 06:43:19 Being a strong light it may not be, and must request user to move areas 06:43:30 Or, may need to adjust intensity of light flashes. 06:44:06 Ambient light helps with detection 06:44:19 Screen brightness can help adjust flash levels 06:44:33 Some have proposed CSS media queries 06:44:45 Have also tried to read exif data from media stream. 06:44:48 q+ 06:44:58 Some implementations don't allow reading that data without setting a value. 06:45:13 Ideally would read light conditions before requesting webcam. 06:45:24 Reduces privacy exposure by only asking for webcam when needed. 06:46:16 q? 06:46:33 ack marcosc 06:46:43 q+ 06:46:51 willmorgan_ has joined #dap 06:47:05 marcosc: Ambient sensor has had several privacy concerns with the API. 06:47:25 e.g. detecting which TV show is currently displayed in area. 06:48:01 The purpose of the application described as a use-case is also a significant privacy concern in that it might help identify people. 06:48:38 There is a presupposition that this is the method needed to solve the use case. 06:49:21 Web authentication, and secure payment APIs have similarities. 06:50:25 So -- would like to life conversation to explore how we can solve the problem generally. 06:50:58 Will: Desire to solve this issue without using particular sensors/solutions from specific companies. 06:52:02 Would like to understand the privacy concerns more. 06:52:45 marcosc: Firefox removed implementation due to privacy concerns. 06:53:19 reillyg: Noting that ambient light sensor isn't being used for identification. Only predicting success 06:53:26 -> https://github.com/w3c/dap-charter/issues/100#issuecomment-654784016 Status report of ALS privacy concerns and their mitigations 06:53:27 q? 06:53:30 q+ 06:53:38 Will: Do not need high precision. Roughly 2 readings a second within 50 lux. 06:54:10 q? 06:54:36 marcosc: Would want a risk assessment to understand if a malicious application could abuse the sensor in a similar way. 06:55:18 ack anssik 06:55:39 Will: The specification seems to be stuck, what is the status? 06:55:50 reillyg: Implementation paused in chromium 06:56:10 anssik: Some data driven investigation was not able to confirm the concerns raised by Mozilla 06:56:39 w3c privacy review was unable to validate concerns, unblocking progress for previous concerns. 06:56:50 current blocker is awaiting strong use cases. 06:57:18 q? 06:57:28 ack reillyg 06:58:19 reillyg: Heard high value clarification: 06:58:40 Camera can't solve the problem alone. Need better calibrated light levels that ambient light sensor can provide 06:58:49 q+ 06:59:36 All sensors currently are exposed without requesting permissions (except in Safari) 07:00:00 Not ideal, would like to find a way to transition sensors to a permission system 07:00:14 Hesitant to add more sensors without permission 07:00:44 Camera permission an option 07:00:59 In combination with other privacy mitigations (limiting accuracy) 07:01:29 Suggest we circulate a proposal through wide review with the camera permission + mitigations. 07:02:14 Will: Had similar thoughts to augment the Media stream with an ambient level stream. 07:02:28 reillyg: There's a permissions spec that includes camera permissions 07:02:30 -> https://w3c.github.io/permissions/ Permissions spec 07:02:44 Sensor specs augment the permissions spec 07:02:54 -> https://w3c.github.io/permissions/#permission-registry Permission Registry 07:03:28 Fits well to have ambient light sensor spec also reference the camera permission. 07:04:06 May have other concerns, e.g. does ambient light reading warrant browser interface showing camera usage 07:04:53 (Those comments without attribution were from Reilly) 07:06:52 reillyg: Unsure if there's any additional channels for get user media, e.g. IR cameras 07:07:06 RRSAgent, generate minutes 07:07:06 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html scheib 07:07:18 Will: How will this move forward 07:07:35 anssik: We'll form a proposal to circulate to e.g. WebRTC 07:08:14 present+ Will_Morgan 07:09:51 reillyg: In Chromium context, would take this to privacy review etc. Value in spec forum proposal and wide review. 07:10:17 proposed RESOLUTION: Define Ambient Light Sensor Permissions API integration combining this feature with "camera" permission 07:12:24 Will: What will the proposal look like? Another media track along with media? Will need to contemplate offline and consider making a pull request. 07:14:20 Will: If not feasible to put behind getUserMedia is there a framework we could use? 07:15:45 reillyg: There's a desire to put sensors behind a permission. But no cross vendor idea for how to do this - issue with compatibility change. 07:16:38 ... explaining sensors to users has stalled progress 07:16:50 q? 07:17:23 anssik: Don't believe we've bundled permissions before 07:17:29 Will: Indeed that's a risk 07:17:49 proposed RESOLUTION: Explore Ambient Light Sensor Permissions API integration combining this feature with "camera" permission 07:18:22 RESOLUTION: Explore Ambient Light Sensor Permissions API integration combining this feature with "camera" permission 07:19:32 RRSAgent, draft minutes 07:19:32 I have made the request to generate https://www.w3.org/2021/04/08-dap-minutes.html anssik 10:24:39 Zakim has left #dap