IRC log of dap on 2023-09-14

Timestamps are in UTC.

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