07:43:37 RRSAgent has joined #dap 07:43:42 logging to https://www.w3.org/2023/09/14-dap-irc 07:43:42 RRSAgent, make logs Public 07:43:43 please title this meeting ("meeting: ..."), anssik 07:43:43 Meeting: Devices and Sensors WG F2F – 14 September 2023 07:43:47 Chair: Anssi, Reilly 07:43:52 Agenda: https://github.com/w3c/devicesensors-wg/issues/66 07:43:56 Scribe: Anssi 07:44:01 scribeNick: anssik 07:44:07 Scribe+ Reilly 07:44:28 gb, this is w3c/devicesensors-wg 07:44:28 anssik, OK. 07:44:37 Present+ Anssi_Kostiainen 07:44:41 Present+ Reilly_Grant 07:44:51 Regrets+ Atsushi_Shimono 07:44:59 Regrets- Atsushi_Shimono 07:45:36 Present+ Atsushi_Shimono 07:46:09 plh has joined #dap 07:46:20 Philippe Le Hegaret, W3C 07:46:25 MarianH has joined #dap 07:46:33 present+ 07:46:38 Present+ Thomas_Steiner 07:46:43 atsushi has joined #dap 07:46:43 Present+ Kenneth_Christiansen 07:46:51 present+ Atsushi_Shimono 07:47:04 present+ 07:47:15 hober has joined #dap 07:47:19 marcosc has joined #dap 07:47:19 present+ 07:47:25 present+ marcosc 07:48:17 Present+ Matt_Reynolds 07:48:23 kenneth has joined #dap 07:48:25 Present+ Tess_OConnor 07:48:37 Present+ Kenneth_Christiansen 07:48:45 present+ Ryo_yasuoka 07:48:55 Present+ Vincent_Scheib 07:49:03 RRSAgent, draft minutes 07:49:04 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 07:49:18 zkis has joined #dap 07:49:18 Penelope has joined #dap 07:49:45 present+ Zoltan_Kis 07:49:53 + Penelope McLachlan 07:50:06 present+ Marian_Harbach 07:50:09 present+ Penelope McLachlan 07:50:20 Topic: Welcome 07:50:54 anssik: Welcome to Devices and Sensors WG F2F! 07:51:25 anssik: IRC https://irc.w3.org/?channels=#dap or irc://irc.w3.org:6667/#dap 07:51:30 anssik: Zoom https://www.w3.org/events/meetings/8c62abaf-4cae-46d3-9b6d-8d0be20166b9/ 07:52:05 reillyg: we'll use queuing system on IRC, we don't use Zoom chat 07:52:11 q? 07:53:26 q+ to ask a question 07:53:26 ack q? 07:53:26 q- anssik 07:53:26 present+ Reilly Grant 08:07:57 zkis has joined #dap 08:10:18 Topic: Charter updates 08:10:49 Topic: Charter update 08:10:49 gb, this is w3c/das-charter 08:10:49 anssik, OK. 08:10:49 anssik: WG chartered until 2024-11-30 08:10:49 -> Devices and Sensors Working Group Charter https://www.w3.org/2022/11/das-wg-charter.html 08:11:11 anssik: Apple has shared it is interested in contributing to a subset of the WG's deliverables, so in order to get Apple onboard we are looking to recharter earlier than that 08:12:23 scribe+ 08:12:23 ... Apple has indicated it is unable to join the DAS WG at this time 08:12:23 ... a proposed solution is to broaden joint deliverables with WebApps WG 08:12:23 https://github.com/w3c/das-charter/issues/123 08:12:23 -> Draft revised Charter https://w3c.github.io/das-charter/das-wg-charter.html 08:12:23 -> Diff to current Charter https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2022%2F11%2Fdas-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fdas-charter%2Fdas-wg-charter.html 08:12:23 anssik: summary of proposed changes: 08:12:23 ... New joint deliverables: 08:12:27 ... - Screen Wake Lock API 08:12:27 ... - DeviceOrientation Event 08:12:27 ... - Geolocation API 08:13:50 ... open issue, "joint deliverable" not defined 08:13:55 https://github.com/w3c/w3process/issues/75 08:14:36 https://www.w3.org/community/w3process/track/issues/93 08:14:47 https://github.com/w3c/w3process/issues/754 08:15:11 https://github.com/w3c/w3process/issues/754 08:15:32 (#754 links to https://github.com/w3c/w3process/issues/2 which links to https://www.w3.org/community/w3process/track/issues/93 ) 08:15:33 https://github.com/w3c/das-charter/issues/754 -> Issue 754 [not found] 08:16:07 q+ 08:16:10 q+ charter for geolocation? 08:16:31 ack hober 08:16:59 hober: We haven't defined joint deliverables in the process but we've been doing them for 20 years. 08:17:17 ... pfh, have there been any problems doing joint deliverables? 08:17:27 q? 08:17:29 s/pfh/plh/ 08:17:39 plh, No, we have not had any issues. 08:17:54 q+ 08:17:56 ... As I understand it the current issue is not patent issue, but a decision point issue. 08:18:20 hober: I don't think we need to define a process. I trust the chairs of both groups and there's an escalation path if we do have a problem. 08:18:26 s/decision point issue/decision policy+success criteria issue/ 08:18:42 s/define a process/block rechartering on the process cg resolving this issue/ 08:19:10 anssik, I agree there hasn't been a problem in the past but I see that there are disagreements in this group which may require resolution. 08:19:13 s/any issues./any issues but there was an issue back in 2024 which was postponed in 2016./ 08:19:22 q+ 08:19:24 s/2024/2014/ 08:19:54 ... I propose that we integrate this work into our charter and it can then be brought into the W3C Process after being tested here. 08:20:03 q+ 08:20:41 hober: Do you want to bring those two issues: exit criteria and scope, up for discussion now? 08:21:23 https://github.com/w3c/w3process/issues/754#issuecomment-1534260428 08:21:26 ... Straw person: Narrower scope wins, stronger exit criteria wins. 08:22:05 anssik: Example: WebApps WG may have a stricter scope for Geolocation API. 08:22:14 hober: Specifications don't have scope, working groups do. 08:22:53 ... If one WG has a proposal for a spec that is out of scope for the other WG then it can't go into the joint deliverable. 08:24:10 ... That is defined based on the current W3C Process requirements for a Working Group. 08:24:29 anssik, I think the same principle applies for scope as well. 08:25:14 ... For out of scope as well. The narrower scope wins. 08:26:10 plh, It might be defined in the Process but it could be a Guide issue. 08:26:36 hober: (Looks at plh) If only someone in this room could update the guide. 08:27:43 ... Each group is responsible for upholding its own exit criteria. 08:28:06 anssik, To pass the joint deliverable success criteria it must pass both. 08:28:19 hober: If the two group's criteria are in conflict then we do have an issue. 08:29:02 anssik, If one group decides to drop a deliverable, then which success criteria does the remaining group have to satisfy? 08:29:18 hober: Only the criteria of the remaining group, since only one group is chartered to produce the deliverable. 08:33:04 anssik, We will make the decision policies the same if there are different but they appear to be the same between the two proposed charters. 08:33:31 plh, The lesson seems to be that the W3C should not charter WGs with joint deliverables with conflicting success criteria or decisions policies. 08:35:22 hober, the two groups don't need to send CfCs at the same time that's great but it's not required. 08:35:54 ... If one group does not find consensus on an issue while another does then we need to go through the escalation path. 08:37:13 anssik: What follows is that it is undefined what happens if the two WGs, for example: 08:37:13 08:37:13 disagree on whether a proposed new feature is in scope (or out of scope) of a joint deliverable, 08:37:13 disagree on whether the joint deliverable meets (or not) the success criteria for advancement on the Rec Track, 08:37:13 disagree on which decision policy is used for the joint deliverable 08:37:31 ... To conclude I believe we've addressed each of these concerns in this discussion. 08:38:20 plh, If you want to transition to CR then each working group needs to agree to transition to CR and if there are disagreements they need to be resolved before the document can transition to CR. 08:38:33 ... The guide would be a good place for this guidence. 08:38:44 ... I'm documenting this in issue 754 now. 08:39:28 anssik, Do we need to ask for legal advice on the Patent Policies? 08:39:29 https://github.com/w3c/w3process/issues/2 08:39:33 https://github.com/w3c/w3process/issues/754#issuecomment-1719014704 08:41:23 hober: No, the legal issues have been resolved. 08:42:00 plh, I would welcome feedback on this before we submit the charters to the AC. 08:42:30 anssik, Any objections to linking to the guide in the charter? 08:42:36 ... No objections heard. 08:42:52 marcosc: Do we have agreement to submit these charters to the AC? 08:42:53 s/No, the legal issues have been resolved.// 08:43:26 plh, As the next step we need to start horizontal review. 08:43:39 q 08:43:40 q? 08:43:57 RRSAgent, draft minutes 08:43:58 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 08:44:05 q? 08:44:23 https://github.com/w3c/strategy/issues/383 08:44:27 plh, We haven't started horiz review for WebApps either. 08:44:50 s/Topic: Charter updates// 08:44:55 RRSAgent, draft minutes 08:44:57 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 08:45:32 q? 08:45:39 ack rakuco 08:45:40 scheib: The draft charter geolocation entry doesn't seem to be marked as a joint deliverable? https://w3c.github.io/das-charter/das-wg-charter.html#:~:text=An%20API%20for%20obtaining%20geolocation%20reading%20from%20the%20hosting%20device%2C%20based%20on%20the%20Generic%20Sensor%20API 08:45:42 ack charter 08:45:44 charter, you wanted to discuss geolocation? 08:45:50 q- 08:46:04 q+ 08:49:22 q? 08:49:23 ack marcosc 08:49:46 marcosc, I think the Geolocation API should be listed in the normal deliverables section. 08:50:16 anssik, Should we move everything in the maintenance section? 08:50:25 marcosc, Let's make no changes if we don't have to. 08:50:27 anssik, Agreed. 08:50:28 q? 08:50:34 ack rakuco 08:50:53 rakuco, From an editor point of view, what changes should I made when sending a PR? 08:51:12 ... What IPR applies? Should I file two issues? 08:51:29 plh, As a general principle both charters apply, including the Patent Policy. 08:52:47 ... There can't be conflicts in the Patent Policy or Decision Policy because they are the same. 08:52:55 ... If they weren't then those need to be resolved before chartering. 08:53:14 q? 08:53:19 ... If there are conflicts in scope the narrower scope applies. 08:53:46 https://github.com/w3c/w3process/issues/754#issuecomment-1719014704 08:56:25 PROPOSED RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups may proceed to begin horizontal review for their proposed charters. 08:57:48 atsushi, Do we need to do a CfC? 08:57:58 plh, It is immaterial to me. 08:58:37 PROPOSED RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups will proceed to begin horizontal review for their proposed charters. 08:59:09 MC: 👍 08:59:11 RESOLUTION: The proposed update to the Guide resolves the open questions on the joint deliverables process and both Working Groups will proceed to begin horizontal review for their proposed charters. 08:59:56 anssik, We are taking a break for 30 minutes. 09:32:28 simon has joined #dap 09:33:48 mattreynolds has joined #dap 09:38:04 Privacy & Security 09:38:08 s/Privacy & Security// 09:38:11 Topic: Privacy & Security 09:38:23 RRSAgent, draft minutes 09:38:24 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 09:38:50 MarianH has joined #dap 09:41:36 anssik: This WG is chartered to develop secure and privacy-preserving specifications 09:41:45 ... we have a good collaboration going on with TAG and PING on privacy, most recently met with PING to discuss our privacy mitigation success for the Compute Pressure API 09:42:05 ... I want to bring to the WG's attention substantial piece of work, Privacy Principles, delivered by TAG and PING 09:42:09 -> Privacy Principles https://w3ctag.github.io/privacy-principles/ 09:42:22 ... "This document provides definitions for privacy and related concepts that are applicable worldwide as well as a set of privacy principles that should guide the development of the Web as a trustworthy platform." 09:42:48 -> Heads up: Privacy Principles nearing end of wide review https://lists.w3.org/Archives/Member/w3c-ac-forum/2023AprJun/0124.html 09:43:12 -> Principles https://w3ctag.github.io/privacy-principles/#principles-for-privacy-on-the-web 09:43:24 anssik: principles on a topic-level: 09:43:31 ... - Data Minimization 09:43:39 ... - Information access 09:43:51 ... - Consent, Withdrawal of Consent, Opt-Outs, and Objections 09:43:58 ... - Notifications and Interruptions 09:44:10 -> Principles Summary https://w3ctag.github.io/privacy-principles/#bp-summary 09:44:24 anssik: Example of principles we've applied in our work: 09:44:58 ... Data minimization, e.g. https://www.w3.org/TR/compute-pressure/#data-minimization 09:44:58 ... Consent "It should be as easy for a person to check what consent they have given, to withdraw consent" 09:44:58 ... this doc also defines privacy-related concepts that could be referenced by web spec, examples: 09:44:58 -> consent https://w3ctag.github.io/privacy-principles/#dfn-opt-in 09:44:58 -> personal data https://w3ctag.github.io/privacy-principles/#dfn-data 09:45:34 -> identifier https://w3ctag.github.io/privacy-principles/#dfn-identifier 09:45:34 q+ 09:45:34 anssik: this doc is "W3C Group Draft Note" but the intent of this is to become a W3C Statement 09:45:34 q? 09:45:34 ack reillyg 09:45:35 reillyg: I was going to bring this up later in the Geolocation API discussion, but an area where there is possible future work on Geolocation relates to data minimization 09:45:54 ... geolocation works on native platforms as such there's split between coarse and fine-grained geolocation 09:46:12 ... W3C Geolocation API provides highAccuracy flag, but the definition is not clear 09:46:31 ... we don't have a set of incentives for web developers to request coarse geolocation 09:47:17 ... the WG should define the highAccuracy flag properly 09:47:17 ... and incentives to provide to sites to only provide coarse geolocation, to get the data that they need and only that 09:47:50 anssik: any other topics re Privacy and/or Security? 09:48:29 tomayac: it is a really good doc 09:48:32 RRSAgent, draft minutes 09:48:33 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 09:49:11 Topic: Permissions 09:49:11 anssik: I wanted to share the key takeaways from a W3C Workshop on Permissions workshop relevant to this WG. 09:49:11 ... held 5–6 December 2022 at Google Munich office 09:49:43 ... I sat on the Program Committee and felt we had a good discussion, participation from all browser vendors, other key contributors, researchers, but importantly UX/UI design experts 09:49:50 -> Workshop report https://www.w3.org/Privacy/permissions-ws-2022/report 09:50:04 ... Some key takeaways: 09:50:14 ... - significant interest in non-prompt, contextual permission UIs 09:50:31 ... - “user-pull” model instead of the “developer-push” model 09:51:01 ... - User agents could surface additional signals to support informed user choices e.g. purpose declarations by developers 09:51:30 ... - research needed: effectiveness of browser-owned UI that crosses the so-called line of death to mitigate spoofing risks 09:51:57 ... - agreement that getting the UX of permission flows right is a core aspect of making capabilities work well 09:52:33 ... - desire to better incorporate considerations around UX into standardization work 09:53:36 ... API design: tension between being known-use-case driven vs. generic-purpose APIs 09:53:36 RRSAgent, draft minutes 09:53:37 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 09:54:00 anssik: reillyg you want to share something about element? 09:55:16 reillyg: the proposal from penny is a HTML element to combine the current way we suggest developers to implement permission prompts to have a button somewhere to trigger a permission UI 09:55:16 ... web developers can request a permission in response to click, sometimes page load etc. 09:55:49 ... this element creates that UI, a browser controller element 09:56:19 [ mek explaining the UI concept of the element ] 09:56:46 mek: want to mitigation clickjacking 09:57:01 ... if the button moved, it is not clickable for 500 ms 09:57:24 ... if any CSS attributes are manipulated, we also make it unclickable 09:57:31 s/mek/MarianH/ 09:58:00 ... this is desktop only for now, OT late/early next year 09:58:26 ... doing this for gUM first and then Geolocation API 09:59:36 q+ 09:59:36 ... icon is tailored to the capability, implementation-defined icon 09:59:36 ... the button text and icon is provided by the platform, localized 09:59:39 q+ 09:59:52 ... dev trial late Oct, then it is available to play it 09:59:53 q? 10:00:02 ack rakuco 10:00:22 rakuco: is there one button for each permission? 10:00:33 ... one for motion sensor, one for gUM etc.? 10:00:42 mek: that is correct 10:01:12 anssik: bundling and element, are these related? 10:01:23 mek: trying to keep them separate for now 10:02:34 anssik: user studies? 10:02:34 mek: synthetic experiment with Google Meet with good results 10:02:34 q? 10:02:34 ack mattreynolds 10:02:34 atsushi has joined #dap 10:02:34 mattreynolds: this is probably out of scope, in context of device APIs, WebUSB etc. with permission prompts 10:02:36 ... how to support that? 10:02:56 mek: not discussed that yet 10:03:14 s/mek/MarianH/ 10:04:09 ... we're not changing the trusted UI, omnibox and picker hanging off of it stays as is, this button is placed in the center of the screen 10:04:09 q? 10:04:40 anssik: is size and/or position of the button customizable? 10:04:40 q? 10:04:51 mek: little bit of sizing option 10:05:00 s/mek/MarianH/ 10:05:01 anssik: similar ? 10:05:25 q? 10:05:44 MarianH, File picker is our original inspiration for this. 10:05:47 Topic: Test automation 10:06:16 anssik: A session to discuss the WG's approach to test automation using WebDriver and recent progress in this space. 10:06:16 scribe+ 10:07:22 rakuco, The goal is to test the sensor APIs without depending on the presence or behavior of the device's real sensors. 10:08:06 rakuco: We added WebDriver integration to the specification after discussing at TPAC 2018. 10:08:22 ... For various reasons neither an implementation nor WPT updates did not land. 10:08:33 ... Instead the current tests depend on Chrome-specific technology. 10:08:54 ... The tests end up relying on some implementation-specific behavior because of that. 10:09:16 ... This architecture also means that not all of the implementation backend is exercised by the tests. 10:09:34 rakuco: Goals: 10:09:40 ... - Have an implementable spec 10:09:47 ... - Implement the spec 10:10:06 ... - Reduce adoption barriers by having web tests that use the WebDriver endpoints 10:10:20 ... - Make WebDriver available to any other developers writing tests 10:11:20 hober has left #dap 10:11:43 ... - Learn how to do this so we can add WebDriver interfaces to more specs 10:12:03 rakuco: Status: 10:12:24 ... - Specification concepts have been cleaned up. 10:12:35 ... - Main PR is under review. 10:12:40 ... - Implementation is under review. 10:13:10 Present+ Florent_Castelli 10:13:33 Present+ Arnaud_Mandy 10:14:22 rakuco: It is not currently possible to test some cross-origin scenarios because of how set_permission() is defined by test_driver. 10:14:22 Present+ Juha_Vainio 10:14:32 RRSAgent, draft minutes 10:14:33 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 10:16:53 rakuco: There is some overlap with the DeviceOrientation Events spec, but it doesn't define how the API maps to underlying sensors. 10:16:58 q+ 10:17:09 ack reillyg 10:17:56 reillyg: do we think we're able to write implementation tests for DeviceOrientation Events API using this new WebDriver API? 10:18:21 ... maybe we pull in WebDriver stuff into a virtual sensor spec to be referenced by both? Is that the right interface for testing? 10:18:37 rakuco: I don't see why that wouldn't work for the DeviceOrientation Event 10:18:59 ... more of a spec questions, would duplicate a lot of the information we already have for Generic Sensor API 10:20:06 ... from spec editing perspective, WebApps may be inclined to add a dependency to Generic Sensor API for test automation bits 10:20:20 reillyg: proposal to write these WPT tests in terms of WebDriver interface 10:20:37 ... next step for the joint working group tasks is to start the CR process for DeviceOrientation Event 10:20:48 ... includes interop and test coverage work 10:21:29 ... good starting point for discussion with other implementers, others may propose simplification to make it applicable for DeviceOrientation Event but may not work for Generic Sensor-based APIs 10:22:14 ... DeviceMotion is a fusion of accelerometer+gyroscope data, it makes sense considering how this is implemented to make the test API for both these low-level APIs separately and bubble that up 10:22:16 q? 10:23:11 rakuco: from process perspective, if we use the existing tests in WPT, wouldn't that require change to the spec for that first? 10:23:50 reillyg: nothing that says how your tests should work, wide review looks for interop 10:24:18 ... only concern is if interop with other vendors have objections to the WebDriver API shape we use now, probably not a real issue 10:24:26 ... WebDriver is a dependency for the tests 10:24:33 ... it will be interesting 10:24:37 q? 10:27:00 s/mek/MarianH/ 10:27:00 s/mek/MarianH/ 10:27:00 s/mek/MarianH/ 10:27:00 s/mek/MarianH/ 10:27:12 RRSAgent, draft minutes 10:27:13 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html reillyg 10:28:12 q? 10:29:02 Want to extend Web Driver BiDi with https://github.com/w3c/webdriver-bidi/pull/523 10:29:04 vincent: small addition, WebBT has pursued some testing work as well, we want to extend the WebDriver bi-dir spec 10:29:51 ... the need here is a user with WebBT, the user needs to be populated and simulated 10:30:08 reillyg: we're the first WebDriver command that use bi-dir feature 10:30:21 s/WebDriver command/WebDriver extension/ 10:31:20 vincent: proposal is from Bocoup, GH issue mentioned above has the contact 10:31:39 q? 10:32:31 Topic: Generic Sensor API 10:32:55 gb, this is w3c/sensors 10:32:55 anssik, OK. 10:33:04 Subtopic: Modernization 10:33:22 anssik: Raphael is modernizing the spec with the new best practices https://github.com/w3c/sensors/issues/463 10:34:41 rakuco: filed issue #463 based on what I was working on WebDriver and found areas where to modernize things, improve 10:34:41 https://github.com/w3c/sensors/issues/463 -> Issue 463 [Meta] Proof-read and modernize spec (by rakuco) 10:35:30 ... we did wide review for this spec some time ago and wanted to refresh for the best practices, e.g. privacy considerations split from security considerations 10:37:08 anssik: any PRs open? 10:37:08 rakuco: no open PRs to be looked at by the WG 10:37:08 anssik: concrete sensors to be refreshed? 10:38:18 q+ 10:38:18 rakuco: some references could be tweaked a bit, mostly editorial stuff simple to solve 10:38:18 q? 10:38:18 ack reillyg 10:38:50 reillyg: re timeline for wide review, consensus from other implementers is the Generic Sensor API family does not provide adequate value to replace the DeviceOrientation Event so not recommending a complex wide review at this time 10:39:13 ... want to wait on wide review until there's clearer buy-in from other vendors 10:41:34 ... we have a lot of specs on our plate, and asking wide review on many of those at the same time would clog the review pipeline 10:41:41 ... rather, we initiate wide reviews in phases, first with DeviceOrientation Event 10:41:55 ... getting DeviceOrientation Event to Rec would be important step 10:42:13 q? 10:43:38 Subtopic: Factory calibration and fingerprinting 10:43:38 #404 10:43:38 https://github.com/w3c/sensors/issues/404 -> Issue 404 device fingerprinting may also refer to the factory (or other) calibration of the device (by npdoty) [privacy-tracker] 10:43:38 anssik: SensorID paper discusses how factory (or other) calibration of the device could contribute to a device fingerprint 10:43:47 ... I recall SensorID paper was discussed in more detail in https://github.com/w3c/deviceorientation/issues/85 and Maryamm reported "results were unstable" on her fleet of Android devices while an unknown individual reported the fingerprint was "relative stable" on a OnePlus device while "did not work" on Huawei P30 Pro device 10:44:01 ... based on this data we are not clear whether Sensor Calibration Fingerprinting proposed in the SensorID paper is working on current mainstream devices 10:44:35 ... should we cite SensorID paper in the Generic Sensor API as suggested in #404 even if results are not consistent? We could simply add [SENSORID] as a new citation to this existing list in https://www.w3.org/TR/generic-sensor/#device-fingerprinting : 10:44:42 "These manufacturing variations and imperfections can be used to fingerprint the device [ACCELPRINT] [MOBILESENSORS]." 10:45:08 RRSAgent, draft minutes 10:45:09 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 10:45:52 reillyg: we did add a normative requirement to DeviceOrientation Events spec 10:46:30 -> https://github.com/JensenPaul/sensor-fingerprint-mitigation 10:46:31 ... a Chromium developer documented a mitigation and the proposal was to round the values to the nearest 0.5 degrees 10:47:06 -> https://github.com/w3c/deviceorientation/pull/86 10:47:47 reillyg: this change was merged into the DeviceOrientation Event and we merged a mitigation match to Chromium and bugs were opened for Gecko and WebKit and both are still open 10:48:40 ... summary of the current state is, we have specified to mitigations for this issue in DeviceOrientation Events spec, 1st is to have permissions specified, 2nd we have rounding of the values to mitigate against factory calibration to be detected by web sites 10:49:00 anssik: did we port these over to the Generic Sensor-based specs? 10:49:38 reillyg: I think the open issue is to port over to Accelerometer and Gyroscope spec, I believe the Chromium implementation does implement the mitigations defined in DeviceOrientation Events? 10:49:44 alexis_menard has joined #dap 10:49:57 rakuco: I think so, Chromium implementation of Generic Sensor-based APIs is fine and mitigations are in place 10:50:25 ... we have to update the Generic Sensor-based specs similarly to match the implementations 10:51:18 reillyg: I think we want to share the recommended values with DeviceOrientation Event, Orientation Sensor is more complex because we use quartenion 10:52:03 ... what type of rounding is appropriate for quartenion, need to be addressed 10:52:41 ... the other thing, hardware vendors have mitigated this either on HW or OS-level with additional mitigations in place 10:53:06 q+ 10:53:48 proposed RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting 10:53:56 ack rakuco 10:53:56 q? 10:54:29 rakuco: in implementation we do rounding at the Euler angles level 10:54:52 ... there should be rounding on all the levels 10:55:19 reillyg: fusion concept is not fully defined in the spec, in implementation we can have software sensors based on multiple hardware sensors 10:55:35 ... fusion sensors get raw values and individually round the values 10:55:51 ... you get from the platforms these values in Euler angles and then convert to quartenion 10:56:05 ... this conversion is implementation-specific 10:56:14 ... we could add a note "if you convert, please do not round twice" 10:56:44 ... if there's an impact on tests we could be testing our fusion sensors with the infra we're adding 10:56:46 q? 10:58:13 proposed RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting matching existing normative mitigations in the DeviceOrientation Events spec 10:59:04 q? 10:59:05 RESOLUTION: Ensure Generic Sensor-based specs have mitigations normatively defined for factory calibration device fingerprinting matching existing normative mitigations in the DeviceOrientation Events spec 12:12:50 Varun has joined #dap 12:21:22 atsushi has joined #dap 12:23:03 mattreynolds has joined #dap 12:24:09 ryo has joined #dap 12:34:28 Present+ Sangwhan_Moon 12:35:43 Present+ Varun_Singh 12:39:47 Topic: Accelerometer 12:40:05 https://github.com/w3c/accelerometer/issues/54 is derived from https://github.com/w3c/sensors/issues/404 12:40:36 anssik: would it be better to discuss generic types of privacy and security threats in the Generic Sensor API and not duplicate this information to concrete sensor specs? Thoughts? 12:42:19 MarianH has joined #dap 12:42:30 https://w3c.github.io/accelerometer/#security-and-privacy 12:42:38 reillyg: This was discussed previously and we resolved to file and fix this issue across each of the sensor specifications. 12:42:47 We say at the end: "These mitigation strategies complement the generic mitigations defined in the Generic Sensor API [GENERIC-SENSOR]." 12:43:14 reillyg: if we normatively define the mitigations, we have to reference something, either the paper directly or Generic Sensor API section that has the reference 12:44:10 Topic: Gyroscope 12:44:14 anssik: no issues 12:44:19 Topic: Magnetomer 12:44:30 anssik: none issues to discuss 12:44:56 anssik: Web dev req for >>60 Hz sampling 12:45:59 Topic: Orientation Sensor 12:46:10 Head orientation tracking https://github.com/w3c/orientation-sensor/issues/68 12:46:24 anssik: wanted to revisit for new information from an expert in this domain 12:47:02 ... problem statement reads: "one or two companies "define spatial audio" as a proprietary feature instead of releasing tools to let everyone access orientation from devices and handle multichannel audio in a more agnostic fashion" 12:47:41 ... what would be required to pull this off AFAICT would be a HeadOrientationSensor that could be used with the Web Audio API's AudioListener interface https://webaudio.github.io/web-audio-api/#AudioListener for spatialization 12:49:02 ... based on comments it looks like one can already use WebXR to pass head orientation to WebAudio to get VR headsets support spatial audio 12:49:07 ... thoughts? It's been a while since touching this issue, but wanted to do a pulse check 12:49:57 reillyg: WebXR is a better place for these integrations, because you're in XR context so can get higher resolution readings 12:50:48 ... device question is another angle, this is not using laptop or phone, you need a spacial headset, or an XRs-style device 12:51:02 ... thinking this as an audio only XR experience 12:51:39 reillyg: there's opportunity to share the API shape even if it'd be only available in XR context 12:52:39 Topic: DeviceOrientation Events 12:52:47 anssik: WebApps WG https://github.com/w3c/webappswg/wiki/TPAC-2023 was looking at this spec ahead our expected official joint work kick off, topics: 12:52:56 ... - Priv/Sec issues 12:52:56 ... - Spec maintenance 12:52:56 ... - aligning with Permissions spec 12:53:20 reillyg: interest to take this through the Rec Track 12:53:47 ... some of to be addressed issues listed above 12:53:59 s/to be/the to be/ 12:54:17 ... wondering what is the state of the permissions implementation in Chromium 12:55:10 ... requestPermission() method, we didn't implement a prompt, we report the method is used 12:55:10 ... we didn't figure out a way to change this without breaking existing content 12:55:43 ... this is new feature in Safari, we can maybe make a breaking change in Chromium 12:56:01 rakuco: per Chrome Status requestPermission() usage is very low 12:56:14 ... that would raise some feathers? 12:56:34 reillyg: any site that has legit interest in using the API will have migrated to requestPermission() 12:57:05 ... the remaining usage of permission-less is from unsupported use cases such as fingerprinting 12:57:43 ... from spec perspective, we should make Antifraud CG know we're planning to do this change 12:57:49 s/make/let/ 12:59:19 rakuco: if we make this change in Chromium it would mean we'd do this for Generic Sensor-based APIs also 13:00:01 ... Permissions Policy, should we discuss that? WebKit does not implement that spec. 13:01:35 reillyg: Permission Policy checks are implemented in Chromium, not WebKit 13:01:58 ...but WebKit implements permission checks 13:02:46 ... if WebKit does that, it is an area that overlaps with Generic Sensor API, names used by WebKit are from gyro and accelerometer 13:02:52 ... the enum values are shared 13:04:54 =? https://github.com/w3c/deviceorientation/issues/64 13:04:54 gb, this is w3c/deviceorientation 13:04:54 anssik, OK. 13:05:27 rakuco: Permissions API integration is blurry 13:05:30 reillyg: what powerful feature name WebKit uses? 13:05:37 s/powerful/powerful feature 13:05:52 s/powerful feature/powerful 13:07:01 reillyg: we don't need to investigate this at this meeting, we can move toward resolution on the work we want priortize here 13:08:16 ... two spec changes that we want to make are to specify integration with Permissions Policy and replace the bespoke permission concepts from DeviceOrientation Event spec and reference the Permissions API 13:09:58 anssik: we have some PRs that are awaiting joint deliverables being operational 13:11:02 PROPOSED RESOLUTION: Resolve the blockers to beginning the Recommendation process by resolving issue #64 and #70, and work with implementations to resolve interop issues in these areas. 13:11:02 https://github.com/w3c/deviceorientation/issues/64 -> Issue 64 Add integration with Feature Policy (by reillyeon) 13:11:02 https://github.com/w3c/deviceorientation/issues/70 -> Issue 70 Add integration with the Permissions API (by reillyeon) 13:12:29 rakuco: Was there an issue discussing removal of deviceorientationabsolute? 13:13:19 reillyg: after solving the fingerprinting question we are better informed on this issue 13:15:11 ... I'd like to seek input from other implementers if absolute is worth keeping 13:15:43 q? 13:15:47 RESOLUTION: Resolve the blockers to beginning the Recommendation process by resolving issue #64 and #70, and work with implementations to resolve interop issues in these areas. 13:15:56 RRSAgent, draft minutes 13:15:57 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 13:16:32 Topic: Ambient Light Sensor 13:16:42 rakuco: not much progress since last year's TPAC 13:17:02 gb, this is w3c/ambient-light 13:17:03 anssik, OK. 13:17:21 rakuco: This bundling is quite novel and we're not quite sure how to do it. 13:17:33 ... There is also a question of priority. 13:18:06 tomayac: We considered the ALS to be a 1x1 camera. 13:18:22 ... There was no use case which wouldn't be resolved by this model. 13:19:22 rakuco: The initial problem was how do you explain what an ALS is, so the proposal was to integrate it with camera permission. 13:19:36 ... The issue was that the camera capture system is complex. 13:19:58 ... But also if this is combined with a camera can you satisfy these use cases with only the camera and not the ALS. 13:21:11 reillyg: from talking to Invited Expert from last year is, it is valuable to have ALS in addition to camera, can be used to improve camera image with additional information about the surroundings 13:21:38 ... summary, we did not have time to follow through the details of this 13:22:31 Topic: Proximity Sensor 13:23:27 anssik: no issues to discuss 13:24:05 Topic: Geolocation Sensor 13:24:05 gb, this is w3c/geolocation-sensor 13:24:05 anssik, OK. 13:25:39 anssik: a vocal group of web developers has been asking us to do "background geolocation" and or "geofencing" API for many years 13:25:39 ... our standard response has been, it would be easy mechanically to pull those off but there's no consensus on how to do that in a privacy-aware way 13:25:39 ... I understand the frustration of web developers because we've circled around this API for many years 13:25:39 ... Tom formalized the use cases a few years back and we parked them in the Geolocation Sensor spec that is "all things v2 geolocation" 13:25:39 -> Use cases https://w3c.github.io/geolocation-sensor/#use-cases 13:25:39 ... the web developers are mostly asking for these background operations: 13:25:39 - Getting continuous geolocation updates (aka. background geotracking). 13:25:39 - Getting a one-off geolocation fence alert (aka. background geofencing). 13:25:39 reillyg: we are bound by implementers moving together with this 13:26:13 ... background geolocation or geofencing enables interesting use cases 13:26:24 ... Use case contributions since last discussion: 13:26:31 gb, this is w3c/geolocation-sensor 13:26:31 anssik, OK. 13:27:16 - Geolocating sports event competitors #50 13:27:16 https://github.com/w3c/geolocation-sensor/issues/50 -> Issue 50 Use Case: Geolocating sports event competitors in real-time (by fadarnell) 13:27:16 - Taxi ride share https://w3c.github.io/geolocation-sensor/#use-case-ride-share-applications 13:27:20 - Insurance prices and coverage level based on the country https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-580186016 (could be addressed by GeoIP?) 13:27:33 - Notify the driver when arrive at a location https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-819822318 13:27:38 - A bike ride tracking app https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-859977345 13:27:46 - A mountaineering app which keeps track of your movements even while the phone is locked https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-1532185314 13:27:54 - A driver app for a taxi provider https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-1661980346 13:27:58 - Another tax app https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-1699070927 13:28:13 ... Workarounds: 13:28:20 ... - Capacitor web location tracking https://github.com/capacitor-community/background-geolocation/issues/31 13:29:24 RRSAgent, draft minutes 13:29:25 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 13:32:03 ... Proposals: 13:32:33 ... - Simple UX: allow only 1 website to track location in the background with an always-on UI to disable/view status https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-1698979009 13:33:24 ... - Wake Lock + Background Geolocation (@tomayac) https://github.com/w3c/geolocation-sensor/issues/22 and existing UI indicators on mobile https://blog.tomayac.com/2018/12/18/experimenting-with-the-wake-lock-api/#closing-thoughts 13:33:24 https://github.com/tomayac -> @tomayac 13:33:43 RRSAgent, draft minutes 13:33:44 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 13:34:18 q? 13:34:25 Topic: Screen Brightness API 13:34:29 gb, this is WICG/screen-brightness 13:34:29 anssik, OK. 13:34:41 anssik: this API was actively discussed at TPAC 2022, minutes https://www.w3.org/2022/09/15-dap-minutes.html#t20 13:34:57 ... our consensus was to explore a declarative approach for allowing web developers to ask the browser to increase the screen brightness 13:35:03 ... we also received a request from Apple to move this API proposal to WICG to allow Apple contributions, this migration was done: 13:35:13 https://github.com/WICG/screen-brightness/issues/1 13:35:19 anssik: since this WICG migration Apple has been unable to contribute at all 13:35:22 ... this does not need to block our progress on this proposal 13:35:34 ... iProov has been a strong supporter of this feature 13:36:09 reillyg: I think this is a great idea, we just don't have enough bandwidth on the implementation side to look into this 13:36:47 rakuco: I haven't been involved since this moved to WICG, I created the initial explainer and Francois took that work over 13:37:03 ... this originated from WICG, moved to DAS, then back again 13:38:00 [ breaking from 23 minutes until 16:00 ] 13:38:04 s/from/for 13:52:11 MarianH has joined #dap 14:02:03 Topic: Screen Wake Lock API 14:02:49 gb, this is w3c/screen-wake-lock 14:02:49 anssik, OK. 14:03:15 reillyg: not so much to discuss here, Apple filed these issues we listed on the agenda 14:03:26 ... we're awaiting joint deliverables operationalization on these 14:03:38 ... then resolving these is easy 14:04:09 ... #352 is about what names we should use for error conditions 14:04:09 https://github.com/w3c/screen-wake-lock/issues/352 -> Issue 352 Distinguish exceptions on .request() (by marcoscaceres) 14:05:17 ... we think we can resolve this once we get to work on this 14:05:28 reillyg: #350 is more interesting 14:05:29 https://github.com/w3c/screen-wake-lock/issues/350 -> Issue 350 Require transient activation to request lock (by marcoscaceres) 14:06:19 ... I've seen a proposal for sticky activation and it was discussed in WebApps meeting on Monday 14:08:15 ... Chromium has data showing a large number of requests don't have transient activation 14:09:35 s/transient activation/user activation 14:10:48 q? 14:10:57 Topic: System Wake Lock API 14:11:42 reillyg: at TPAC 2022 I noted a proposal how we could support System Wake Lock API 14:12:00 ... the interesting thing is that this proposal would suffice for use cases beyond System Wake Lock 14:12:33 ... the problem we solved with Screen Wake Lock was there are cases where the browser had to keep the screen on, show video or keep WebRTC connection 14:12:44 ... Screen Wake Lock is appropriate for those use cases 14:13:57 ... there are other scenarios where additional hints are necessary for the site to communicate to the browser to understand that the site is doing something that it cares about, and for example, with system wake lock, a long-running compute task needs to not be interrupted 14:14:25 ... but there's no way to tell inappropriate use e.g. a timer that runs on a tight loop from e.g. file upload 14:14:37 ... this applies to both the cases where the site might acquite a system wake lock 14:15:03 applies to site acquires a system wake lock and the site is in the background 14:15:18 reillyg: in the case of background, UAs throttle resource consumption in most cases 14:16:19 ... there is a need for an API where the site can tell the browser I do something the user cares about 14:16:19 ... I don't have folks working on this but there are good use cases, an opportunity for us to look at System Wake Lock in the future 14:16:21 anssik: do you have a customer for this? 14:16:42 reillyg: yes 14:16:56 q? 14:17:58 q? 14:17:58 Topic: Compute Pressure API 14:17:58 gb, this is w3c/compute-pressure 14:17:58 anssik, OK. 14:18:43 s/Topic: Compute Pressure API// 14:20:07 Topic: Contact Picker API 14:20:22 reillyg: not aware of recent work for this API 14:21:46 tomayac: It's implemented in Android and behind a flag on iOS for a long time now. 14:21:53 q? 14:23:12 anssik: nothing more to discuss at this time 14:23:39 Topic: Battery Status API 14:23:44 gb, this is w3c/battery 14:23:44 anssik, OK. 14:23:57 anssik: these was a long-standing feature request by web developers to allow detect power saving mode that gardened substantial support signals https://github.com/w3c/battery/issues/9 14:24:06 ... I drafted an explainer to synthesize the discussion: 14:24:11 -> Energy Saver Mode explainer https://github.com/w3c/battery/blob/gh-pages/energy-saver-mode-explainer.md 14:24:19 ... anssik: Problem: 14:25:01 ... The end user expects modern web applications to use less energy when the OS-level energy saver mode setting is turned on. Web authors have currently no means to apply such optimization on demand informed by this signal because it does not exist. 14:25:13 ... Proposed solution: 14:25:49 ... API to expose the OS-level energy saver mode state and a corresponding signal. 14:25:50 ... This is a read-only boolean, so data minimization principle applies. 14:25:50 ... No way to toggle the power saving mode, only using OS controls. 14:25:54 ... Platform support: 14:26:00 ... - Android isPowerSaveMode boolean 14:26:09 ... - Windows EffectivePowerMode* enum values 14:26:15 ... - macOS and iOS lowPowerModeEnabled boolean 14:26:35 ... Current status: Web developers want this API, minimal privacy impact, implementable on major platforms. 14:26:49 ... Up for grabs? 14:26:56 RRSAgent, draft minutes 14:26:58 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 14:27:37 q? 14:28:06 tomayac: I've seen a "user preference" media feature and "prefers reduced data" 14:29:03 https://github.com/w3c/battery/blob/gh-pages/energy-saver-mode-explainer.md#new-css-media-query-prefers-energy-saving 14:30:14 q? 14:30:47 This could be modeled like `prefers-reduced-energy-consumption` https://drafts.csswg.org/mediaqueries-5/#mf-user-preferences 14:31:08 Topic: Device Posture API 14:31:25 anssik: first Alexis to give us an update on the implementation and the remaining spec work 14:31:33 ... then I'd like to discuss if we're ready to kick off wide review 14:33:06 [ alexis presenting slides ] 14:34:32 alexis: market update on foldable devices, two Samsung phones, Chinese OEMs with foldables, Google Pixel Fold, three new foldables PCs in 22/23 14:36:13 ... fixing usability issues such as seam causing image distortion when placed where the seam is 14:36:17 ... dialogs are hard to interact with when placed at the center of the foldable screen 14:36:25 ... browsers can fix this for build-in dialogs but not for UI frameworks 14:37:13 ... examples clipchamp from Microsoft, web video editor with video placed above the screen seam and controls below 14:37:51 ... split UX for common apps such as email, video streaming service, video games 14:38:16 ... what the browser needs: top segment in px, fold size in px, bottom segment in px 14:39:01 ... non-symmetrical usage where the keyboard slides away 14:39:38 ... Device Posture API in Chromium, partial implementation, Android and Windows backends expected 14:40:21 ... implementation challenges: 14:41:49 - Windows, no Windows OS API, OEMs have a preinstalled software that provides this information 14:43:39 alexis: Android, no Chromium upstream implementation, blocked on androidx.window dependency 14:43:53 s/Android/- Android 14:45:02 RRSAgent, draft minutes 14:45:03 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 14:47:34 alexis: current implementation status, behind a flag in Chrome and Edge on Windows 14:48:01 ... Android implementation 14:48:49 ... CSS media feature and JS API defined in the Device Posture API 14:49:49 ... TAG review completed in 2020, suggest to start wide review to capture wider feedback, e.g. privacy 14:50:47 ... next steps, proposal to move forward in W3C process, WPT, devtools support, some implementation work for fullscreen video player 14:50:49 q? 14:57:24 q? 14:58:18 Dongwoo has joined #dap 14:58:20 scheib has joined #dap 14:58:32 kenneth has joined #dap 14:58:47 rakuco has joined #dap 14:59:01 Josh_Soref has joined #dap 14:59:03 alexis: thanks for the demo! 14:59:03 s/alexis:/anssik:/ 14:59:03 anssik: proposed next step to start wide review 14:59:04 tomayac: cool demo! angles are no longer exposed through the API? 14:59:16 alexis: true, angles removed per TAG feedback abstracted into a set of posture modes 14:59:34 sangwhan has joined #dap 14:59:35 hadleybeeman has joined #dap 15:00:06 tomayac: use case, you see advertisements when on a stadium with perspective correction when the side walls are tilted 15:02:17 reillyg: nothing to add to what Anssi said 15:02:57 ... I think this is ready for wide review, given this exists in Windows and Android ecosystem, we should ask what is Mozilla's position and multi-vendor position 15:03:08 ... if no obvious blockers then we can move forward 15:03:45 ... nothing that prevents Mozilla to implement this API 15:03:49 One use case for fine-grained angles would be perspective correction similar to cam carpets in stadiums (example: https://3dsportsigns.com/wp-content/uploads/2020/06/02-3-moqueta.jpg) 15:04:13 s/... nothing/alexis:/ 15:04:21 reillyg: no standards position filed for Mozilla? 15:04:46 alexis: correct, I'd like to start Origin Trial 15:04:58 reillyg: I'd prefer to ask Mozilla's position now 15:05:33 alexis: Viewport Segment API is complementary so working on that in parallel 15:06:18 reillyg: these reviews are non-blocking can request them in parallel 15:06:49 q? 15:07:19 q? 15:08:17 reillyg: the Chromium fullscreen video issue, you can fix that by CSS 15:09:57 gb, this is w3c/compute-pressure 15:09:57 anssik, OK. 15:12:06 alexis_menard has joined #dap 15:12:06 Topic: Compute Pressure API 15:12:48 Subtopic: Wide review and PING feedback 15:13:40 anssik: wide review #177 has been completed, I'd like to discuss what changed and what we learned 15:13:40 https://github.com/w3c/compute-pressure/issues/177 -> Issue 177 Wide review tracker (by anssiko) 15:13:40 ... for testing the implementation, Chrome Origin Trial is available until 5 Jan 2024 https://developer.chrome.com/origintrials/#/view_trial/1196831600973709313 15:14:21 ... most substantial wide review contributions came from PING and APA WG for privacy and accessibility respectively 15:14:21 ... we had F2F discussion this Tue with PING for privacy and APA for accessibility considerations 15:14:35 ... for privacy we received a contribution for a possible cross-site covert channels attack #197 15:14:36 https://github.com/w3c/compute-pressure/issues/197 -> Issue 197 Feature can be abused to create cross-site covert channels (by pes10k) [privacy-needs-resolution] 15:14:52 ... we addressed this by describing this attack in prose: https://www.w3.org/TR/compute-pressure/#mitigation-strategies 15:15:06 ... and by defining the mitigation normatively, changes summary: https://github.com/w3c/compute-pressure/issues/197#issuecomment-1682242035 15:16:39 kenneth: We went ahead and prototyped the side-channel attack and I have some slides about that. 15:17:05 [ kenneth presenting slides ] 15:17:31 kenneth: Compute Pressure exposes global state and that can be used to create a side-channel. 15:18:00 ... For example a site could artificially create a pattern of compute pressure that is visible to another site and thus communicate a value. 15:19:27 ... We found that there were machines where we couldn't reproduce this, for example if there were background apps. 15:20:18 ... Our demo is not perfectly reliable but it works. 15:21:10 ... We worked with the PING to develop mitigations. 15:22:44 ... We provide additional data at random which breaks the calibration of the attacker. 15:23:18 ... We also manipulate the observation window when we detect that pressure state changes suspiciously frequently. 15:23:30 q+ to ask about how mitigation affects usability after presentation 15:24:16 kenneth: Open question: Should apps be told that the penalty is in place? 15:26:05 q? 15:26:08 ack sangwhan 15:26:08 sangwhan, you wanted to ask about how mitigation affects usability after presentation 15:26:35 sangwhan: Adding mitigations will likely add a tradeoff in the usefulness of the API because we're adding noise. 15:27:21 ... TAG had similar concerns to PING but we dismissed these concerns because there are other ways of observing this side channel. e.g. creating CPU pressure and observing frame times. 15:27:58 kenneth: When experimenting with this we found that it is very noticeable when this is being abused. 15:28:11 ... This really shouldn't be an issue for regular applications. 15:28:14 TAG discussion from the past: https://github.com/w3ctag/meetings/blob/0b1ec03d76fbc614b68d15d2694578bad3b44d40/2023/04-tokyo/minutes.md?plain=1#L30 15:29:01 ... If you want to do this attack and not have anyone notice then you have to do it very slowly. 15:29:19 RRSAgent, draft minutes 15:29:21 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 15:30:04 sangwhan: I'm concerned that we've sacrificed usability for an unnecessary mitigation. 15:30:13 ... Is there a general distaste for permissions here? 15:30:43 kenneth: Conferencing applications already have to ask for a lot of permissions. 15:30:56 sangwhan: You could enable the API with the mitigation when the site doesn't have permissions. 15:31:16 q+ 15:31:33 q+ 15:32:01 Subtopic: Proposed v2 issues 15:32:14 s/Subtopic: Proposed v2 issues// 15:32:15 q? 15:32:19 ack reillyg 15:32:48 reillyg: I think I agree with Sangwhan's perspective 15:33:11 ... now the API is available in OT developers can use it and tell and prove to us it helps them 15:34:33 ack sangwhan 15:34:34 q? 15:35:06 sangwhan: We have two other resources where there would be pressure: memory and storage 15:35:30 ... We should distill best practices from this work to apply to this future work. 15:35:36 q? 15:35:49 Subtopic: Proposed v2 issues 15:35:57 anssik: we have a number of v2 features proposed by the community: 15:36:02 -> Proposed v2 features https://github.com/w3c/compute-pressure/issues?q=is%3Aissue+is%3Aopen+label%3AV2 15:36:16 #228 Catch-all source that considers global thermal and power constraints 15:36:17 https://github.com/w3c/compute-pressure/issues/228 -> Issue 228 Does compute pressure reflect OS-level speed limit changes due to throttling? (by brycepj) [question] [V2] 15:36:24 #211 Automated performance regression testing 15:36:25 https://github.com/w3c/compute-pressure/issues/211 -> Issue 211 Use Case: Automated performance regression testing in Utopia (by Rheeseyb) [V2] 15:36:31 #120 Memory stalls 15:36:32 https://github.com/w3c/compute-pressure/issues/120 -> Issue 120 Use-case: Memory stalls (by kenchris) [V2] 15:36:35 #119 Optimize for long battery life 15:36:36 https://github.com/w3c/compute-pressure/issues/119 -> Issue 119 Use-case: optimize for long battery life (by kenchris) [V2] 15:36:40 #8 Current process contribution 15:36:40 https://github.com/w3c/compute-pressure/issues/8 -> Issue 8 Use-case: Current process contribution (by alexcyn) [V2] 15:36:44 RRSAgent, draft minutes 15:36:46 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 15:39:07 reillyg: Suggestion on #8, a single "it's you" flag when the current document is responsible for > 50% of resource consumption. 15:39:51 q? 15:40:01 ryo has left #dap 15:40:25 Topic: Geolocation API 15:40:29 anssik: WebApps was interested in this proposed joint deliverable, had proposals for: 15:40:44 ... - WebDriver Testing API 15:40:44 ... - toJSON() 15:41:06 reillyg: Geolocation API is a Recommendation 15:41:27 ... I think Geolocation API is relatively good shape 15:41:52 s/is relatively/is in a relatively 15:42:25 reillyg: WebDriver would probably be simple from Chromium implementation perspective 15:43:32 ... another proposal is toJSON() to return a JSON serialization of geoposition 15:44:24 ... also third idea for coarse location option, today we have highAccuracy flag that turns on GPS receiver, in general in native platforms have separate UI permissions for coarse and fine-grained permission 15:44:56 ... we should follow suit there, the challenge is on figuring out the incentives for developers to not to choose the high accuracy geolocation 15:45:26 anssik: Less friction for coarse geolocation could be an incentive. 15:45:42 ... But developers can also already do GeoIP without prompting and that is coarse location. 15:47:08 reillyg: implementations have shipped one-time permission for Geolocation API 15:47:25 ... the most common one-time grant on the platform 15:47:35 RRSAgent, draft minutes 15:47:36 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik 15:47:43 q? 15:47:52 Topic: Wrap up 15:48:02 anssik: Time for synthesis of key outcomes, next steps 15:50:33 RRSAgent, draft minutes 15:50:34 I have made the request to generate https://www.w3.org/2023/09/14-dap-minutes.html anssik