16:02:32 RRSAgent has joined #dap 16:02:36 logging to https://www.w3.org/2024/09/24-dap-irc 16:02:36 RRSAgent, make logs Public 16:02:37 please title this meeting ("meeting: ..."), anssik 16:04:26 Meeting: Devices and Sensors WG + WebApps WG F2F – 24 September 2024 16:04:28 atsushi has joined #dap 16:04:47 Chair: Anssi, Leonie 16:04:54 Agenda: https://github.com/w3c/devicesensors-wg/issues/69 16:04:55 https://github.com/w3c/devicesensors-wg/issues/69 -> Issue 69 Devices and Sensors WG - TPAC 2024 agenda (by anssiko) 16:05:22 Scribe: Anssi 16:05:27 scribeNick: anssik 16:05:37 tink has joined #dap 16:05:48 Present+ Anssi_Kostiainen 16:05:49 present+ Léonie 16:05:56 Present+ Reilly_Grant 16:06:00 Present+ Atsushi_Shimono 16:06:04 Present+ Xiaoqian_Wu 16:06:11 Present+ Matthew_Reynolds 16:06:15 Present+ Diego_Gonzalez-Zuniga 16:06:19 Present+ Theresa_OConnor 16:06:28 Present+ Olli_Pettay 16:06:55 Present+ Marijn_Kruisselbrink 16:07:15 Present+ Steven_Becker 16:07:39 RRSAgent, draft minutes 16:07:40 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 16:07:50 arma has joined #dap 16:09:10 Present+ Marcos_Caceres 16:10:10 reillyg has joined #dap 16:10:12 Present+ Arnaud_Mandy 16:10:22 Present+ Christian_Liebel 16:10:34 Present+ David_Risney 16:10:44 Present+ Howard_Wolosky 16:10:57 Present+ Kagami_Rosylight 16:11:19 Topic: Welcome 16:11:48 smaug has joined #dap 16:11:54 hober has joined #dap 16:11:56 present+ 16:12:09 mattreynolds has joined #dap 16:12:11 Amanda has joined #dap 16:12:19 rwarren2 has joined #dap 16:12:30 anssik: Welcome to the Devices and Sensors WG and WebApps WG joint F2F! 16:13:11 NatashaGaitonde has joined #dap 16:13:30 diekus has joined #dap 16:13:35 present+ Raphael_Kubo_da_Costa 16:14:17 krosylight1 has joined #dap 16:14:21 RRSAgent, draft minutes 16:14:22 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 16:14:28 krosylight1 has left #dap 16:14:28 present+ 16:14:28 present+ Diego Gonzalez 16:14:28 krosylight has joined #dap 16:14:28 xiaoqian has joined #dap 16:14:30 MarianH has joined #dap 16:14:32 dmurph has joined #dap 16:14:34 kenchris has joined #dap 16:14:36 present+ Rob Warren 16:14:36 present+ 16:14:41 present+ 16:14:42 present+ Dan Murphy 16:14:47 present+ Kenneth Christiansen 16:14:50 present+ Marian Harbach 16:15:05 garykac has joined #dap 16:15:12 HowardWolosky has joined #dap 16:15:19 Subtopic: Agenda bashing 16:15:22 anssik: we have 4 joint deliverables on the agenda today: 16:15:24 present+ 16:15:27 ... - Screen Wake Lock API 16:15:27 present+ Amanda Baker 16:15:32 present 16:15:40 ... - Device Orientation and Motion (was DeviceOrientation Event specification) 16:15:43 ... - Geolocation API 16:15:48 ... - Contact Picker API 16:15:56 ... any last-minute issues to bring to the agenda? 16:15:56 ... note for Contact Picker API we did not have any specific issues 16:16:00 present+ 16:16:12 ayu has joined #dap 16:16:13 Topic: Charter update 16:16:49 anssik: at last year's TPAC we establish guidelines for joint deliverables and initiated rechartering of both the DAS WG and WebApps WG to ensure both the charters are aligned and adhere to the principles we laid out in the W3C Guide for joint deliverables 16:16:55 ... both the groups successfully rechartered Feb 2024 16:17:11 Marcosc has joined #dap 16:17:22 Topic: Screen Wake Lock API 16:17:38 gb, this is w3c/screen-wake-lock 16:17:38 anssik, OK. 16:17:43 anssik: we had two issues on our agenda 16:17:50 Subtopic: Distinguish exceptions on .request() 16:18:05 anssik: issue #352 opened by Marcos 16:18:06 https://github.com/w3c/screen-wake-lock/issues/352 -> Issue 352 Distinguish exceptions on .request() (by marcoscaceres) 16:18:35 anssik: this issue is about what names we should use for error conditions 16:19:06 reillyg: figuring out what errors to use with request() method 16:20:15 Olli: we should not use specific messages 16:20:16 hagio_nhk has joined #dap 16:20:57 christianliebel has joined #dap 16:21:06 present+ 16:21:17 reillyg: trying to figure out what are the areas where we don't yet disagree 16:21:38 ... two situations are: fully active check, visibility check, which can fall in invalid state 16:21:52 marcos: security error or not? 16:23:01 reillyg: there's four checks: fully active, visibility state, permission policy check, permission check 16:23:53 marcos: for fully active and focused, and visible there's a nice hook in HTML, "fully active traversable", we can capture all these additional checks in a single statement 16:24:48 " fully active descendant of a top-level traversable with user attention " 16:25:10 https://html.spec.whatwg.org/#fully-active-descendant-of-a-top-level-traversable-with-user-attention 16:25:22 marcos: covers a lot of cases, does not yet address the main issue 16:25:38 ... not allowed generally for permissions is good 16:26:01 ... visibility state for user attention 16:26:31 reillyg: important for the spec to use NotAllowedError consistently, we change fully active check to invalid state check 16:26:32 LuHuang has joined #dap 16:26:52 ... Chromium willing to accept web compat impact for the change 16:27:21 marcos: another thing, require the doc to be visible, does that have significant web compat impact? 16:28:20 reilly: posted a proposal to the issue as a comment 16:29:22 Subtopic: Require transient activation to request lock 16:29:38 anssik: issue #350 and PR #351 16:29:38 https://github.com/w3c/screen-wake-lock/pull/351 -> Pull Request 351 Require transient activation (by marcoscaceres) 16:29:39 https://github.com/w3c/screen-wake-lock/issues/350 -> Issue 350 Require transient activation to request lock (by marcoscaceres) 16:29:49 ... discussion on what user activation state to use. 16:30:03 ... - transient activation i.e. user currently interacts with the page, has two flavours: 16:31:12 ... -- "use" transient activation to allow multiple calls per user activation 16:31:23 ... -- "consume" to prevent multiple calls per user activation 16:31:27 ... - sticky activation i.e. check if the user has ever interacted with the page 16:31:38 ... Reilly provided data from Chromium Dec 2022: "about 80% of screen wake lock requests do not have user activation" and Apr 2024 "Chromium's metrics look better for [sticky activation] and it means that a site can reacquire a lock if it had one before but lost it due to visibility changes 16:31:43 -> https://github.com/w3c/screen-wake-lock/issues/350#issuecomment-1343570525 16:31:44 https://github.com/w3c/screen-wake-lock/issues/350 -> Issue 350 Require transient activation to request lock (by marcoscaceres) 16:31:47 -> https://github.com/w3c/screen-wake-lock/pull/351#issuecomment-2043531810 16:31:48 https://github.com/w3c/screen-wake-lock/pull/351 -> Pull Request 351 Require transient activation (by marcoscaceres) 16:31:57 reillyg: use case is to be able to reacquire wake lock as needed 16:32:12 ... screen off site loses the wake lock 16:32:23 ... if the site becomes visible again should be able to reacquire 16:32:36 ... you may be looking at a recite and have the same expectations you see what the page was representing you 16:32:54 ... if we do require any user activation at all it needs to be sticky so the site can reacquire the clock 16:33:03 ... proposing a more complex approach in the issue 16:33:18 ... that is to require transient activation first 16:33:22 -> https://github.com/w3c/screen-wake-lock/issues/350#issuecomment-1719530862 16:33:49 marcos: a pointer the current WebKit implementation: 16:33:50 -> https://github.com/w3c/screen-wake-lock/issues/350#issuecomment-1831274350 16:33:51 https://github.com/w3c/screen-wake-lock/issues/350 -> Issue 350 Require transient activation to request lock (by marcoscaceres) 16:34:02 reillyg: we have some data on Chromium usage 16:34:34 ... requiring an activation is going to have an impact, we have to consider a migration path to minimize web compat impact 16:35:05 Olli: marcos do you know of any web compat issues from WebKit? 16:35:29 marcos: I think out our implementation is different 16:36:00 ... it makes sense to have this in place, this is powerful and would be a great thing 16:36:14 Olli: we should have a warning in console "this will change soon" 16:36:30 reillyg: what error should we throw when we don't have transient activation state? 16:36:58 marcos: I'll check what others go in a similar situation, 16:37:21 RRSAgent, draft minutes 16:37:22 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 16:37:57 reillyg: a possible scenario: user decided to not click, you just called it at the wrong time? 16:38:30 ... one example is a security error 16:38:48 ... there should be a standard algorithm step for this we should reuse for consistency 16:39:20 ... if the proposal is to throw an error I can formulate that into a GH comment 16:40:30 zkis has joined #dap 16:40:36 marcos: LGTM 16:41:09 Olli: LGTM, but some sites might he broken, need to figure out what to do 16:41:20 s/he/be 16:42:18 anssik: anything else to discuss for Screen Wake Lock today? 16:42:47 marcos: permission prompt issue status? 16:43:02 reillyg: if the screen is on then the API is active and you can close down the API by turning off the screen? 16:43:07 yuanchen has joined #dap 16:43:18 marcos: the concern from the WebKit side is we now fake the permission 16:43:34 ... it does not meet the conditions of it being a powerful feature to require prompting 16:43:43 ... we should remove dependency on the Permission API 16:43:56 alexis_menard has joined #dap 16:44:08 reillyg: in the latest version of the Permissions API, policy control is integrated 16:44:45 Subtopic: Should this prompt 16:44:50 anssik: issue #324 16:44:51 https://github.com/w3c/screen-wake-lock/issues/324 -> Issue 324 Should this prompt? (by marcoscaceres) 16:45:52 marcos: Firefox shipped without permission prompt 16:46:00 ... having a setting so the user can disable the API 16:46:19 reillyg: if the setting would be toggled it makes sense to expose that to the site via .query() 16:46:41 ... we would reject the promise, but it would also mean developers understand why the site is not working 16:47:08 marcos: it would be good for us to see what permission policy needs from an iframe 16:47:36 ... WebKit has specific code to handle this case currently 16:47:49 ... you never prompt 16:48:19 ... screen wake lock is not a powerful feature, it is a policy controlled feature 16:48:34 ... get rid of permission and user prompts 16:49:39 marcos: proposing we tweak the wording, the UI presents some kind of thing such as a camera, indicator of sorts what wake lock is on for this particular tab 16:49:51 reillyg: nobody implement that currently 16:50:08 ... this feels like a different thing, the questions is should we have Permissions API integration 16:50:17 ... Mozilla considers using this for the user setting 16:52:19 reillyg: permissions that don't prompt and provide settings -- any examples of that usage? 16:53:11 ... are you OK with the proposed resolution being drafted in the GH comment? 16:54:22 marcos: will took a time to review this proposal after the meeting 16:54:32 Topic: Device Orientation and Motion 16:54:37 gb, this is w3c/deviceorientation 16:54:37 anssik, OK. 16:54:42 Subtopic: CR Snapshot publication 16:54:49 anssik: CfC to publish CR Snapshot passed on March 2024 16:54:58 -> https://lists.w3.org/Archives/Public/public-device-apis/2024Mar/0000.html 16:55:02 anssik: after CfC we received feedback that we should identify "at risk" features, the "at risk" features are annotated in the spec, changes in PR #149. 16:55:03 https://github.com/w3c/deviceorientation/pull/149 -> MERGED Pull Request 149 editorial: Identify at risk features and their causes (by reillyeon) 16:55:09 ... the following features were identified as "at risk" 16:55:14 -> https://www.w3.org/TR/orientation-event/#permissions-integration 16:55:20 -> https://www.w3.org/TR/orientation-event/#deviceorientationabsolute 16:55:29 -> https://www.w3.org/TR/orientation-event/#automation 16:55:30 anssik: we also have "what's new since previous CR:" 16:55:35 -> https://www.w3.org/TR/orientation-event/#sotd 16:55:54 anssik: it's now 6 months since the CfC passed, so I'd like the groups to advance with the CRS publication and continue work in subsequent updates. The most recent CR is from 2016. 16:56:27 reilly: I'm happy with the document as is 16:56:48 marcos: I don't have any concerns 16:57:23 reillyg: WebKit implement the permissions integration, Chromium has not had time to do that yet 16:57:30 ... automation is good to have and improves the testing story 16:57:40 present+ 16:57:50 ... the only truly "at risk" feature is the deviceabsoluteorientation 16:57:57 ... WebKit has its own version of that 16:59:05 anssik: we did an issue triage on Feb 2024 in preparation for the CRS publication 16:59:13 -> DeviceOrientation Event issue triage - 12 Feb 2024 - minutes https://www.w3.org/2024/02/12-dap-minutes.html 16:59:17 anssik: we have 4 open issues from that triage that are also considered non-blocking for the CRS publication 16:59:23 ... do we want to discuss any of them today? 16:59:31 ... they are #87 #91 #118 #137 16:59:31 https://github.com/w3c/deviceorientation/issues/137 -> Issue 137 Guidance needed: how to acquire compass headings in a future-compatible manner? (by juj) [question] 16:59:31 https://github.com/w3c/deviceorientation/issues/118 -> Issue 118 Behavior when event data cannot be provided is underspecified (by rakuco) 16:59:31 https://github.com/w3c/deviceorientation/issues/91 -> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz) 16:59:32 https://github.com/w3c/deviceorientation/issues/87 -> Issue 87 Device motion sampling frequency (by marcoscaceres) [privacy-needs-resolution] 17:00:07 marcos: still surprising we have 3 permissions policies for this API 17:01:53 reillyg: more recent changes have moved permissions policy concepts into this spec and we think those issues are not resolved 17:02:19 ... I want to publish this CR Snapshot, given that issue is marked as "at risk" 17:03:01 ... permissions and automation are good to have, agree Marcos 17:03:08 Marcos: absolutely yes 17:03:34 ... only concern with automation it ties into the automation model based on Generic Sensor API, it may be a great model, however 17:04:28 proposed RESOLUTION: Publish a Candidate Recommendation Snapshot of Device Orientation and Motion with "at risk" features as identified 17:04:59 +1 17:06:17 RESOLUTION: Publish a Candidate Recommendation Snapshot of Device Orientation and Motion with "at risk" features as identified 17:06:31 Topic: Geolocation API 17:06:37 gb, this is w3c/geolocation 17:06:37 anssik, OK. 17:06:45 Subtopic: WebDriver Testing API 17:06:51 anssik: #146 and draft PR #170 17:06:52 https://github.com/w3c/geolocation/pull/170 -> Pull Request 170 Add test automation support via Web Driver (by marcoscaceres) 17:06:52 https://github.com/w3c/geolocation/issues/146 -> Issue 146 A means to test the API via Web Driver (by marcoscaceres) 17:07:06 anssik: Marcos proposed an API for a WebDriver extension for emitting a GeolocationPosition 17:07:16 ... what would you like to bring to the groups' attention? 17:07:36 marcos: wanted to introduce this extension 17:07:45 ... reilly pointed out a few concerns 17:08:03 ... I looked at how to do this in WebKit, using a mock API that sets a location for an origin 17:08:34 reillyg: we'd set a mock location for a top-level traversable, this gives developers what developers expect, applies to the entire page for its lifetime 17:09:04 marcos: we wanted for WebDriver and BiDi, we'd set and get an ack it is set 17:09:19 ... it was cool that the same API surface can clear, and generate errors 17:09:42 ... I think it covers all the cases the developers would need 17:09:49 ... for folks in the groups, please take a look 17:10:00 ... if you have knowledge of WebDriver BiDi contributions welcome! 17:10:30 Subtopic: Learnings from the updatable Recommendation journey 17:10:51 anssik: after an evaluation of available options for revising the W3C Recommendation Geolocation API, the joint groups decided in May 2024 to advance with the "Revising a W3C Recommendation" mechanism defined in the W3C Process 17:10:55 -> https://lists.w3.org/Archives/Public/public-device-apis/2024May/0012.html 17:11:00 -> https://www.w3.org/TR/geolocation/ 17:11:05 anssik: the editors have annotated the Geolocation W3C Recommendation with "purple boxes" that present a diff to the previous Recommendation: 17:11:08 ... a "candidate addition" proposes a new feature 17:11:12 ... a "candidate correction" proposes an error correction 17:11:22 ... new features: 17:11:26 ... - toJSON() 17:11:29 ... - Define units for accuracy 17:11:41 ... corrections: 17:11:41 ... - Update acquisition algorithm to define data types and handle cached positions 17:11:41 ... - Check for non-secure contexts 17:11:41 ... - Clarify units and reference geodetic system for latitude and longitude 17:11:41 ... - Use null instead of NaN when stationary 17:11:44 -> https://www.w3.org/TR/geolocation/#sotd 17:12:09 anssik: "candidate corrections" and "candidate additions" are collectively known as "candidate amendments", and these "candidate amendments" are only made normative when the "purple boxes" are integrated into the spec spec per "Incorporating Candidate Amendments" 17:12:25 -> Incorporating Candidate Amendments https://www.w3.org/policies/process/#change-review 17:13:03 marcos: OK to amend the changes to Recommendation now and then go to CRS and iterate at CR 17:14:21 reillyg: would we want to add the automation parts into the Recommendation? 17:14:57 example changes in purple boxes: https://w3c.github.io/geolocation/#latitude-longitude-and-accuracy-attributes 17:19:03 proposed RESOLUTION: Incorporate Candidate Amendments into the Geolocation API, then do another Recommendation with automation parts integrated 17:20:06 RESOLUTION: Incorporate Candidate Amendments into the Geolocation API, then do another Recommendation with automation parts integrated 17:20:18 rrsagent, this meeting spans midnight 17:21:05 Subtopic: Integrating features from the Generic Sensor API 17:21:09 anssik: on the agenda we have "integrating features from the Generic Sensors API" 17:22:25 marcos: WebKit implements older specs such as Geolocation API 17:22:53 ... can we bring some of the features from the new specs into the older specs? 17:23:33 reillyg: there's been a lot of discussion around Geolocation Sensor, background geolocation has had a lot of discussion 17:24:00 ... would like to discuss recasted Sensor APIs that offer interesting new features over the older APIs 17:24:31 ... e.g. Permissions API integration, the API has a clear sensor initialization process and can signal errors, can integrate permissions and communicate failure 17:24:46 ... that does not work with older API attached to the window object 17:25:14 ... another improvement is that the API provides reading attribute, integrates with rAF and event loop similarly Gamepad API 17:25:37 marcos: you have the details, the ask is is there appetite for us to step back and consider these 17:25:52 ... we acknowledge the use cases 17:26:03 reillyg: the question is can be bring them over? 17:26:23 ... being able to read an event during rAF may not be technically possible 17:26:50 marcos: I think myself and other people need to look at all the possible solutions so we can better debate the merits 17:27:17 ... also developers want to be able to ask for the sensor polling rate, they can ask for less than 60 Hz 17:27:38 ... feedback from Mozilla or WebKit? 17:27:53 s/... also/reilly: 17:28:06 reilly: are you interested in solving these problems? 17:28:21 marcos: we haven't had an opportunity to look at the use cases you're proposing 17:28:39 ... sell us the thing and show what developers made with it and what Safari users are missing out 17:28:59 Olli: might be useful to have a list of things Generic Sensor APIs provide and see how we could implement that based on other APIs 17:29:56 reilly: action on DAS WG to put together an implementation report and/or explainer, list of improvements this API provides so that other browser implementers can consider whether they're interested in the improvements and the improved API 17:31:14 RRSAgent, draft minutes 17:31:15 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 17:36:07 HowardWolosky has joined #dap 17:42:58 alexis_menard has joined #dap 18:07:23 arma7 has joined #dap 18:11:29 alexis_menard has joined #dap 18:11:34 alexis_menard has left #dap 18:35:56 ktoumura has joined #dap 19:27:10 Zakim has left #dap 19:27:34 HowardWolosky has joined #dap 20:22:52 omt has joined #dap 20:26:05 Zakim has joined #dap 20:26:52 aki has joined #dap 20:30:06 xiaoqian has joined #dap 20:34:26 LuHuang has joined #DAP 20:37:46 Meeting: Devices and Sensors WG + WebApps WG F2F (Part 1) / Devices and Sensors WG F2F (Part 2) – 24 September 2024 20:37:55 RRSAgent, draft minutes 20:37:56 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 20:38:38 Topic: Devices and Sensors WG F2F (Part 2) 20:38:40 RRSAgent, draft minutes 20:38:41 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 20:39:36 btriebw has joined #dap 20:42:26 engedy has joined #dap 20:42:51 test3283 has joined #dap 20:46:22 Regarding the agenda, did we discuss system level permissions (e.g. https://github.com/w3c/geolocation/issues/107) in the morning? I am not seeing notes in the minutes about that. 20:46:23 https://github.com/w3c/geolocation/issues/107 -> CLOSED Issue 107 Specify behavior for operating system permissions (by reillyeon) [bug] 20:46:51 Topic: Accelerometer 20:46:56 hagio_nhk has joined #dap 20:46:56 gb, this is w3c/accelerometer 20:46:58 alexis_menard has joined #dap 20:47:00 anssik, OK. 20:47:15 Subtopic: Disable Accelerometer use while Vibration API is in use 20:47:19 anssik: #69 20:47:19 https://github.com/w3c/accelerometer/issues/69 -> Issue 69 Disable Accelerometer use while Vibration API is in use (by MrBrain295) 20:47:24 ... quoting: "The accelerometer could be used to fingerprint people if it is used at the same time as the vibration API. This could be prevented by having the accelerometer disabled or collecting data at a lower accuracy when the vibration API is in use." 20:48:04 ... Reilly notes there's two normative requirements in place in both the Vibration API and Accelerometer (via Generic Sensor API) to mitigate this threat: 20:48:18 Vibration API: "If the document's visibility state is not visible, then return false and terminate these steps." -> https://w3c.github.io/vibration/#dfn-processing-vibration-patterns 20:48:33 Generic Sensor API: "The user agent can expose sensor readings to a Document document if and only if all of the following are true: [...] document’s visibility state is "visible". [...] The focus and origin check on document returns true." -> https://www.w3.org/TR/generic-sensor/#concepts-can-expose-sensor-readings 20:48:37 anssik: these checks ensure only the same document that is also "visible" can access both the APIs at the same time 20:48:42 ... "focus and origin check" ensures third-party site from within iframe cannot use Accelerometer: 20:48:46 -> Focus and origin check https://www.w3.org/TR/generic-sensor/#focus-and-origin-check 20:49:20 reillyg: the original author did not come back to us, theoretically possible, but we haven't seen researchers validating this attack vector 20:50:00 ... mitigation we have in place for Accelerometer should limit to the being able to measure only the strength, is the amplitude enough to fingerprint the device you have? 20:50:03 hgo has joined #dap 20:50:22 ... how your holding the device could impact 20:50:40 ... Balasz, is this a side-channel we have received data on? 20:50:44 Balasz: no 20:53:46 ... proposed approach added to the GH issues 20:53:55 Subtopic: Define normative privacy mitigation 20:53:59 anssik: #57 20:54:00 https://github.com/w3c/accelerometer/issues/57 -> Issue 57 define normative privacy mitigation (by samuelweiler) [privacy-needs-resolution] 20:54:21 anssik: the ask is to normatively specify mitigations suggested in the research papers referenced in the security and privacy considerations 20:54:25 -> https://www.w3.org/TR/accelerometer/#security-and-privacy 20:54:43 reillyg: for Device Orientation event we do have rounding requirement 20:56:06 reillyg: we should port the Device Orientation mitigations over the the Generic Sensor specs 20:56:58 anssik: given Chromium already implements that mitigation for Generic Sensor APIs, this would be just a spec change 20:57:27 ... applies to Accelerometer and Gyroscope 20:57:40 Subtopic: Device calibration of accelerometers may reveal precise hardware fingerprint 20:57:44 anssik: #54 20:57:44 https://github.com/w3c/accelerometer/issues/54 -> Issue 54 device calibration of accelerometers may reveal precise hardware fingerprint (by npdoty) [privacy-needs-resolution] 20:58:46 anssik: I'm interested in feedback from Device Orientation that spec'd Paul Jensen's recommendation of rounding to 0.1 m/s^2: 20:58:53 If acceleration’s x axis acceleration is not null, limit its precision to no more than 0.1 m/s2. 20:58:53 If acceleration’s y axis acceleration is not null, limit its precision to no more than 0.1 m/s2. 20:58:53 If acceleration’s z axis acceleration is not null, limit its precision to no more than 0.1 m/s2. 20:58:59 anssik: and similarly for accelerationIncludingGravity and rotationRate 20:59:12 ... IIRC on Chromium this rounding mitigation is already applied to readings exposed through Accelerometer, LinearAccelerometer, GravitySensor 20:59:24 anssik: there's a "reading quantization algorithm" defined by the Generic Sensor API for this: 20:59:29 -> Generic Sensor API: reading quantization algorithm https://w3c.github.io/sensors/#reading-quantization-algorithm 20:59:49 anssik: and this algorithm is used by ALS currently: 20:59:49 20:59:49 -> Ambient light reading quantization algorithm https://www.w3.org/TR/ambient-light/#ambient-light-reading-quantization-algorithm 21:00:02 anssik: if the Accelerometer implementations already "limit precision to no more than 0.1 m/s2" then an "Accelerometer reading quantization algorithm" would likely fix this issue 21:00:51 Topic: Gyroscope 21:00:51 gb, this is w3c/gyroscope 21:00:51 anssik, OK. 21:00:56 Subtopic: Gamepad API gyro support 21:00:59 anssik: issue https://github.com/w3c/gamepad/issues/211 21:01:00 https://github.com/w3c/gamepad/issues/211 -> Issue 211 Add device orientation support (by jdarpinian) [feature request] [TPAC2024] 21:01:20 xiaoqian has joined #dap 21:01:28 matt: we extended Gamepad API with pose to include this information, that never got implemented in Chromium 21:01:43 ... only Firefox has it for VR gamepads, WebXR has its own XRPose interface 21:01:49 NatashaGaitonde has joined #dap 21:02:05 ... going forward gamepads still have motion sensors, doing it with gamepad not the best interface 21:02:21 ... because gamepad API is poll-based not good to motion sensors 21:02:38 ... a good opportunity to leverage work se did for Generic Sensor-based Gyroscope API 21:02:52 ... remaining concern no permission model on the Gamepad API 21:03:16 ... we don't necessarily want to expose sensor data via Gamepad API without user consent 21:03:35 reillyg: conversation earlier today was what Device Orientation spec can learn from Generic Sensor APIs 21:03:51 ... we took an action to list the differences, one of the things the new API does better is support for multiple sensors 21:04:13 ... you can have Gyroscope on the Gamepad API, expose that through an attribute on Gamepad API, or have multiple Gyroscopes per Gamepad 21:04:39 ... the fact that Generic Sensors support multiple sensors of the same type is really good 21:05:01 ... the other is to say, what if we take the Device Orientation model, fire an event on the gamepad object 21:05:27 ... the difference is whether you want to do polling or not 21:05:51 ... no conclusion, but we have a space of solutions, whether to use the new surface or the old one 21:06:06 matt: using eventListener we couldn't add any permission prompt 21:06:13 sebastian has joined #dap 21:06:32 presence+ sebastian_kaebisch 21:06:34 reillyg: using event-based, it would need to be a global permission, not specific to Gamepad API 21:07:00 dmurph has joined #dap 21:07:52 reillyg: is WebApps looking at this? 21:08:09 matt: not much progress there 21:10:20 Topic: Magnetometer & Proximity 21:10:56 reillyg: both are in a similar state, specced but not shipped, one implemented behind a flag, another not implemented 21:11:11 ... should we update the status of the specs? 21:11:45 anssik: we have requested web developer feedback as follows 21:11:51 -> "This specification is looking for developer feedback and high value use cases. Please provide your feedback via GitHub." https://www.w3.org/TR/magnetometer/#sotd 21:12:01 anssik: but we did get some feedback #59 for high frequency sampling but no new use cases 21:12:02 https://github.com/w3c/gyroscope/pull/59 -> MERGED Pull Request 59 editorial: Use permissions and permissions-policy dfn's from DEVICE-ORIENTATION (by rakuco) 21:12:25 gb, this is w3c/magnetometer 21:12:25 anssik, OK. 21:12:28 xiaoqian has left #dap 21:12:30 #59 21:12:30 https://github.com/w3c/magnetometer/issues/59 -> Issue 59 Request for Magnetometer web developer feedback (by anssiko) 21:13:16 anssik: the spec documents a set of use cases: sensor fusion, VR/AR, gesture recognition, indoor navigation, metal detection, compass 21:13:22 -> Use Cases and Requirements https://w3c.github.io/magnetometer/#usecases-and-requirements 21:14:25 reillyg: I propose we very clearly mark this spec as not actively worked on, we leave the GH repo in place to gather feedback from web developers 21:14:41 anssik: many web developer articles mention mapping app/compass use case for Magnetometer: 21:14:45 -> https://mobiforge.com/design-development/the-generic-sensor-api 21:15:41 anssik: what are the best ways to gather helpful feedback from web developers? 21:15:45 nickname has joined #dap 21:15:50 reillyg: state of HTML has been good to us 21:17:39 gb, this is w3c/proximity 21:17:39 anssik, OK. 21:18:05 anssik: recent updates to the IEEE 802.11 wireless standards enable Wi-Fi Sensing in mainstream devices 21:18:10 -> IEEE Xplore: Wi-Fi Sensing Based on IEEE 802.11bf https://ieeexplore.ieee.org/document/9941042 21:18:14 -> arXiv: An Overview on IEEE 802.11bf: WLAN Sensing https://arxiv.org/abs/2310.17661 21:18:41 anssik: with 802.11bf Wi-Fi-connected devices can be turned into proximity sensors that detect human presence, broadening the installed base of devices capable of supporting this API 21:18:46 ... we might be doing some prototyping in this space and will look at the use cases #4 to identify intersection with the web 21:18:46 https://github.com/w3c/proximity/issues/4 -> Issue 4 Generic Proximity sensor or UserProximity sensor (by tobie) 21:19:05 ... this tech support a range of use cases, room sensing, gesture recognition, health care, 3D vision 21:19:10 ... positive privacy properties in certain scenarios over camera-based implementations 21:21:25 reillyg: Idle Detection API is another API surface that could expose similar information 21:21:51 ... currently that API relies on HID input, this kind of proximity sensor technology could provide a better signal 21:22:16 ... seems like a good way to expose user detection without any of the sensor data 21:24:15 anssik: we can update the status text similarly to magnetometer 21:25:04 Topic: Geolocation Sensor 21:25:09 gb, this is w3c/geolocation-sensor 21:25:09 anssik, OK. 21:25:52 Subtopic: Rescope to address background/geofencing use cases only 21:25:57 anssik: #17 21:25:57 https://github.com/w3c/geolocation-sensor/issues/17 -> Issue 17 Next-gen geolocation use cases (by tomayac) [geo-background-fencing] [use-cases] 21:26:50 reillyg: we should clarify we do not intend to duplicate anything 21:27:07 anssik: Mozilla's position via Marcos from 2018 was to decouple Geolocation API from background/geofencing 21:27:20 ... I recall Apple had a similar position 21:28:48 reillyg: use cases seem mainly fully background geolocation focused 21:29:12 ... one specific use case is a fleet management situation 21:29:51 ... someone doing deliveries is using for business reasons where they are, you don't want the system to go to sleep or the user switching to another task/app so you lose location when you switch context 21:30:13 ... this use case really requires explicit background location with some frequency, possibly via ServiceWorker 21:31:04 Mek: use cases for batched updated vs. real-time updates? 21:33:18 reillyg: we have a good list of use cases, right no browser implementer is trying to solve the related privacy issues 21:34:45 anssik: can we better crowdsource solutions to the privacy issues from the broader community? 21:35:35 Marian: Chrome would need a permission from the OS, right? 21:36:11 atsushi has joined #dap 21:36:45 reillyg: yes, it would be a lot of work, but it would be possible, for installed web apps we can attribute the permission to the application 21:38:17 Evan: are most of the use cases for installed PWA? 21:38:48 reillyg: seems so, would be reasonable to restrict this to installed PWAs outside the browser tab that have an installation requirement 21:39:26 ... use cases such as fitness tracker, driver tracking app fall in this category 21:39:56 ... one of the comments imply they'd trust PWA and not the browser, can you just grant the permission to PWA and not the browser? 21:40:57 reillyg: developer feedback suggests, they'd trust an installed PWA and not generically to the browser 21:41:27 ... implementation-wise, if you trust a PWA you truist the browser too 21:42:19 reillyg: permissions UX for installed apps is better than tabs because you can ask for permission in the context of the installed app 21:45:18 ... a possible next step would be to add this feature to the next "State of HTML" survey to understand relative priority 21:46:00 RRSAgent, draft minutes 21:46:02 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 21:46:23 test3283 has joined #dap 21:47:42 example survey results https://2023.stateofhtml.com/en-US/features/mobile-web-apps/ 22:00:42 Topic: System Wake Lock API 22:01:36 reillyg: the next falls under the topic of System Wake Lock, we split "Wake Lock" into Screen Wake Lock and System Wake Lock 22:02:08 Subtopic: Progress Notification API 22:02:13 -> Progress Notification API https://github.com/explainers-by-googlers/progress-notification 22:02:51 Ishii: scenarios: backgrounding a tab 22:03:01 ... e.g. long download 22:03:24 ... scenario 2: keeping a tab open for a task 22:03:38 ... users forced to keep the tab open 22:03:59 ... some APIs require screen wake lock by playing video or audio 22:04:21 ... scenario 3: tasks when a site isn't open, e.g. cloud file service 22:05:05 ... all scenarios have in common that the user needs to complete an important task 22:05:42 ... use cases: 1) providing hints to the browser, 2) extend the lifetime of a service worker, 3) extend the lifetime 22:05:50 ... proposal: a generic API 22:06:12 engedy has joined #dap 22:06:45 ... security and privacy considerations, must provide UI to inform users of background tasks, provide options for controls, present developer-specified messages in context 22:07:26 ... API shape 22:07:54 ... current state, explainer published, Intent to Prototype for Blink, Getting feedback and other use cases 22:07:55 q? 22:08:06 Evan: naming the API? 22:09:56 reillyg: we want sites to use this often to report to the browser what they're doing 22:10:21 ... I'd limit sites using this all the time 22:11:23 ... it is useful to know if the site is "done" with its task 22:12:07 Balasz: alternative UX options to use to indicate to the user there's background processing happening? 22:12:33 Ishii: if installed we use a different UI 22:12:45 Balasz: interested in a variant that can be exposed on a drive-by web 22:13:06 ... string to describe what type of processing is happenint 22:13:06 s/happenint/happening 22:14:17 s/Ishii/Ayu/g 22:14:43 RRSAgent, draft minutes 22:14:44 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 22:15:25 reillyg: we might show the string in the tab title 22:16:08 ... to use as a replacement for onbeforeunload, need to consider malicious use, is it safe to show the user a string or a progress bar 22:16:47 ... for installed apps, there might be a place to allow a version of this to be notification based, enable more background activity, ability have the tab closed 22:17:54 Balazs: one option is more discrete UI 22:18:22 LuHuang: I looked at a similar problem for installed web apps 22:18:44 ... web apps sometimes want to close the app windows, scenario 3, for some apps it is useful to run the logic in the background 22:19:08 ... we have a breakout session tomorrow for minimized to system tray concept 22:19:35 ... haven't decided yet, should convince users to keep the ServiceWorker open or have associated logic running 22:20:32 reillyg: apps running in the background even if closed, web apps don't have a good concept for that -- figuring out what things you can do in that state 22:20:51 ... when in that state you get Service Worker events, resources constrained 22:21:06 ... user agent can populate the tray with more information 22:21:49 Lu mentioned this Breakout session on Wednesday (System Tray Icon Support for PWAs) https://www.w3.org/events/meetings/c7122995-e333-461d-81a5-eb16b5a98d64/ 22:21:51 LuHuang: I don't think we should go to a direction that SW is short-lived 22:22:58 Vincent: hidden page vs Service Worker, this is a good topic 22:23:19 ... Chrome extensions used a hidden documents for a while and the general approach wasn't good 22:23:28 ... heavy weight, poor practices 22:23:49 ... with ServiceWorker we're careful to allow only execution required by the task 22:24:27 Mek: for SW, single thread not great for long-running tasks 22:25:28 Evan: tab with controlled text in the browser UI, gmail is using that for things that are not really titles 22:26:13 ... a good API to give them a more standardized way to edit tab text 22:26:30 s/text/notification or status indicatore 22:26:43 s/indicatore/indicator 22:26:59 sebastian has joined #dap 22:27:36 MarianH has joined #dap 22:27:58 anssik: can you script favicon for a similar experience? 22:28:11 reillyg: that has some side-effects, not reliable 22:28:17 LuHuang has joined #DAP 22:28:45 Topic: Compute Pressure API 22:28:50 gb, this is w3c/compute-pressure 22:28:50 anssik, OK. 22:29:00 anssik: we completed the wide review #177 for the Compute Pressure API 22:29:01 https://github.com/w3c/compute-pressure/issues/177 -> Issue 177 Wide review tracker (by anssiko) [w3c-process-steps] 22:29:10 ... a Chrome Origin Trial ran during Q4'23 - Q1'24. 22:29:17 ... we received feedback from early adopters of the Compute Pressure API: 22:29:21 -> Origin Trial feedback https://github.com/w3ctag/design-reviews/issues/795#issuecomment-1982796332 22:29:21 https://github.com/w3ctag/design-reviews/issues/795 -> CLOSED Issue 795 Compute Pressure Specification Review (by arskama) [Progress: review complete] [Venue: WICG] [privacy-tracker] [Venue: Devices & Sensors WG] [Missing: Multi-stakeholder support] [Resolution: satisfied with concerns] 22:29:35 anssik: quoting "100% of the respondents are extremely likely to continue using the API." 22:29:38 ... this feedback suggested the current version of the API is addressing real customer needs 22:29:44 ... the Compute Pressure API shipped in Chrome 125 Stable release Q2'24. 22:29:49 HowardWolosky has joined #dap 22:29:54 ... as suggested by Atsushi, the next step for the spec is to advance toward CR 22:30:08 krosylight has joined #dap 22:30:12 ... I asked the editors to do a triage to identify "V2" and "bug" issues 22:30:17 ... "V2" issues are out of scope for CR, non-blocking 22:30:21 ... "bug" issues to be discussed whether they're CR blockers 22:31:11 arnaud: we have 3 items for the spec 22:32:20 ... one was solved #291 22:32:21 https://github.com/w3c/compute-pressure/issues/291 -> Issue 291 "Rate-limiting change notifications" section is confusing (by rakuco) [bug] 22:32:31 arnaud: this can be solved before CR 22:32:49 ... there's a log of discussion mitigations and we need to clear that 22:33:03 arnaud #281 22:33:04 https://github.com/w3c/compute-pressure/issues/281 -> CLOSED Issue 281 "Current pressure state" definition and cardinality are confusing (by rakuco) [bug] 22:33:27 #243 is trickier 22:33:28 https://github.com/w3c/compute-pressure/issues/243 -> Issue 243 Permission policy needs to be checked when owner set changes (by kenchris) [bug] [V2] 22:34:00 arnaud: these are the two remaining issues to be addressed 22:35:02 arnaud: not sure about issue #243 when and how to solve it 22:35:25 reillyg: are developer using this API is Shared Workers? 22:35:43 arnaud: we had a feature request from web developers for shared workers 22:36:22 reillyg: it would be nice to get general advice from WebAppsSec on how to use Permissions Policy in Shared Workers 22:36:42 ... this might be a case where we need to get feedback from another WG 22:37:04 ... as Kenneth says, we probably need to monkey-patch the spec to specify the behaviour 22:37:38 ... the current behaviour might be correct 22:38:07 ... this is a known issue with Shared Workers, if any page has a capability it can share it with any page 22:39:41 ... I think we need to reach out to WebAppSec WG that works on the Permissions Policy, how to do these checks in Shared Workers, then follow their guidance 22:41:11 anssik: https://www.w3.org/TR/compute-pressure/#dom-pressuresource-thermals is proposed as "at risk" feature for CR 22:41:41 atsushi: we just mark it as "at risk" in the specification, we keep it in the CR 22:42:42 arnaud: #233 22:42:43 https://github.com/w3c/compute-pressure/issues/233 -> Issue 233 Use-case: Analytics / RUM (by nicjansma) [V2] 22:43:02 ... buffer compute pressure values before we start the observer 22:43:22 reillyg: is the goal to provide small amount of history? 22:43:29 arnaud: yes 22:43:51 reillyg: I understand the use case, when the page loads, understand if the system is under high pressure 22:45:07 ... what is the cost of monitoring system pressure is the question 22:46:50 ... the issue is if the code monitoring the page loads late in the process, they can't get analytics from the loading process 22:47:05 ... if we can record analytics earlier and report the history that'd be helpful 22:48:03 RRSAgent, draft minutes 22:48:04 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 23:42:17 Topic: Vibration API 23:42:21 gb, this is w3c/vibration 23:42:22 anssik, OK. 23:42:35 Subtopic: Wide review feedback: TAG 23:42:40 anssik: #69 23:42:40 Issue 69 not found 23:42:55 HowardWolosky has joined #dap 23:43:25 https://github.com/w3ctag/design-reviews/issues/971 23:43:25 https://github.com/w3ctag/design-reviews/issues/971 -> Issue 971 Vibration API (by anssiko) [Progress: pending external feedback] [Venue: Devices & Sensors WG] [Focus: API design (pending)] [Focus: Privacy (pending)] [Focus: Accessibility (pending)] 23:43:41 anssik: TAG asks "would enough use cases be served if browsers could treat the device they're running on as a gamepad?" 23:43:58 -> GamepadHapticActuator https://w3c.github.io/gamepad/#gamepadhapticactuator-interface 23:44:33 matt: I don't think that's possible, you can't access any gamepad without it being attached 23:45:39 ... talked about his a little bit, will discuss this more in a specific session, can ask OS to draw an overlay of a gamepad, could in theory design the API to turn the device into a sort of a gamepad, that's seems reasonable, but the issues are how to trigger vibration without any overlay, would need the overlay to be hidden 23:46:56 reillyg: haptics with virtual gamepad is a great idea, but it is unclear whether that is reusable for apps that don't want to use the gamepad part that includes e.g. buttons 23:47:43 ... are there use cases that do not deal with gamepad? I think there are 23:48:11 ... what the developers try to do is neither notification nor gamepad, should provide these as examples in the specification 23:51:46 ... we should author an explainer with alternatives considered, focus on use cases that are not achieved by gamepad API or notifications 23:52:19 anssik: Vibration API is currently reused by the Notifications API and that integration would not work with the Gamepad API 23:52:23 -> https://notifications.spec.whatwg.org/#create-a-notification 23:52:32 anssik: I think the Gamepad generalization and repurposing idea is an interesting idea, but would need that API to change quite a bit 23:53:40 atsushi has joined #dap 23:54:57 Subtopic: Wide review feedback: Privacy 23:55:15 anssik: #42 is about Permissions API integration 23:55:16 https://github.com/w3c/vibration/issues/42 -> Issue 42 Integration with permissions API (by pes10k) [privacy-needs-resolution] 23:55:39 anssik: "Both to address the potential misuse of the API to create a cross-device / cross-context covert channel (and to standardize the behavior of the discussed cases of when the user agent might want to deny access to the API to prevent user annoyance), the API should integration with the permissions API (even if the expected UX for access / denial of that permission isn't a standard permission dialog)" 23:56:09 ... I responded that Permission integration was considered in #10 but after implementation experience user activation-gating #29 was selected as a mechanism instead and that is what the latest editor's draft now reflects 23:56:10 https://github.com/w3c/vibration/issues/29 -> CLOSED Issue 29 Require user activation for navigator.vibrate (by johannhof) 23:56:10 https://github.com/w3c/vibration/issues/10 -> Issue 10 Vibration should require user's permission (by andrey-logvinov) [v2] 23:57:52 reillyg: similar to Screen Wake Lock question, we don't intend to implement a permission for this, other mitigations are considered sufficient 00:00:37 ... there's no Permissions Policy integration, we don't have implementation experience for permissions 00:01:24 ... Permissions Policy integration seems useful 00:03:25 ... could improve the metrics, add a new use counter after checks 00:04:40 ... #43 is about non-privacy related concerns 00:04:40 https://github.com/w3c/vibration/issues/43 -> Issue 43 Misc non-privacy concerns with the API (by pes10k) 00:04:44 ... - ask to make this an async API instead 00:05:00 ... - comment on informative notes that contain extensive advice to implementers, and expand on normative prose 00:05:30 ... I responded that making the API async at this point has web compat impact 00:05:30 ... for informative content, pointed out there's single normative step to bail out: 00:05:30 00:05:30 An implementation MAY return false and terminate these steps. 00:06:44 reillyg: the action to take on this feedback is about consistency, do a pass that our guidance is consistent 00:08:08 Subtopic: Wide review feedback: Security 00:08:19 -> https://github.com/w3c/security-request/issues/71 00:08:20 https://github.com/w3c/security-request/issues/71 -> Issue 71 Vibration API 2024-06-28 > 2024-09-20 (by anssiko) [REVIEW REQUESTED] [WD] 00:08:32 anssik: received suggestions, proposing to incorporate applicable mitigations 00:10:33 ... Standardize of Max Length and Duration 00:11:15 reillyg: Chromium hardcodes certain limit, unless platform API is stricter 00:11:33 ... we could say only 50 entries allowed in vibration pattern 00:12:44 ... 15 seconds seems to be the max duration for many Android devices 00:13:17 s/15 seconds/10 seconds 00:14:01 s/50 entries/10 entries 00:14:10 ... Include Random Vibration 00:15:00 reillyg: we could add random variation, but don't want the app to feel unreliable because of vibration constantly changing 00:15:24 ... adding 10 ms at the end could mitigate the problem 00:15:58 Mek: IPC could already add some randomness and act as a mitigation 00:16:17 ... Request User Consent 00:17:27 anssik: the spec says "[T]he user agent SHOULD inform the user when the API is being used and provide a mechanism to disable the API (effectively no-op), on a per-origin basis or globally" 00:20:34 reillyg: I disagree with the premise of this threat, the premise is that by vibrating the phone you can emulate system UI, but any app can already vibrate your phone 00:22:08 Vincent: Vibration as a concept is understandable, users would understand what they are granting permission to if asked 00:22:45 anssik: Minimize Information Disclosure in Error Handling 00:24:26 reillyg: in order to prevent information disclosure, the API behaviour should be well specified and consistent 00:24:50 ... Limit API Usage 00:25:54 anssik: proposal to add to Security and privacy considerations: "The use agent should employ global rate limiting to restrict the number of vibration requests made within a certain period (e.g., per minute or hour) to prevent excessive use." 00:27:23 reillyg: we can come up with some specific values 00:27:39 ... based on experience and data collected 00:30:35 Subtopic: CRS plan, obsoletion request 00:31:04 anssik: the WG wants to refresh the spec at /TR to do so we need to publish a CR Snapshot given Process 2015 does not enable revising a Recommendation 00:31:10 Zakim has left #dap 00:31:23 ... the process provides us means to obsolete the Recommendations that we cannot update in place, and I'd recommend we do that when we publish the CR Snapshot 00:31:42 proposed RESOLUTION: Request AC to publish the current Vibration API Recommendation as Obsoleted Recommendation and the group will publish a new CR Snapshot with the latest changes incorporated. 00:40:36 RESOLUTION: Request AC to publish the current Vibration API Recommendation as Obsoleted Recommendation and the group will publish a new CR Snapshot with the latest changes incorporated. 00:40:59 Topic: Device Posture API 00:41:04 gb, this is w3c/device-posture 00:41:04 anssik, OK. 00:41:08 anssik: Origin Trial active 00:41:14 -> Trial for Foldable APIs https://developer.chrome.com/origintrials/#/view_trial/4188910603407982593 00:41:20 Subtopic: Wide review feedback 00:41:25 anssik: wide review #146 nearly completed 00:41:26 https://github.com/w3c/device-posture/issues/146 -> Issue 146 Wide review tracker (by anssiko) [process] 00:41:31 ... one a18y issue open #151 00:41:32 https://github.com/w3c/device-posture/issues/151 -> CLOSED Issue 151 Device posture and direction interaction (by aphillips) [i18n-needs-resolution] 00:41:39 ... special thanks for a11y for Accessibility Considerations 00:41:43 -> https://www.w3.org/TR/device-posture/#accessibility-considerations 00:42:43 alexis: no Mozilla or WebKit position 00:42:56 ... for testing, we have w-p-t landed 00:43:12 Subtopic: Candidate Recommendation plan 00:43:48 anssik: with wide review completed, wpt testing story in place, and no blocking open issues, we've be ready for CR 00:43:49 ... do we want to await for Origin Trial feedback prior to making a decision? 00:44:18 alexis: I would think of sending Intent to Ship in the coming weeks 00:44:38 RRSAgent, draft minutes 00:44:39 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik 00:46:01 alexis: #111 00:46:02 https://github.com/w3c/device-posture/issues/111 -> Issue 111 Should Device Posture API be exposed to iframes (JS or CSS) (by darktears) 00:49:12 alexis: CSS exposes this same information to iframes already 00:52:14 anssik: we are ready for CR transition request? 00:52:40 atsushi: I will check with the privacy colleague to confirm PING review status 00:52:54 ... if the WG is fine I'd like to submit the request for publication 00:53:48 proposed RESOLUTION: Start CfC to publish CR of Device Posture API 00:53:58 RESOLUTION: Start CfC to publish CR of Device Posture API 00:54:41 RRSAgent, draft minutes 00:54:42 I have made the request to generate https://www.w3.org/2024/09/24-dap-minutes.html anssik