16:44:06 RRSAgent has joined #dap 16:44:11 logging to https://www.w3.org/2024/02/12-dap-irc 16:44:11 RRSAgent, make logs Public 16:44:12 please title this meeting ("meeting: ..."), anssik 16:44:18 Meeting: DAS WG working session: DeviceOrientation Event issue triage - 12 Feb 2024 16:44:25 Chair: Anssi, Reilly 16:44:47 Agenda: https://www.w3.org/events/meetings/9b57c50d-617c-499c-abb6-60e20d79d45b/ 16:46:22 Scribe: Anssi, Reilly 16:48:34 ScribeNick: anssik 16:50:50 RRSAgent, draft minutes 16:50:52 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 16:55:36 Juha_Vainio_Intel has joined #dap 16:59:40 Present+ Anssi_Kostiainen 16:59:44 Present+ Juha_Vainio 16:59:49 Present+ Raphael_Kubo_da_Costa 17:03:27 Present+ Laura_Morinigo 17:05:52 Present+ Reilly_Grant 17:06:11 RRSAgent, draft minutes 17:06:13 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 17:06:45 Topic: Welcome 17:07:12 anssik: In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for its expected CR Snapshot publication. 17:07:17 -> Latest specification https://www.w3.org/TR/orientation-event/ 17:07:21 -> Open issues https://github.com/w3c/deviceorientation/issues 17:08:10 reillyg: we're in a good position with this spec that has a lot of implementation experience, an older specification 17:08:23 ... similar to the work we did with Geolocation API to get it to Rec 17:08:40 ... thanks Raphael for all the work in modernizing this spec and cleaning it up to standards 17:09:31 ... today we go thought the existing issues to see which are v2 to be deferred for later 17:09:48 ... we can go from older newest 17:09:59 https://github.com/w3c/deviceorientation/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc 17:11:01 Topic: Add way of getting current orientation 17:11:25 #11 17:11:26 https://github.com/w3c/deviceorientation/issues/11 -> Issue 11 Add way of getting current orientation (by marcoscaceres) 17:12:04 reillyg: Geolocation API provides getCurrentPosition() 17:12:34 ... getCurrentOrientation() could be implementable however it seems extremely polyfillable 17:12:52 ... observables can wrap events so you'll get just the first event in a fluid way 17:13:08 ... not sure there's significant value in adding this to the API 17:13:14 ... not a terrible idea either 17:13:56 ... because sensors fire events all the time, the app probably wants to receive a few values and average the results to filter out noise, doing this properly could get complicated 17:14:57 Raphael: we have a legacy API we must maintain because everyone implement it, it probably does not make sense to add another method to this API, Generic Sensor API would be better alternative 17:15:39 Reilly: there's no promise-based version in the Generic Sensor API to get current reading 17:16:50 ... I'd like to take an action to close this issue with a comment 17:23:51 proposed RESOLUTION: A Promise-returning API can easily be polyfilled, #11 is considered closed 17:24:20 RESOLUTION: A Promise-returning API can easily be polyfilled, #11 is considered closed 17:24:32 Topic: Malicious use of the phone's Gyroscope 17:24:34 #30 17:24:34 https://github.com/w3c/deviceorientation/issues/30 -> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren) 17:26:01 Raphael: we're not exposing on insecure contexts 17:26:17 Reilly: Chrome issue was mitigated by capping frequency to 60 Hz 17:26:45 ... I'd say that given a number of mitigations in place we could consider this closed 17:27:26 Raphael: bug report says just capping the frequency wouldn't mitigate this? 17:28:33 Reilly: accuracy not mentioned in this paper as a mitigation, we've added that additional mitigation to this spec 17:28:43 ... reduces passive fingerprinting 17:30:52 -> passive fingerprinting issue https://github.com/w3c/deviceorientation/issues/85 17:30:53 https://github.com/w3c/deviceorientation/issues/85 -> CLOSED Issue 85 Move fingerprintable APIs behind permissions (by pes10k) [privacy-tracker] 17:33:10 Reilly: I think we can close given the proposed mitigations have been implemented and more, close with an invitation for the community to investigate this API further 17:33:26 Raphael: WFM, since the mitigations suggested are in place 17:34:39 proposed RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented 17:35:25 https://github.com/w3c/deviceorientation/pull/123 -> MERGED Pull Request 123 Add Permissions API integration, start requiring requestPermission() usage (by rakuco) 17:37:05 Reilly: the paper suggests a low-pass filter could be applied to filter our higher frequencies 17:37:30 s/our/out 17:37:51 proposed RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented, consider #30 addressed 17:37:52 https://github.com/w3c/deviceorientation/issues/30 -> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren) 17:38:11 RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented, consider #30 addressed 17:38:27 Topic: Security/privacy consideration: cross-origin linkage 17:38:27 #33 17:38:27 https://github.com/w3c/deviceorientation/issues/33 -> Issue 33 Security/privacy consideration: cross-origin linkage (by wseltzer) [privacy-tracker] 17:39:03 Reilly: agree with Raphael this has been mitigated as commented in https://github.com/w3c/deviceorientation/issues/33#issuecomment-1939126266 17:39:04 https://github.com/w3c/deviceorientation/issues/33 -> Issue 33 Security/privacy consideration: cross-origin linkage (by wseltzer) [privacy-tracker] 17:39:24 Raphael: it is in S&P section, not integrated into the algorithms 17:39:41 Reilly: but MUSTSs in that section are implemented? 17:39:51 Raphael: in Blink yes 17:40:07 Reilly: an action is to update the algorithms to match implementations 17:41:14 proposed RESOLUTION: Integrate visibility state check into affected algorithms, that closes #33 17:41:33 RESOLUTION: Integrate visibility state check into affected algorithms to close #33 17:41:48 Topic: Need to define the DeviceMotionEvent constructor 17:41:48 #83 17:41:49 https://github.com/w3c/deviceorientation/issues/83 -> Issue 83 Need to define the DeviceMotionEvent constructor (by foolip) 17:42:19 Reilly: we don't have algorithms for contructors and Raphael found some implementation issues 17:42:55 ... constructors inherit from the DOM spec, no need to spec constructor prose, IDL implementation difference between Blink and Gecko 17:43:44 ... DOM spec should define getter steps for each of the attributes 17:44:41 ... I'd say close #83 and fix #91 17:44:42 https://github.com/w3c/deviceorientation/issues/91 -> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz) 17:46:29 Reilly: if we close #91 do we need to write spec text? 17:46:39 Raphael: if we change the IDL we don't need prose 17:46:53 Reilly: need to figure IDL then and align with implementations 17:47:31 Topic: Device motion sampling frequency 17:47:34 #87 17:47:35 https://github.com/w3c/deviceorientation/issues/87 -> Issue 87 Device motion sampling frequency (by marcoscaceres) [privacy-tracker] 17:48:31 Reilly: this is the same Gyrophone paper than in the earlier issue #30 17:48:31 https://github.com/w3c/deviceorientation/issues/30 -> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren) 17:49:00 Reilly: Firefox issue notes browser caps, information is outdated 17:49:32 Raphael: spec does not seem to mention frequency caps 17:50:33 ... implementations poll the backend 17:50:55 Reilly: normatively limiting the rate would solve this issue, assuming every implementation does that? 17:51:26 Raphael: I don't know what Firefox and WebKit do 17:51:50 Reilly: action item to confirm what engines do and normative specify cap 17:52:52 Raphael: would be great to get feedback from other engines to understand what is the limit they settled on 17:53:38 Reilly: good topic to discuss when we kick off joint work with WebApps WG 17:53:52 Raphael: could also follow up on the GH issue 17:54:08 ... I can take that action 17:54:59 ... should we try to solve this prior next CR Snapshop or defer to a later snapshot? 17:55:10 anssik: OK to go to CR Snapshot with open issues 17:55:26 Topic: DeviceMotionEvent atttributes can't be null per current IDL 17:55:29 #91 17:55:29 https://github.com/w3c/deviceorientation/issues/91 -> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz) 17:57:32 Raphael: I looked at this, all engines do this differently and current IDL is wrong 17:57:55 Reilly: many layers of dictionaries, complexity that you can fire an event with null events 17:58:17 ... null and undefined are two different things, must be handles differently 17:59:18 Reilly: acceleration, accelerationIncludingGravity must be nullable, initialization with null is valid 17:59:59 ... usual WebIDL behaviour is passing empty dictionary you get default initialized dictionary that gets you all of the individual values set to null 17:59:59 RRSAgent, draft minutes 18:00:00 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 18:00:28 Reilly: if dictionary is not required can it be null or only undefined 18:01:44 Reilly: we want to distinguish between null and undefined? Is that useful thing to do? 18:02:09 ... would be helpful to enumerate reasonable uses of the constructor and make sure that is possible through IDL 18:03:29 ... default dictionary construction not doing what is useful for the spec 18:04:33 ... all dicts are nullable indicates support for the values of that attribute the sensor can return 18:05:19 Raphael: what if you make acceleration, accelerationIncludingGravity and rotationRate nullable and default to null 18:07:09 Reilly: we say default value is null? 18:07:21 ... is it value for dict value to be null? 18:07:41 s/ it value/ it valid 18:08:16 Reilly: if nullable dict type is valid we can say default value is null 18:09:27 ... I will add a proposal to the GH issue to revert #55 and explicitly define the default values for acceleration, accelerationIncludingGravity and rotationRate to be null 18:09:28 https://github.com/w3c/deviceorientation/pull/55 -> MERGED Pull Request 55 Remove '?' from dictionary members of DeviceMotionEventInit (by reillyeon) 18:10:01 Raphael: if we do that though, it will diverge from implementations 18:11:00 ... what you propose is the right way to go about and make implementation to align with that 18:12:47 proposed RESOLUTION: Seek feedback from WebIDL experts to ensure the proposed spec changes are correct 18:13:42 RESOLUTION: Seek feedback from WebIDL experts to ensure the proposed spec changes are correct 18:14:23 https://github.com/w3c/deviceorientation/pull/123 -> MERGED Pull Request 123 Add Permissions API integration, start requiring requestPermission() usage (by rakuco) 18:15:13 Topic: Behavior when event data cannot be provided is underspecified 18:15:26 #118 18:15:26 https://github.com/w3c/deviceorientation/issues/118 -> Issue 118 Behavior when event data cannot be provided is underspecified (by rakuco) 18:15:47 Raphael: underdefined behaviour that is not a big issue, the spec could provide more detail here 18:16:13 Reilly: would be nice to improve this because now we have permissions and when you grant permission you may or may not have fired an event 18:16:27 ... being more specific would be nice 18:16:40 ... in reality there are no platforms where new sensors appear 18:17:05 ... and currently there's agreement whether to fire an empty event if no permission 18:17:19 ... Safari doesn't fire an event in such a case matching the spec behaviour 18:18:06 ... I'm of an opinion APIs should provide errors 18:18:13 ... an idea of an empty event appeals to me 18:18:31 ... you can check permission state, it'd be nice if the API could produce an error 18:18:55 Raphael: there's nothing in the spec that says there's just one error, should there be text there's just one event? 18:19:27 Reilly: only one event type checks for significant difference, deviceorientation specifically 18:19:46 ... I'm be fine amending this so that single event should be fired in this case 18:20:06 ... how that interacts with multiple event listeners, I guess only fires the first times 18:20:19 Raphael: I'd expect in that case to fire once per each listener? 18:20:49 Reilly: in overlapping cases sensor state is changing with fire once semantics 18:21:00 RRSAgent, draft minutes 18:21:02 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 18:21:43 Raphael: from spec perspective it makes sense to say fire a null event once 18:21:53 Reilly: right, still underspecified but clearer 18:22:21 Raphael: OTOH, between this and permission handling, if permission denied fire one event as well? 18:22:44 Reilly: if we introduce sensor state concept, "started", "stopped", "errored" it'd be easier to spec 18:23:12 ... if we add these states and state machine it'd be easier to spec 18:23:23 ... all implementation have a state machine 18:23:34 Raphael: even speccing this is the first event listener is hard 18:23:58 Reilly: if the event listener mechanism tries to hide this detail, it becomes impossible 18:24:12 Raphael: is this so big of an issue? 18:24:34 anssik: we can surface this in the proper as an issue? 18:24:52 Topic: DeviceOrientationEvent.absolute's value when data cannot be obtained 18:24:53 #119 18:24:54 https://github.com/w3c/deviceorientation/issues/119 -> Issue 119 DeviceOrientationEvent.absolute's value when data cannot be obtained (by rakuco) 18:25:30 Reilly: this is about null events, I'd say we'll init this to false, I believe all implementation do that 18:25:43 Raphael: I can take an action to check what WebKit and Gecko do in here 18:26:34 Topic: Guidance needed: how to acquire compass headings in a future-compatible manner? 18:26:36 #137 18:26:37 https://github.com/w3c/deviceorientation/issues/137 -> Issue 137 Guidance needed: how to acquire compass headings in a future-compatible manner? (by juj) [question] 18:27:04 Reilly: this is a known area of implementation incompatibility and we should discuss this with reps from the WebKit project 18:27:27 Raphael: there was an implementation of DeviceOrientation when Blink did not exist 18:27:44 ... a new WebKit implementation landed a few years ago 18:28:43 RRSAgent, draft minutes 18:28:44 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 18:29:21 Topic: Wrap up 18:29:58 anssik: thanks editors for your diligent! 18:30:31 s/diligent!/diligent work on this spec! 18:30:36 RRSAgent, draft minutes 18:30:37 I have made the request to generate https://www.w3.org/2024/02/12-dap-minutes.html anssik 19:17:36 Zakim has left #dap