IRC log of dap on 2024-09-24

Timestamps are in UTC.

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