14:59:37 <RRSAgent> RRSAgent has joined #dap
14:59:37 <RRSAgent> logging to https://www.w3.org/2022/09/15-dap-irc
14:59:42 <Zakim> Zakim has joined #dap
14:59:56 <xfq> present+
15:00:01 <xfq> present+ kenneth
15:00:15 <anssik> Zakim, prepare meeting
15:00:15 <Zakim> RRSAgent, make logs Public
15:00:16 <Zakim> please title this meeting ("meeting: ..."), anssik
15:00:21 <anssik> Meeting: Devices and Sensors WG - TPAC 2022 – 15 September 2022
15:00:26 <anssik> Chair: Anssi, Reilly
15:00:31 <anssik> Agenda: https://github.com/w3c/devicesensors-wg/issues/56
15:00:35 <anssik> Scribe: Anssi
15:00:39 <anssik> scribeNick: anssik
15:00:46 <anssik> scribe+ Reilly
15:00:51 <anssik> scribe+ fxq
15:01:08 <ghurlbot> ghurlbot has joined #dap
15:02:34 <amandy> cannot join zoom either
15:02:46 <amandy> An error occurred. Sorry, the page you are looking for is currently unavailable. Please try again later.
15:03:42 <xfq> scribe- fxq
15:03:45 <xfq> scribe+ xfq
15:03:49 <tomayac> present+
15:03:57 <anssik> RRSAgent, draft minutes
15:03:59 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
15:04:13 <bneedham> bneedham has joined #dap
15:04:21 <bneedham> present+
15:04:53 <plh> plh has joined #dap
15:04:57 <reillyg> present+
15:05:22 <plh> present+
15:06:58 <scheib> present+
15:07:00 <anssik> RRSAgent, draft minutes
15:07:00 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
15:07:01 <kenneth> present+
15:07:47 <reillyg> scribe+
15:12:40 <willmorgan> HTTP 502 for me
15:12:50 <amandy> same here
15:12:50 <anssik> Present+ Anssi_Kostiainen
15:13:36 <willmorgan> ah, I am not chair, I am human
15:15:15 <tomayac> Devices and Sensors
15:15:15 <tomayac> Thursday, September 15 · 08:00 – 08:30
15:15:15 <tomayac> Google Meet joining info
15:15:15 <tomayac> Video call link: https://meet.google.com/ask-qtia-hdg
15:15:16 <tomayac> Or dial: ‪(CA) +1 437-781-4585‬ PIN: ‪595 646 086 5026‬#
15:15:16 <tomayac> More phone numbers: https://tel.meet/ask-qtia-hdg?pin=5956460865026
15:15:46 <cmartin> cmartin has joined #dap
15:16:27 <anssik> anssik has changed the topic to: if Zoom is down for you, please join Google Meet https://meet.google.com/ask-qtia-hdg
15:18:23 <alexis_menard> alexis_menard has joined #dap
15:19:24 <amandy> present+
15:19:29 <rakuco> present+
15:19:36 <willmorgan> present+
15:19:41 <fbeaufort> present+
15:19:43 <alexis_menard> present+
15:20:06 <cmartin> present+
15:22:02 <anssik> Topic: Welcome
15:22:07 <anssik> ghurlbot, this is w3c/devicesensors-wg
15:22:07 <ghurlbot> anssik, OK
15:22:12 <anssik> anssik: Welcome to the Devices and Sensors WG TPAC 2022 meeting
15:22:32 <anssik> ... a few practical things:
15:22:37 <anssik> -> Health rules https://www.w3.org/2022/09/TPAC/health.html
15:22:41 <anssik> -> Code of Ethics and Professional Conduct https://www.w3.org/Consortium/cepc/
15:22:53 <anssik> ... To speak up we use a queue on IRC: q+, q-
15:23:05 <anssik> ... See also TPAC 2022 site for the latest information
15:23:09 <anssik> -> W3C TPAC 2022 https://www.w3.org/2022/09/TPAC/
15:23:25 <anssik> Subtopic: Intros
15:23:36 <anssik> anssik: Anssi Kostiainen, DAS WG co-chair, Intel
15:24:40 <fbeaufort> FYI mit.zoom.us seems to be back.
15:25:45 <anssik> join Zoom https://mit.zoom.us/j/95200652562?pwd=dTE4NVRsN3dqV0ovRUh5S0FZa05mQT09
15:26:48 <bneedham> trying to reset my camera from switching
15:27:00 <anssik> Thomas Steiner, Google DevDel, Project Fugu
15:27:01 <scheib> Vincent Scheib from Google, working on Capabilities / Fugu ... device APIs, installable desktop PWAs, supporting web audio
15:27:43 <plh> plh has changed the topic to: 
15:27:49 <anssik> Reilly Grant, WG co-chair, TL for Device APIs team and ??? at Google
15:28:19 <anssik> Philippe Le Hageret, PM of W3C
15:28:21 <cmartin> Chris Martin from Mozilla -- Device Interfaces and low-level OS integration for Windows (only here as an observer)
15:28:33 <reillyg> s/???/Isolated Web Apps/
15:30:10 <anssik> Ralph Swick W3C
15:30:32 <anssik> Arno Mandy, Intel, Generic Sensors, Compute Pressure implementation in Chromium
15:30:45 <plh> s/Hageret/Hegaret/
15:30:53 <anssik> Bradley Needham, Sony Playstation, extension to  Gamepad spec and impl for DS4
15:31:12 <anssik> Francois Beaufort, Google DevRel, love Device API and guitars!!
15:31:25 <anssik> Fuqiao Xue: W3C Staff contact for this WG
15:31:37 <anssik> Kenneth Christiansen: Web Platform team Intel, working on Compute Pressure
15:31:59 <anssik> Raphael Kubo da Costa, Intel, Screen Wake Lock, Sensors, Compute Pressure, janitor of old specs in this WG
15:32:24 <anssik> Will Morgan, head of web innocation iProov, Screen brightness work is our interest, also ALS, Generic Sensor work
15:32:40 <anssik> Alexis Menard, Intel, involved with Device Posture API mostly
15:33:01 <anssik> Topic: Charter update
15:33:06 <anssik> Subtopic: Update on the proposed charter in review
15:33:17 <anssik> -> Status of Formal Objections (Member-only) https://www.w3.org/Member/wiki/DirectorFOdashboard
15:33:46 <anssik> anssik: I invited plh to give us an update on the FO
15:34:05 <anssik> ... we're switching TBL out from the process, so some pains there
15:34:12 <xfq_> xfq_ has joined #dap
15:34:56 <anssik> [plh shares the FO planning document]
15:36:28 <anssik> plh: I've been working on the report prepared for DAS to be sent to the AB+TAG Council
15:36:42 <anssik> ... you're the first people to see it
15:37:42 <anssik> ... FO from Mozilla, sent to public record also
15:38:25 <anssik> ... two disagreements about 1) existing deliverables 2) new deliverables
15:39:06 <anssik> RRSAgent, draft minutes
15:39:06 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
15:44:37 <anssik> q?
15:44:39 <reillyg> q+
15:45:28 <rakuco> q+
15:45:56 <plh> q+ to ask about TAG reviews
15:46:59 <anssik> q?
15:47:04 <anssik> ack plh
15:47:04 <Zakim> plh, you wanted to ask about TAG reviews
15:47:15 <plh> https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Venue%3A+Devices+%26+Sensors+WG%22+
15:48:29 <anssik> https://github.com/w3ctag/design-reviews/issues/207
15:48:41 <anssik> https://github.com/w3ctag/design-reviews/issues/115
15:48:54 <anssik> https://github.com/w3ctag/design-reviews/issues/110
15:49:46 <anssik> q?
15:49:48 <anssik> ack reillyg
15:50:27 <anssik> reillyg: I want to mention that in the previous meeting we agreed on a plan to review those APIs that have most implementer interest
15:50:36 <anssik> ... this includes Geolocation API that went to Rec recently
15:51:07 <anssik> ... I'm proposing we should perhaps next ask TAG review the DeviceOrientation API
15:51:36 <anssik> ... we should be careful in asking reviews, ask reviews one by one
15:51:46 <anssik> q?
15:52:02 <anssik> plh: it is important to fill in the report with this new information
15:52:18 <anssik> ... some people will be coming from outside the WG and lock the context
15:52:41 <anssik> q?
15:52:46 <anssik> ack rakuco
15:53:05 <anssik> rakuco: questions about TAG reviews, should they be requested periodically?
15:53:28 <anssik> plh: back in Dec 2020 Council asked the WG to do TAG reviews, that we need to answers
15:53:49 <anssik> rakuco: looking at the doc, not clear what chairs vs. regular contributors should do?
15:54:01 <anssik> ... we need to make sure the history of the WG is well captured
15:54:05 <anssik> q?
15:54:22 <anssik> ... the doc will be presented to individuals who have not followed the work
15:54:45 <anssik> tomayac: does demonstrated user demand help here?
15:55:03 <anssik> plh: deployed and shipped?
15:55:18 <willmorgan> +q
15:55:25 <anssik> ... you're welcome to write that [in the report?]
15:55:58 <anssik> willmorgan: I'm in a position to deploy an app that is reaching millions of users a week
15:56:15 <anssik> ... using ALS, Device Orientation, Screen Brightness
15:56:45 <anssik> ... if you look for concrete implementation, my company and a number of other companies would be willing to go on record on our usage
15:57:10 <anssik> plh: no need to make a case for the use case
15:57:33 <anssik> willmorgan: is these what else could be lacking except TAG review?
15:57:44 <anssik> s/what/anything
15:58:25 <anssik> plh: are we solving the problems the right way?
15:59:53 <anssik> tomayac: as Anssi pointed our, Screen Brightness is trending in WebKit positions, use case being validated by a number of vendors
16:00:22 <anssik> ... there have been several proposals for this particular API, when is the right moment to do a TAG review?
16:00:23 <anssik> q?
16:00:23 <willmorgan> As an example for screen brightness, DAS went to TC39 and CSS WG to ensure that we're actually solving the use case in the best way. We also have multiple current and ex members of TAG. So when is the right moment for TAG review? Probably when there is enough consensus in and out of the the DAS WG?
16:00:25 <willmorgan> -q
16:00:40 <anssik> q- willmorgan
16:01:09 <anssik> RRSAgent, draft minutes
16:01:09 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
16:03:06 <anssik> q?
16:03:55 <anssik> Subtopic: 2023-2024 scope discussion, Low level Device APIs breakout session
16:04:10 <anssik> anssik: our current charter ends 2022-11-30
16:04:25 <anssik> ... so regardless of the Formal Objection status we must recharter again for the next two-year period 2022-12-01 - 2024-11-30
16:04:35 <anssik> plh: or short extension
16:04:48 <anssik> anssik: as usual, we review the device APIs landscape for promising new incubations
16:04:53 <anssik> -> [DRAFT] Devices and Sensors Working Group Charter https://w3c.github.io/dap-charter/DASCharter-2021.html
16:05:10 <anssik> anssik: we collect feedback for charter through the GH repo
16:05:15 <anssik> -> DAS WG Charter GH issues https://github.com/w3c/dap-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
16:05:22 <anssik> ... looking at the issue from most recently updated first
16:05:28 <anssik> ... it is suggested the Compute Pressure API scope to be adjusted based on feedback from user's, to explicitly add in scope "v2 use cases"
16:05:39 <anssik> -> Compute Pressure API v2 use cases https://github.com/WICG/compute-pressure/issues?q=is%3Aissue+is%3Aopen+label%3AV2
16:05:52 <anssik> -> DAS WG Charter: Compute Pressure API https://github.com/w3c/dap-charter/issues/111
16:06:04 <anssik> q?
16:06:13 <reillyg> q+
16:06:20 <reillyg> ack reillyg
16:06:21 <anssik> ack reillyg
16:06:28 <zkis> zkis has joined #dap
16:07:04 <anssik> reillyg: maybe it is worth discussing the contrary option, we have a process in W3C to incubate in WICG
16:07:21 <anssik> present+ zkis
16:07:54 <anssik> reillyg: looking at new work, should we consider the Council's recommendations, being more critical of the scope
16:08:33 <anssik> ... waiting for multi-implementer interest before expanding the scope
16:09:33 <anssik> ... ability of the WG to advance its specs is hindered by other implementer's unwillingness to contribute to the WG
16:09:35 <anssik> q?
16:11:51 <anssik> anssik: this WG is following the W3C Process and that doc does not require multi-implementer commitment for WG to take on new work
16:12:03 <anssik> plh: this is a hard issue
16:12:26 <plh> --> https://www.w3.org/2022/09/14-iii-minutes.html III breakout minutes
16:14:20 <anssik> RRSAgent, draft minutes
16:14:20 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
16:15:02 <anssik> reillyg: I want to understand what is needed to help people join us
16:15:32 <anssik> scheib: people have different motivations, but we're practical about it, if ppl don't want to collaborate we still want to solve the problems people have
16:16:01 <anssik> ... incubation is healthy, we shouldn't be too attached where the work happens
16:16:03 <anssik> q?
16:16:26 <anssik> scheib: willmorgan wants to see a solution in place and make progress on it
16:16:32 <anssik> q?
16:16:44 <anssik> plh: W3C Process is here to validate your work
16:16:54 <anssik> ... in an ideal world there would be no process
16:17:03 <xfq> xfq has joined #dap
16:17:16 <anssik> ... the process is to say, this is how we validate the work: horizontal review, TAG review etc.
16:17:34 <anssik> ... you can do that outside the W3C Process of course
16:17:59 <willmorgan> q
16:18:04 <willmorgan> q+
16:18:22 <anssik> scheib: W3C is facilitating the work
16:18:40 <anssik> plh: that is perfectly fine, I want to make sure you make the right decision
16:20:11 <Dongwoo> Dongwoo has joined #dap
16:20:21 <weiler> present+
16:20:30 <tomayac> q?
16:20:34 <anssik> q?
16:21:12 <willmorgan> q-
16:21:26 <anssik> ack willmorgan
16:22:00 <anssik> willmorgan: on getting other implementers on board, I don't have interest in philosophy of each implementer
16:22:02 <tomayac> q+
16:22:14 <anssik> ... this is the only group where philosophical differences are noticeable
16:22:28 <anssik> ... I'm curious where people think the web should be going
16:22:39 <anssik> ... toward a platform capable of doing many things?
16:23:23 <anssik> ... there's a clear generic use case, sometimes you need to do powerful things but don't want to download an app, and DAS WG covers that use case, this is important
16:24:13 <rakuco> q+ diego_on_zoom
16:24:21 <willmorgan> sorry - do not mean to stall progress
16:24:31 <anssik> q?
16:24:47 <anssik> ack diego_on_zoom
16:25:19 <anssik> diego: this reminds me of a discussion with some Samsung folks, Device Posture API
16:25:48 <anssik> ... we had two workstreams, Intel enabling the API on Windows, and Samsung working on Android
16:26:15 <anssik> ... the questions was, are these two implementations sufficiently different to consider two implementations?
16:26:28 <anssik> ... codebases for different platforms might be considered different implementations
16:26:30 <anssik> q?
16:28:19 <diekus> diekus has joined #dap
16:28:28 <diekus> present+
16:28:43 <anssik> anssik: this is a great perspective, I've also raised this, also another datapoint is the shared WebRTC library across all major implementations
16:28:46 <anssik> q?
16:29:11 <anssik> reillyg: I'm leaning towards keeping the scope as is
16:29:14 <anssik> q?
16:29:23 <tomayac> q-
16:29:48 <plh> [thanks to the Working Group]
16:30:04 <anssik> Topic: Privacy & Security
16:32:18 <anssik> Sam: you're doing great! Appreciate your contributions and collaboration
16:32:31 <anssik> ... device discovery is one generic privacy issue
16:32:43 <anssik> ... having a device available adds one bit of entropy
16:32:51 <anssik> ... you know about specific vulnerabilities
16:33:03 <rakuco> q+ to talk about my impressions
16:33:08 <anssik> ... working relationship with you is great, my colleagues feel the same
16:33:09 <reillyg> q+
16:33:10 <anssik> q?
16:33:14 <zkis> q?
16:33:22 <anssik> anssik: thanks Sam for your kind words!
16:34:06 <anssik> q?
16:34:28 <anssik> Sam: sometimes we're [PING] not great in other things that "here's the whole doc review"
16:35:02 <anssik> ack rakuco
16:35:03 <Zakim> rakuco, you wanted to talk about my impressions
16:35:23 <anssik> rakuco: I've been landing and/or reviewing PRs to some of our specs since last year's TPAC
16:35:32 <anssik> ... Generic Sensor, ALS, Battery
16:35:51 <anssik> ... I think my main take away is that privacy work is harder than implementing them
16:36:03 <anssik> ... folks have less time for privacy patch review
16:36:14 <anssik> ... I've learned best practices on the go reading PING documentation
16:36:28 <anssik> ... in general making focus improvements is easier
16:36:44 <anssik> ... I'm not sure how wide reviews for our specs would entail
16:37:08 <anssik> ... some involving permissions is hard to reach consensus on, when we touch upper layers of the implementation (UI/UX?)
16:37:21 <anssik> ... what criteria to use to make a decision on those issues
16:37:54 <anssik> ... sometimes PING guidance is not always clear, I couldn't find a source how to calculate the entropy mentioned in some of the docs
16:38:19 <anssik> ... also ephemeral fingerprinting did not have a good reference, there was a 2-year old repo for that
16:38:45 <anssik> ... looking ahead, what we could do to improve the process, speed it up, should we redo questionnaires?
16:39:01 <anssik> Sam: we pay a lot of attention to device discovery due to fingerprinting concerns
16:39:29 <anssik> ... look at ways of shifting device picking into the browser, if the user needs to select something delegate that to the browser (UI)
16:39:30 <anssik> q?
16:40:04 <anssik> Sam: note what we are opening up, a lot of this is domain-specific so you're the experts
16:40:21 <anssik> ... when and how I make this available
16:40:30 <anssik> q?
16:40:33 <anssik> ack reillyg
16:40:34 <alexis_menard> q+
16:40:53 <anssik> reillyg: my question ducktails on the ephemeral fingerprinting
16:41:46 <anssik> ... the sensor issues around accuracy and attach based on sensor data, there's a fundamental issue: a device does or not have a gyroscope/hw capability
16:42:02 <weiler> q+ re: permissions workshop December 5-6, Munich
16:42:04 <anssik> ... in the audio space, we have path forward to avoiding more bits
16:42:24 <anssik> ... at some point you get down to a boolean question like sensor availability
16:42:39 <anssik> ... what is the model for providing that type of information
16:42:48 <anssik> ... there bits add up
16:43:26 <anssik> q?
16:43:55 <anssik> Sam: example from audio, explaining sample rate of devices, there was no pattern for this
16:44:59 <anssik> ... specialized hardware that use unusual sampling rate, do not expose that information
16:45:45 <anssik> ... how can we make all the devices look the same even when they are not?
16:46:15 <anssik> tomayac: that makes some use cases complicated? e.g. I'm telling I'm a 4K camera, even if I'm not
16:46:24 <anssik> Sam: we want the default to look the same
16:46:27 <anssik> q++
16:46:36 <anssik> q- +
16:48:12 <rakuco> q+
16:48:27 <anssik> q?
16:48:41 <anssik> anssik: we use static defaults for Battery Status API
16:48:56 <plh> plh has left #dap
16:49:23 <anssik> q?
16:49:38 <anssik> ack alexis_menard
16:49:40 <msw> msw has joined #dap
16:50:06 <anssik> alexis_menard: you may not have 3 gyros in your device, in foldables there actually are multiple gyros
16:50:10 <willmorgan> q+
16:50:49 <anssik> ... I'm not sure if fake gyro works
16:51:42 <anssik> q?
16:51:44 <rakuco> q-
16:51:44 <anssik> ack weiler
16:51:45 <Zakim> weiler, you wanted to discuss permissions workshop December 5-6, Munich
16:52:03 <anssik> weiler: there's a Permissions workshop in Munich in December 2022
16:52:14 <anssik> ... mark your calendars DAS WG participants
16:52:16 <willmorgan> count me in...
16:52:31 <weiler> https://github.com/w3c/strategy/issues/348
16:52:57 <rakuco> q+
16:53:01 <anssik> q?
16:53:08 <anssik> ack willmorgan
16:53:35 <weiler> s/a Permissions/likely to be a Permissions/
16:53:38 <anssik> willmorgan: if we were to start providing fuzzy info for gyros it might break a lot of existing stuff
16:53:39 <anssik> q?
16:54:23 <anssik> anssik: we don't want to break backwards compat
16:54:24 <anssik> q?
16:54:27 <willmorgan> q-
16:54:53 <anssik> ack rakuco
16:55:11 <anssik> rakuco: I'm trying to think of a concrete example on what Sam proposed
16:55:28 <anssik> ... if we call Accelerometer.start() it'll fail with a specific error when there's no accelerometer
16:55:41 <anssik> ... so given the PING guidance, we wouldn't return anything at all?
16:55:56 <anssik> Sam: we'd want to return the same error if there's no accelerometer or no permission to use it
16:56:34 <anssik> reillyg: in the current model, WebKit is the only engine that implements permissions for DeviceOrientation
16:57:48 <anssik> ... there were two options: "denied" & "provide no data" or provide low resolution data
16:58:12 <anssik> q?
16:58:50 <rakuco> q+
16:59:13 <anssik> q?
16:59:32 <anssik> q?
16:59:34 <anssik> ack rakuco
17:00:00 <anssik> rakuco: wanted to clarify Generic Sensors example: would it be better to provide fake data for accelerometer that does not exists or throw an error?
17:00:13 <zkis> q?
17:00:16 <anssik> Sam: no guideline, need to be figured on on a use case basis
17:00:17 <anssik> q?
17:00:35 <willmorgan> I think absent accelerometer returns as 0, 0, 0 in motion events
17:00:43 <anssik> reillyg: if we could fake data when no permissions are available, once granted
17:00:51 <anssik> ... would we also want to provide fingerprinting protection
17:01:31 <anssik> Sam: I'd say look at layers, there are things you can do, even if you grant permissions you can get sample rates (in Web Audio API)
17:02:01 <anssik> ... we can't sample everyone, but we can constrain this much
17:02:10 <anssik> q?
17:02:51 <fbeaufort> Marcos is in the Immersive Group right now and will attend the TPAC Devices and Sensors WG meeting after lunch. He asks me if we can move "Screen Wake Lock API" item so that he can be there.
17:02:53 <anssik> Sam: even if the user has granted permission, minimize fingerprint still consistent with the environment and use case
17:06:41 <weiler> q+
17:06:53 <anssik> q?
17:07:15 <weiler> ack me
17:07:39 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html xfq
17:30:33 <anssik> RRSAgent, draft minutes
17:30:33 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
17:30:41 <jsbell> jsbell has joined #dap
17:30:46 <jsbell> present+
17:32:14 <anssik> Topic: Sensor Framework
17:34:18 <anssik> ghurlbot, this is w3c/sensors
17:34:18 <ghurlbot> anssik, OK
17:34:46 <anssik> #429
17:34:46 <ghurlbot> https://github.com/w3c/sensors/issues/429 -> Pull Request 429 [closed] Declare quantization and threshold check algorithms for extension to the spec (rakuco)
17:35:46 <anssik> anssik: related to the previous discussions, quantization and threshold check algorithms for Generic Sensor API received PING review and finally landed after an extensive 6 month review
17:36:10 <anssik> rakuco: good news here, after a lot of work this has landed
17:36:38 <mattreynolds_> mattreynolds_ has joined #dap
17:36:55 <anssik> ... our ALS implementation in Chrome had some issues and we implemented mitigations, then also brought those changes to the spec so other implementers can benefit from them
17:37:14 <anssik> ... reviewed with PING and Lukasz, IE in this WG and author of paper describing the attack we mitigate against with this PR
17:37:16 <anssik> q?
17:37:31 <anssik> ... as for next steps, we could extend this for rounding for motion sensors we do in Chrome
17:37:49 <anssik> ... we do rounding for most sensors, but only spec it in ALS spec
17:38:10 <anssik> reillyg: we do that in Device Orientation spec, but did not bring those mitigation back into the spec
17:42:26 <anssik> anssik: any concerns?
17:42:32 <anssik> [no concerns]
17:42:37 <anssik> RESOLUTION: Incorporate quantization measures from Device Orientation into motion sensor specs (accelerometer, gyroscope, device orientation)
17:42:52 <willmorgan> willmorgan has joined #dap
17:42:59 <anssik> RRSAgent, draft minutes
17:42:59 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
17:43:55 <anssik> anssik: no other bugs for the Generic Sensor API, we're doing great it seems!
17:45:19 <anssik> RRSAgent, draft minutes
17:45:19 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
17:45:42 <anssik> Topic: Motion Sensors
17:46:19 <anssik> anssik: For completeness, this agenda enumerates all the WG's deliverables, including tentative ones.
17:46:19 <anssik> 
17:46:19 <anssik> ... I want to check if anyone is aware of issues we should discuss for any of the Motion Sensors marked with "none". "None" indicates no issues proposed to the F2F agenda currently.
17:46:33 <anssik> anssik: anything we missed in GH bug triage?
17:47:22 <anssik> reillyg: checked Chrome metrics for these, the Sensor APIs we shipped are duplicates of Device Orientation because they provide a better API for developers, allow configurability and modern API  surface
17:47:39 <anssik> ... most usage is on old Device Orientation, likely due to the fact developers use what works across browsers
17:48:38 <kenneth> https://www.npmjs.com/package/motion-sensors-polyfill
17:48:50 <kenneth> 579 weekly downloads
17:48:58 <anssik> anssik: the polyfill could help raise awareness among developers
17:49:11 <kenneth> https://www.npmjs.com/package/urlpattern-polyfill <- 100k downloads per week!
17:49:20 <kenneth> to compare with another polyfill
17:50:05 <anssik> kenneth: when I talk to web developers, many don't know these features are available
17:50:32 <anssik> reillyg: something I've been thinking recently, I feel there used to be a lot more interest in Sensor APIs when XR/AR used sensors a lot
17:50:57 <anssik> ... it feels like WebXR has moved to its own API from the polyfill
17:51:02 <anssik> q?
17:51:41 <anssik> q+ willmorgan
17:51:43 <hakan_> hakan_ has joined #dap
17:52:35 <anssik> tomayac: dated spec URLs were an issue, now web.dev has a landing page for Generic Sensors
17:52:37 <anssik> q?
17:52:59 <anssik> q?
17:53:04 <anssik> ack willmorgan
17:53:43 <anssik> willmorgan: from an implementer's PoV, I'm aware this is changing, why we haven't migrated yet is it is literally just easier to deal with the old events listening on windows
17:53:46 <anssik> s/windows/window
17:54:17 <anssik> willmorgan: if the polyfill could make the usage easier with permissions then it'd be ideal
17:54:31 <kenneth> we accept patches to the polyfill :-) I will gladly review
17:55:03 <anssik> RRSAgent, draft minutes
17:55:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
17:55:13 <willmorgan> q-
17:56:22 <anssik> q?
17:56:27 <willmorgan> I will pass this through to the dev working on this at the mo, thanks Kenneth!
17:56:42 <anssik> Subtopic: Accelerometer
17:56:47 <anssik> [no f2f issues]
17:56:51 <anssik> Subtopic: Gyroscope
17:56:54 <anssik> [no f2f issues]
17:56:58 <anssik> Subtopic: Magnetometer
17:57:03 <anssik> [no f2f issues]
17:57:08 <anssik> Subtopic: Orientation Sensor
17:57:11 <anssik> [no f2f issues]
17:57:15 <anssik> Subtopic: Device Orientation
17:57:18 <anssik> ghurlbot, this is w3c/deviceorientation
17:57:18 <ghurlbot> anssik, OK
17:57:23 <anssik> #88
17:57:24 <ghurlbot> https://github.com/w3c/deviceorientation/issues/88 -> Pull Request 88 Drop duplicate PermissionState definition (foolip)
17:57:45 <anssik> anssik: Drop duplicate PermissionState definition PR has been open for long so I put it on the agenda to see if we can nudge it forward
17:57:49 <anssik> ... the concrete spec change is small, removes:
17:57:56 <anssik> enum PermissionState {
17:57:56 <anssik>     "granted",
17:57:56 <anssik>     "denied",
17:57:56 <anssik> };
17:58:01 <rakuco> q+
17:58:07 <anssik> anssik: but the devil is in the details, who wants to take a stab at the status?
17:58:09 <anssik> q?
17:58:12 <anssik> ack rakuco
17:58:34 <anssik> rakuco: IIRC, the more general problem is this API does not integrate with the permission spec
17:58:58 <anssik> ... we duplicate some Permissions spec text in Device Orientation
17:59:06 <anssik> ... not sure if removing this would break WebKit
17:59:15 <anssik> ... need to think of powerful feature names
17:59:48 <anssik> ... WebKit checks these strings "accelerometer", "gyroscope", and "magnetometer" for Permission Policy
17:59:50 <willmorgan> q+
17:59:58 <anssik> q?
18:00:08 <anssik> s/Permission Policy/Permission Policys
18:00:16 <anssik> s/Permission Policys/Permissions Policy
18:00:30 <anssik> q?
18:00:32 <anssik> ack willmorgan
18:00:55 <anssik> willmorgan: just to confirm, the permissions policy gives the JS code within an origin a permission to request a permission from the user?
18:01:08 <anssik> ... if you don't have it on your permissions policy, any calls will fulfill with denied?
18:01:26 <anssik> ... for context, this causes problems for shipping code for people who iframe your apps
18:01:37 <anssik> ... that's my 2cent, it's confusing
18:01:40 <anssik> q?
18:01:41 <rakuco> q+
18:01:51 <anssik> reillyg: the error message should be different
18:01:57 <anssik> ... not allowed error
18:02:20 <anssik> ... this is a bit separate, confusingly, permissions policy and permissions are unrelated features, not integrated at all
18:02:30 <anssik> ... we should eventually resolve this issue
18:02:54 <willmorgan> sorry!!!
18:03:30 <anssik> ... originally named as "Feature Policy", then renamed and split into two "Permissions Policy" and "Document Policy"
18:04:05 <anssik> reillyg: the theory was, the things in FP that were features "how should this HTML work with X" would go to Document Policy
18:04:12 <anssik> ... things related to permissions go to Permissions Policy
18:04:40 <anssik> q?
18:04:50 <anssik> ack rakuco
18:05:08 <anssik> reillyg: I think that we should eventually fully integrate with the Permissions spec
18:05:15 <anssik> ... similarly to what Generic Sensor API does
18:05:37 <anssik> ... for this issue #88 the only issue is the algorithms text still referred to an enum value that was no longer defined
18:05:37 <ghurlbot> https://github.com/w3c/deviceorientation/issues/88 -> Pull Request 88 Drop duplicate PermissionState definition (foolip)
18:05:48 <anssik> ... we should refer to the Permissions spec enum value instead
18:05:53 <anssik> q?
18:06:12 <anssik> rakuco: I haven't look at this in a while
18:07:11 <anssik> RRSAgent, draft minutes
18:07:11 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
18:08:02 <anssik> reillyg: if we just integrate with Permissions spec, would we break WebKit?
18:08:16 <anssik> s/reillyg: if/rakuco: if
18:08:30 <anssik> reillyg: next topic is how to take this to Rec
18:09:44 <anssik> reillyg: the API returns a custom enum for backwards compat (with WebKit) reasons
18:10:44 <anssik> anssik: was this a namespace clash issue?
18:11:29 <anssik> reillyg: correct, we could have a mapping table from what is shipping in WebKit to Permissions spec enum values
18:11:39 <anssik> rakuco: was there a behaviour difference too?
18:12:14 <anssik> reillyg: algorithm seems like the same
18:13:10 <anssik> anssik: do we need to ask WebKit implementation to change?
18:13:30 <anssik> rakuco: it's not possible to return default, but default does not act like prompt exactly
18:14:09 <anssik> reillyg: the issue is in Permissions spec integration in many places, for user gesture concept, many specs need some custom steps
18:14:31 <anssik> ... including Generic Sensor API with custom user activation check in place
18:14:42 <anssik> ... we should upstream it to Permissions API but that is not a blocker IMO
18:15:39 <anssik> reillyg: maybe rakuco will take a look, and we try to land this at the earliest opportunity
18:17:40 <ghurlbot> https://github.com/w3c/deviceorientation/issues/88 -> Pull Request 88 Drop duplicate PermissionState definition (foolip)
18:18:35 <anssik> RESOLUTION: take another look at issue #88 Drop duplicate PermissionState definition and provide feedback on what still needs to be done to land
18:19:01 <anssik> reillyg: Now that the Geolocation API has reached Recommendation status should we start the process of doing the same for this specification?
18:19:46 <anssik> ... we care about spec maintenance, so I'd propose the next legacy API is Device Orientation to move to CR and toward Rec
18:20:00 <anssik> ... request TAG review and other horizontal reviews
18:20:06 <anssik> q?
18:20:26 <anssik> reillyg: privacy mitigation done, would be great to get that stamped
18:21:14 <anssik> anssik: I agree, do we have an explainer for this API that is a requirement for Device Orientation?
18:21:41 <anssik> reillyg: I think an extensive introduction can almost serve as an explainer
18:21:54 <anssik> ... pull text from intro to an explainer?
18:22:14 <rakuco> q+
18:22:35 <anssik> ack rakuco
18:22:59 <anssik> anssik: any concerns with the WG starting to move Device Orientation toward CR and Rec?
18:26:39 <anssik> rakuco: couple of questions about the spec itself
18:26:40 <anssik> ?
18:26:45 <scheib> q+
18:27:31 <anssik> rakuco: w-p-t, a lot of test for Device Orientation spec but many of those only pass in Chrome
18:27:44 <anssik> anssik: what is missing in other engines?
18:27:57 <anssik> rakuco: they don't implement the same mocks?
18:28:52 <anssik> rakuco: optimally, we'd use WebDriver so other engines could interop, now we rely on JS mocks in Blink
18:29:08 <anssik> reillyg: similar concern raised for Geolocation
18:29:31 <anssik> ... Chrome DevTools can fake Geolocation, there is no similar support for DeviceOrientation
18:29:40 <anssik> ... we have WebDriver spec'd but not implemented
18:30:43 <anssik> ... it'd be reasonable to say, we need to figure out multi-implementer i) permissions and ii) automated testing approach, not rely on manual testing
18:31:14 <anssik> q?
18:31:21 <anssik> ack scheib
18:32:00 <anssik> scheib: Device Orientation, I read the introduction section to size it how good an explainer text this is -- it's primarily missing the "why"
18:32:08 <anssik> ... it simply states what it is, now "why" it is
18:32:24 <anssik> ... maybe not a blocker, but would probably get friction if this was a new proposal
18:32:53 <anssik> ... second point, we have a superior modern API based on Generic Sensor API, but we want to take the old API to Rec?
18:33:10 <anssik> ... how much energy we want to put on the old spec or simply say it is the new one we want to proceed with?
18:33:40 <anssik> reillyg: this is why we did the Geolocation API Rec, we need to recognize we're maintaining old legacy specs that are being used
18:34:00 <anssik> ... we're not adding new features, but we need to integrate with permissions if that is what developers need
18:34:50 <scheib> Links:
18:34:51 <scheib> https://w3c.github.io/deviceorientation/spec-source-orientation.html
18:34:59 <scheib> https://www.w3.org/TR/generic-sensor
18:35:03 <scheib> https://www.w3.org/TR/orientation-sensor/
18:35:12 <anssik> https://w3c.github.io/orientation-sensor/#intro
18:36:09 <anssik> scheib: I see a component missing, why do we need orientation at all?
18:36:17 <scheib> use cases in https://w3c.github.io/motion-sensors/#usecases-and-requirements
18:36:19 <anssik> https://w3c.github.io/motion-sensors/
18:36:57 <msw> +q
18:37:03 <anssik> q?
18:37:19 <willmorgan> iProov is using it for liveness detection as well
18:37:43 <anssik> scheib: I still think we're insufficiently motivating the problem, more and more W3C tries to work with other implementers, explain the problem first, then propose the solution
18:37:55 <anssik> ... this should be explained in the explainer document
18:39:36 <anssik> reillyg: in addition to the immersive experiences and gaming use cases, we should acknowledge a lot of these use cases are motivated by fraud detection
18:39:59 <anssik> willmorgan: we'd look to use the sensors with trust tokens
18:41:09 <anssik> willmorgan: how long sensors are granted, if the use case does not need them more than for a minute, that is one possible privacy issue mitigation
18:42:47 <anssik> scheib: proposal to clean up the old spec and direct to the new spec for introduction and motivation, driving to the modern API
18:47:39 <anssik> RESOLUTION: Start advancing the DeviceOrientation Event spec toward Rec, produce an explainer, and evaluate areas of concern prior to wide review
18:47:43 <anssik> q?
18:47:53 <anssik> ack msw
18:48:28 <anssik> msw: I found the Device Orientation spec when I was looking at Screen Orientation spec that exposes an angle attribute
18:48:55 <anssik> ... that is inaccurate, presumably done to workaround the new spec, that should be the lightly lit path for anyone using the screen orientation angle
18:49:11 <anssik> reillyg: the description is inaccurate?
18:49:32 <anssik> msw: what I've seen from the wpt, implementation are unreliable
18:50:03 <anssik> anssik: Screen Orientation exposes type of orientation, discreet states
18:50:16 <anssik> msw: it also exposes a numeric angle
18:50:30 <anssik> ... Device Orientation would be a replacement for the numeric angle?
18:51:19 <anssik> reillyg: difference between Screen Orientation and Device Orientation: Screen exposes the landscape, portrait etc. orientation, similar to Device Posture
18:51:26 <anssik> ... semantics vs. physical
18:52:18 <anssik> q?
18:55:09 <msw> sorry for raising a topic from a place of ignorance! :-/
19:19:42 <hjrchung_> hjrchung_ has joined #dap
19:31:12 <anssik> RRSAgent, draft minutes
19:31:12 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
19:34:13 <larsgk> larsgk has joined #dap
19:34:34 <jsbell> jsbell has joined #dap
19:41:57 <hjrchung> hjrchung has joined #dap
19:42:19 <anssik> Topic: Device Capabilities
19:42:27 <anssik> Subtopic: Battery Status API
19:42:40 <anssik> ghurlbot, this is w3c/battery
19:42:40 <ghurlbot> anssik, OK
19:42:46 <anssik> #52
19:42:47 <ghurlbot> https://github.com/w3c/battery/issues/52 -> Issue 52 Explore a high-level API (anssiko)
19:43:08 <anssik> anssik: Chris Palmer provided a number of good use cases for a high-level API in a crbug https://bugs.chromium.org/p/chromium/issues/detail?id=661792#c49
19:43:25 <anssik> ... summarizing: "I believe these valid use-cases can be satisfied with `onlowpower` and maybe `onfullpower` events, rather than the current API."
19:43:30 <anssik> anssik: Francois has produced an elegant high-level API polyfill in 8 lines of JS
19:43:53 <anssik> ... my question is do folks like this high-level API? any obvious issues?
19:44:12 <anssik> ... and if so, do we have a good migration path for the existing API to the new API?
19:44:54 <anssik> ... the implementations of the existing API could aggressively round the readouts to simulate the high-level API already today, report two discrete values e.g. 0.09 and 1.0 mapping to "lowpower" and "fullpower"
19:45:36 <anssik> q?
19:45:44 <reillyg> q+
19:45:46 <Dongwoo> present+
19:45:49 <anssik> q?
19:46:19 <anssik> tomayac: for native apps, power saving mode kicks in at some point and otherwise apps don't care
19:46:40 <hjrchung> present+
19:46:50 <msw> present +
19:46:52 <anssik> q?
19:47:01 <anssik> q+ msw
19:47:10 <msw> q-
19:47:29 <anssik> kenneth, there's an issue for that https://github.com/w3c/battery/issues/9
19:47:54 <jsbell> q+
19:48:02 <anssik> reillyg: I think the battery saving mode idea is that it shifts the power mgmt policy, e.g. timer behaviour, it forces apps to use less power
19:48:12 <anssik> tomayac: does it disable bg sync?
19:48:15 <anssik> reillyg: yes
19:48:30 <anssik> ... I'd like to understand the existing use cases of the battery status API?
19:48:44 <anssik> use cases in https://bugs.chromium.org/p/chromium/issues/detail?id=661792#c49
19:49:00 <rakuco> q+
19:49:41 <anssik> reillyg: those are good use cases, I'd like to see that real sites are using the API this way
19:50:24 <anssik> ... we should look at other platforms for examples of apps that adjust their behavior based on battery status level
19:50:53 <anssik> ... we talked to YT embed, they were using this API to switch to a lower resolution video format
19:51:04 <anssik> scheib: there's a lot of usage for this API
19:51:17 <anssik> reillyg: similar to device orientation and motion
19:51:36 <anssik> scheib: on Chrome this is 10% of page loads
19:51:41 <scheib> https://chromestatus.com/metrics/feature/timeline/popularity/2198 10% of page loads
19:51:53 <anssik> tomayac: YT is using this API
19:53:53 <anssik> reillyg: I like the "lowbattery" proposal
19:54:03 <kenneth> constrained battery :-)
19:54:13 <anssik> q?
19:54:27 <reillyg> q-
19:54:29 <kenneth> I would like my webapps to preserve battery when I manually put on battery saver mode
19:54:30 <anssik> ack jsbell
19:55:33 <anssik> jsbell: regarding high-level API, we'd love if another implementer goes first
19:55:52 <anssik> q?
19:55:55 <anssik> ack rakuco
19:56:52 <anssik> rakuco: I was also part of this investigation, to see if we can stop exposing BatteryStatus in secure context, there were various usages in https websites but did not see sites changing their behaviour
19:57:14 <anssik> ... could these be signals in Compute Pressure API?
19:58:21 <rakuco> s/https/http/
19:59:22 <anssik> anssik: it would help us make a decision on this API and the proposed high-level API if we'd know what the usage is now
20:00:17 <anssik> q?
20:00:38 <anssik> #54
20:00:39 <ghurlbot> https://github.com/w3c/battery/issues/54 -> Issue 54 Use of "current global object" is confusing (Ms2ger)
20:01:18 <anssik> q?
20:05:02 <willmorgan> q+
20:05:33 <anssik> RRSAgent, draft minutes
20:05:33 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
20:07:16 <anssik> willmorgan: if OS is throttling would be useful to know
20:07:51 <anssik> anssik: there's Compute Pressure API for OS throttling related use cases
20:08:08 <willmorgan> q-
20:08:40 <reillyg> RESOLUTION: Understand the use cases behind current usage of the API, and if compelling, seek positions from other implementers for interest for the high-level Battery proposal
20:08:47 <anssik> RRSAgent, draft minutes
20:08:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
20:09:21 <anssik> Subtopic: Device Posture API
20:09:25 <anssik> ghurlbot, this is w3c/device-posture
20:09:25 <ghurlbot> anssik, OK
20:09:33 <anssik> #100
20:09:34 <ghurlbot> https://github.com/w3c/device-posture/issues/100 -> Pull Request 100 Remove Folded Over from Device Posture (supo2co)
20:09:49 <anssik> anssik: proposal to remove "tent-mode" motivated by experiences from the WindowManager Jetpack library for Android
20:09:55 <anssik> https://developer.android.com/reference/androidx/window/layout/package-summary
20:10:23 <anssik> alexis_menard: they removed "folded over posture"
20:10:42 <anssik> ... to do content side-by-side with other content needs this
20:11:01 <anssik> ... we have devices with foldable screens that can do 360
20:11:19 <anssik> ... not against removing, we can add in the future
20:11:31 <anssik> kenneth: if no implementation, agree to remove
20:12:08 <anssik> s/"tent-mode"/"folded-over"
20:12:19 <anssik> q?
20:12:37 <anssik> Dongwoo: I'm from Samsung, worked with Diago when he worked on this API
20:12:53 <anssik> ... Samsung also does not have "folded the other way" devices
20:13:03 <anssik> ... Huawei has some devices that fold like that
20:13:33 <anssik> ... "folded" and "continuous" is enough for our purposes
20:13:54 <reillyg> q+
20:13:56 <anssik> q?
20:13:58 <anssik> ack reillyg
20:14:28 <anssik> reillyg: "folded-over" posture, are there not devices that support that posture?
20:14:42 <anssik> ... Android removed it because foldable OLEDs do not support that
20:15:49 <anssik> alexis_menard: technically the devices can support "folded-over" posture but there's no platform API to get this information on Windows
20:16:12 <anssik> q?
20:18:41 <anssik> q?
20:19:14 <anssik> Dongwoo: is there any plan from different browser vendors to support this API?
20:19:53 <anssik> ... Samsung supports this API and why try to connect service providers to use this API, e.g. in developer conference next month we do a presentation with one of our partners to show live web page using this API and Viewport Media Query
20:19:56 <anssik> q?
20:20:53 <anssik> q?
20:21:35 <anssik> alexis_menard: Chromium does not depend on JetPack library
20:22:01 <anssik> ... on Windows side, there's no official API for posture information, the best is hinge angle from the SDK
20:22:47 <anssik> q?
20:23:24 <anssik> alexis_menard: two 2nd gen new foldable devices coming to the market, this is public information, getting this API working would be great
20:24:13 <anssik> Chris_Martin: there's a lot of entropy in the previous iteration of the API
20:25:03 <anssik> alexis_menard: we have mitigated fingerprinting satisfactorily in the latest API by reduced entropy
20:25:46 <anssik> Chris_Martin: is cross-tab correlation possible?
20:26:13 <anssik> reillyg: exposed to visible content only as a mitigation
20:26:46 <anssik> alexis_menard: we don't give info how big the fold angle is, it is "folded" or "not folder", minimizing the fingerprinting concern
20:27:13 <anssik> ... only visible and in focus pages get these events
20:27:44 <anssik> RESOLUTION: Remove "Folded Over" posture from Device Posture API due to platform API limitations
20:27:50 <anssik> q?
20:28:45 <anssik> Topic: Environment Sensors
20:29:07 <anssik> Subtopic: Ambient Light Sensor
20:29:32 <anssik> ghurlbot, this is w3c/ambient-light
20:29:32 <ghurlbot> anssik, OK
20:29:40 <anssik> #77
20:29:41 <ghurlbot> https://github.com/w3c/ambient-light/issues/77 -> Pull Request 77 [closed] editorial: Add reading quantization and threshold check algorithms. (rakuco)
20:30:07 <anssik> rakuco: we're working on wpt tests for these changes
20:30:16 <anssik> #79
20:30:17 <ghurlbot> https://github.com/w3c/ambient-light/issues/79 -> Issue 79 Add camera permission requirement to spec? (rakuco)
20:30:40 <anssik> rakuco: last year we discussed this and made a resolution to add camera permission to ALS spec
20:31:06 <anssik> ... some time passed and I looked at this and had questions and was not sure how to do this if we decide to do this
20:32:11 <anssik> reillyg: to summarize, ALS is in front of the phone to detect the ambient light, used by camera to also measure ambient light for better exposure adjustment, also used for iProov use case how light is reflected off of environment to understand if the person is real
20:32:31 <anssik> ... ALS exposes information about the user's environment, so concerns over side channel attacks
20:32:42 <anssik> ... this is different from motion sensors
20:33:05 <anssik> ... use cases involve camera with ALS, so proposal was to grant ALS access if camera has already access
20:33:18 <anssik> ALS is in practice a camera with a resolution of 1x1 pixels :)
20:33:28 <anssik> s/ALS is in/... ALS is in
20:34:39 <anssik> rakuco: the problem is how do you prompt the user for access if they don't know what light sensor is
20:34:43 <larsgk> q+
20:34:57 <anssik> reillyg: apps could have asked for camera access already
20:35:06 <willmorgan> q+
20:35:14 <anssik> rakuco: some concerns may be UA concerns, and we try to solve this on a spec level
20:35:45 <anssik> ... my concern is if we risk changing the constraints in the getUserMedia, how to integrate with media capture permission management
20:36:29 <anssik> ... hypothetical device with camera and not ALS
20:36:35 <anssik> q?
20:36:43 <anssik> ack larsgk
20:37:25 <anssik> larsgk: there was a case at Maersk, we wanted to use this on a vessel, for day, night, dusk, in this case tying to a camera permission makes no sense
20:37:41 <anssik> in that environment granting access to camera is not appropriate
20:38:23 <anssik> q?
20:38:26 <anssik> ack willmorgan
20:38:44 <anssik> willmorgan: side channel is mitigated by quantization and rounding?
20:39:49 <willmorgan> q+
20:39:57 <anssik> reillyg: good questions, I don't recall what the states reason was for moving motions sensors from being granted by default and say ALS would be OK
20:41:03 <anssik> Chris_Martin: trying to the camera permission is a good approach, but has few failure scenarios: site that only wants ALS, but not camera
20:41:38 <anssik> ... WebXR has a similar approach with its depth map vs. regular camera permission
20:41:54 <anssik> ... do users understand what ALS means, use cases are specialized
20:42:36 <anssik> ... I like bundling permissions
20:43:15 <anssik> reillyg: explaining sensors is difficult, we say "Detect the motion of your device" rather than "Access sensors"
20:43:47 <anssik> willmorgan: in my use where it is bundling powerful browser APIs, we may be asking ALS depending on how it is implemented
20:44:27 <anssik> ... easier to have context where we see permissions going from WebAppSec WG, are they allowing more of bundling permissions, otherwise we end up doing weird things like bundling with camera
20:44:44 <anssik> ... you may need a virtual video device to make this  happen
20:45:01 <anssik> ... I'd be happy if we piggy-pack on the camera permission and tolerate we cannot go the other way around
20:45:38 <fbeaufort> FYI Marcos is coming in 15mins
20:45:58 <anssik> reillyg: in spec discussion we identified ALS with its own permission request method, requesting a camera permission
20:47:05 <anssik> q?
20:47:09 <anssik> q+
20:47:10 <willmorgan> q-
20:47:33 <anssik> q?
20:47:35 <anssik> ack anssik
20:47:45 <reillyg> scribe+
20:47:55 <tomayac> scribe+
20:49:31 <reillyg> s/Chris_Martin/Theodore_Olsauskas-Warren/
20:49:53 <anssik> FTR: Chris_Martin in above ALS discussion is Theodore_Olsauskas-Warren
20:51:09 <anssik> reillyg: it looks like the proposal to integrate with camera permission is the most appropriate approach
20:51:43 <tomayac> rakuco: Should we still require camera permission?
20:51:49 <tomayac> ... or just assume it's there?
20:52:18 <anssik> RRSAgent, draft minutes
20:52:18 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
20:52:26 <tomayac> reillyg: It would be better to request, because that avoids the situation that Theodore_Olsauskas-Warren mentioned
20:52:43 <tomayac> rakuco: Should ALS be listed in media enumeration?
20:53:02 <tomayac> reillyg: If we're only requiring it, then it would not appear
20:53:26 <tomayac> willmorgan: Firefox will prompt you for the device. If you only have one, not sure what happens.
20:53:36 <tomayac> reillyg: What would happen if it requested camera?
20:53:48 <tomayac> willmorgan: It would probably be not that bad
20:54:02 <tomayac> ... You could customize the text or display a dropdown
20:54:17 <tomayac> rakuco: Should stopping the camera stop the ALS?
20:54:35 <tomayac> reillyg: It should stop the indicator and activate it like the camera does.
20:54:49 <tomayac> willmorgan: If you close the media stream, does that stop the sensor>
20:54:56 <tomayac> s/sensor>/sensor?
20:55:22 <lauram> lauram has joined #dap
20:55:24 <tomayac> ... Is there a mechanism within the existing API to stop the feed without the developer explicitly asking to stop?
20:55:36 <tomayac> reillyg: We could throw an exception "camera ended"
20:55:48 <tomayac> ... This would tie them even closer together.
20:56:04 <tomayac> willmorgan: It would probably be cleaner to just drop this off.
20:56:20 <tomayac> ... You would stop the media stream together.
20:57:20 <tomayac> rakuco: Should we only tie the permissions together, or tie the sensor to a stream? Would there be a way to only have the indicator, without the actual camera being on?
20:57:37 <tomayac> reillyg: It makes sense from a user perspective
20:57:57 <tomayac> ... It would make it so the physical indicator would be in sync with the ALS
20:58:06 <anssik> Present+ Will_Morgan, Raphael_Kubo_da_Costa, Alvin_Ji, Arno_Mandy, Bradley_Needham, Francois_Beaufort, Hakan_Isbiliroglu, Jack_Hsiesh, Jimmy_Huang, Kenneth_Christiansen, Lars_Knudsen, Laura_Morinigo, Matt_Reynolds, Zoltan_Kis, Philippe Le Hégaret, Fuqiao_Xue
20:58:09 <anssik> RRSAgent, draft minutes
20:58:09 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
20:58:14 <tomayac> Theodore_Olsauskas-Warren: Are there a lot of use cases that only require ALS?
20:58:25 <larsgk> q+
20:58:44 <anssik> Present+ Theodore_Olsauskas-Warren
20:58:58 <tomayac> ... Or are the use cases very specific, and operators on a ship for example can understand that it's not really the camera
20:59:10 <tomayac> reillyg: Seems reasonable to request camera and ALS together
20:59:20 <tomayac> Theodore_Olsauskas-Warren: Does this affect the use cases?
20:59:52 <tomayac> reillyg: Every device that has fulfills the use cases also has a camera. Maybe old laptops to activate the keyboard lights.
21:00:00 <tomayac> willmorgan: We would not bother to ask.
21:00:02 <rakuco> q+
21:00:12 <anssik> ack larsgk
21:00:28 <tomayac> larsgk: I would get this through if it were easier.
21:00:35 <tomayac> ... What about a car dashboard?
21:00:44 <tomayac> ... Could there be a media query instead?
21:00:51 <tomayac> ... Maybe car dashboards?
21:01:03 <tomayac> ... With maybe two or three coarse values?
21:01:27 <anssik> https://www.w3.org/TR/ambient-light/#scope
21:01:31 <tomayac> reillyg: Similar to light mode dark mode, a media query for ambient light might be useful, albeit we haven't seen it
21:01:47 <anssik> q+
21:01:48 <anssik> q?
21:01:49 <tomayac> Theodore_Olsauskas-Warren: Is this for regular browsers, or special environments?
21:02:06 <tomayac> larsgk: Google Maps switches when you go in a tunnel
21:02:22 <anssik> q?
21:02:22 <tomayac> reillyg: Talking with delivery drivers, we know that this exists
21:03:00 <anssik> ack anssik
21:03:13 <tomayac> anssik: You can follow up in the issue discussion if you're interested
21:03:25 <tomayac> ... I might be wrong, but I think it was hard to reach interop
21:03:45 <tomayac> anssik: I believe it was hard to define what dusk etc. means
21:03:49 <tomayac> q?
21:04:16 <tomayac> rakuco: There used to be a light level media query, but it was dropped.
21:04:26 <tomayac> ... Because it could achieve the same as prefers-contrast
21:04:52 <tomayac> ... We seem to tie ALS and camera close together
21:05:27 <tomayac> willmorgan: I have to check the thread, but it was long and caused me to flipflop my own opinion.
21:05:44 <tomayac> ... I'll be talking about providing a media stream of a 1x1 pixel camera
21:05:53 <tomayac> rakuco: This is what we proposed
21:06:11 <tomayac> willmorgan: I don't know enough about the inner workings of an ALS
21:06:35 <tomayac> willmorgan: I can't think of a use case where you would want this
21:06:45 <tomayac> reillyg: The units would be different
21:07:06 <tomayac> ... An ALS provides a more calibrated light level in lumens, so the camera can be calibrated
21:07:45 <tomayac> rakuco: We would need to turn a camera on to get a media stream
21:07:48 <reillyg>  /me PROPOSED RESOLUTION: Prepare a specification proposal for coupling the ALS to an active media stream rather than camera permission.
21:08:10 <reillyg> RESOLUTION: Prepare a specification proposal for coupling the ALS to an active media stream rather than camera permission.
21:08:35 <tomayac> rakuco: Would this be basically creating a new stream or track?
21:08:58 <tomayac> reillyg: The existing stream doesn't make sense for the format. It would need to be a special track
21:09:05 <anssik> Present+ Marcos_Cáceres
21:09:13 <tomayac> willmorgan: We would need to tie it to an active media stream
21:09:29 <tomayac> rakuco: ALS would not be creating this stream, just be attached to it.
21:10:17 <tomayac> tomayac: If there's no camera, you cannot engage this stream, right?
21:10:30 <tomayac> willmorgan: You can create a virtual camera in such cases. Horrible, but works.
21:10:37 <anssik> Topic: Device Capabilities (cont'd)
21:10:40 <anssik> Subtopic: Screen Brightness API
21:10:47 <anssik> ghurlbot, this is w3c/screen-wake-lock
21:10:47 <ghurlbot> anssik, OK
21:12:47 <tomayac> reillyg: Screen brightness, we have the brightness mode explaienr
21:12:57 <tomayac> ... And we opened a standards position thread
21:13:06 <tomayac> ... Which elicited some interesting feedback
21:13:11 <Marcosc> Marcosc has joined #dap
21:13:15 <willmorgan> https://github.com/w3c/screen-wake-lock/blob/gh-pages/brightness-mode-explainer.md
21:13:15 <tomayac> s/explaienr/explainer
21:13:18 <Marcosc> present+
21:13:30 <tomayac> reillyg: Let's reaffirm the use cases we're trying to resolve
21:14:08 <tomayac> ... As I understand it: the generic use case is the one where the developer wants to make a section or the entire screen brighter, so a QR code could be read
21:14:16 <tomayac> .... We proposed a couple of actions
21:14:36 <tomayac> .... Either an explicit brightness API, or as a part of the fullscreen API
21:14:43 <tomayac> .... Or a declarative API
21:15:02 <tomayac> ... The user agent can then decide whether it wants to adhere or not
21:15:10 <tomayac> ... The use case is still scanning
21:15:22 <tomayac> ... Are there concerns about the use cases per se?
21:16:18 <tomayac> Marcosc: If we disassociate the use cases from the API shape, both on iOS and Android, you're either using the app, or iOS Wallet
21:16:52 <tomayac> reillyg: Interesting that it only boosts the brightness of the code
21:17:18 <tomayac> Marcosc: At least on the Apple side, we have a system component for doing this
21:17:37 <tomayac> ... If you want to have a boarding pass, you download it
21:17:46 <tomayac> reillyg: Is there an open standard?
21:17:53 <tomayac> Marcosc: No, but there is a format
21:18:15 <reillyg> q?
21:18:16 <tomayac> ... This tech exists, and this is what Apple does today
21:18:52 <tomayac> ... For the authentication case, I did see the Australian government thing with the flashing and all.
21:19:10 <tomayac> ... It's not about web authentication as an API, only about the use case
21:19:14 <willmorgan> q+
21:19:20 <rakuco> q-
21:19:32 <tomayac> ... Brightness helps, but more sophisticated sensor on an iPhone exist. Like Face ID.
21:20:08 <tomayac> ... Taking a step back. Let's find an existing usable thing, maybe at the OS level
21:20:31 <tomayac> reillyg: My understanding is that this is not something that could be delegated to the OS
21:20:43 <tomayac> ... Face ID is not solving the usecase of iProof
21:20:51 <tomayac> s/iProof/iProov
21:21:22 <tomayac> willmorgan: A couple of points on QR codes. Web Authn is brilliant, however, it ties the authentication to a device
21:21:37 <tomayac> ... I have two laptops, but I can only bind one security key to a device
21:22:07 <tomayac> ... The second issue is how do I establish trust in a device, before I bind the device
21:22:59 <tomayac> ... It's funny that you mention Face ID. Getting access to that sensor would be brilliant. Or to infrared cameras.
21:23:15 <tomayac> ... Using some of the same sensors the OS is using would be great
21:23:39 <tomayac> ... For now, my use case is a complement to WebAuthn
21:23:55 <tomayac> ... We (iProov) encourage WebAuthn
21:24:14 <tomayac> ... WebAuthn is not a replacement
21:24:40 <tomayac> ... For QR stuff, I have passes, but I don't want an app for that
21:24:55 <tomayac> ... I feel like Wallet doesn't completely replace the QR code case
21:25:17 <tomayac> Marcosc: I live close to a post office, having the QR code a click away from the SMS for example is usefuk
21:25:23 <tomayac> ]s/usefuk/useful
21:25:34 <reillyg> q?
21:25:39 <willmorgan> q-
21:25:39 <reillyg> ack willmorgan
21:26:35 <tomayac> reillyg: It seemed like the direction from Apple was more to declaratively solve this, like with CSS
21:26:56 <tomayac> ... You could mark a region and say in CSS that this needs boosting
21:27:18 <tomayac> ... How would the user agent react to this. It gives the user agent a lot of latitude
21:27:24 <anssik> RRSAgent, draft minutes
21:27:24 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
21:27:41 <tomayac> ... The user agent can detect if there's really a QR code, and if so, boost it
21:28:02 <tomayac> ... It's in the pattern to give the user agent more information about what is on the page
21:28:11 <tomayac> Marcosc: Reiterating what you're saying
21:28:46 <tomayac> ... You scroll down, and author says this is brightable, the user agent could then verify it is a QR code, and then boost the region
21:29:12 <tomayac> ... This would solve the Wikipedia article case, since the regions would not be marked as boosted
21:29:27 <tomayac> reillyg: The iProov use case would be solved by this
21:29:55 <tomayac> ... This would improve upon the status quo where the user has to be told to open quick settings
21:30:13 <tomayac> ... I think making that declarative is more manageable, since the user agent would have more context
21:30:21 <tomayac> Marcosc: And it doesn't leak information
21:30:32 <tomayac> reillyg: Counters abuse
21:31:05 <tomayac> ... What the WG should do is to focus the conversation on the declarative proposal
21:31:13 <tomayac> ... and see what CSS WG think about it
21:31:28 <tomayac> Marcosc: It could be an element attribute as well
21:31:40 <fbeaufort> q+
21:31:51 <tomayac> reillyg: We would then bring this back to the WebKit repo
21:31:56 <reillyg> ack fbeaufort
21:31:59 <reillyg> q+ scheib
21:32:17 <tomayac> fbeaufort: How is this different from the fullscreen proposal?
21:32:27 <tomayac> Marcosc: They are not mutually exclusive
21:32:41 <tomayac> ... You might still go fullscreen and request boosted brightness
21:33:07 <tomayac> ... It could be paired with fullscreen, like when you hand over a movie ticket
21:33:50 <tomayac> Marcosc: We haven't solved the way how to get out of fullscreen, which is why we haven't done it on Safari
21:34:04 <tomayac> Marcosc: Fullscreen comes with nice things
21:34:48 <tomayac> reillyg: I don't think we need both, but including brightness in fullscreen makes sense.
21:35:31 <tomayac> willmorgan: iPadOS does support fullscreen, iOS doesn't
21:35:50 <tomayac> ... Going back to the fullscreen API, this would help my use case
21:36:08 <reillyg> ack scheib
21:36:33 <tomayac> scheib: Are the nuances of the use cases communicated correctly to Marcosc?
21:36:53 <tomayac> ... Most of what I heard was focused on the QR code use case.
21:37:15 <tomayac> Marcosc: We're discussing this actively
21:38:18 <tomayac> willmorgan: It's a complicated thing. What we're trying to prove is that the thing we're pointing the camera at is 3D.
21:38:35 <tomayac> Marcosc: Is this about making sure it's the same person?
21:39:02 <tomayac> willmorgan: Feature matching is one thing we do.
21:39:31 <tomayac> Marcosc: If you had the assurance of the infrared sensor, this would work
21:40:13 <tomayac> willmorgan: We're currently using depth data
21:40:32 <tomayac> willmorgan: I know on Surface laptops you can get access to infrared cameras
21:40:42 <tomayac> ... This is not about fingerprinting users
21:41:16 <tomayac> Marcosc: What if we had a "compare A to B" service?
21:41:41 <tomayac> ... So that the matching would be done on the device
21:42:03 <tomayac> willmorgan: Maybe. It would be only one of the signals.
21:42:24 <tomayac> Marcosc: If I log in with Passkeys, it works
21:42:49 <tomayac> willmorgan: We're doing stuff on device. It's a limited use case.
21:43:32 <tomayac> willmorgan: There are also compliance reasons, people in the banks would like to know that someone was actually a person, and not just get a hash
21:43:56 <tomayac> ... This is a huge industry.
21:43:57 <reillyg> RRSAgent, please generate the minutes
21:43:57 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html reillyg
21:44:24 <tomayac> Marcosc: I think you have something quite interesting, and brightness is a small part of it.
21:44:41 <reillyg> s/usefuk/useful/
21:44:44 <tomayac> ... If we take the larger part, what would be the technology to solve your use case
21:44:47 <msw> +q: could auth ask the user to move head to match a set of poses that varies? (would need a sophisticated fake to beat), without needing phone-based brightness?
21:45:20 <tomayac> Marcosc: What is the ultimate way to solve this problem.
21:45:46 <tomayac> msw: Related to that idea, alternative methods would include to move the head to a set of poses
21:46:09 <tomayac> ... It would come up with a set of sequences
21:46:29 <scheib> q+
21:46:36 <tomayac> willmorgan: We have that already. This problem falls for deep fakes
21:47:06 <tomayac> msw: Understood. Is it not possible to fake light changes.
21:47:09 <msw> q-
21:47:22 <tomayac> reillyg: I have seen a demo of lighting changes
21:48:19 <tomayac> reillyg: The conclusion from the last message on the thread from Marcosc was to discuss in person
21:48:39 <tomayac> reillyg: Now you have collected a lot of info and the understanding is that there will be a response
21:48:48 <fbeaufort> q+
21:48:55 <tomayac> Marcosc: I will take back those declarative proposals
21:49:11 <scheib> q-
21:49:37 <tomayac> fbeaufort: Talking about the declarative approach, the CSS property was part of the explainer
21:49:55 <tomayac> ... Did WebKit not address this in their response?
21:50:19 <anssik> https://github.com/w3c/screen-wake-lock/blob/gh-pages/brightness-mode-explainer.md#css-property
21:50:21 <tomayac> reillyg: The issue is less the API, but the use cases
21:50:32 <tomayac> ... Now WebKit can make a more informed decision
21:51:24 <reillyg> ack fbeaufort
21:51:45 <tomayac> Marcosc: I learned Safari detects QR codes, but doesn't currently do anything with this info
21:52:15 <tomayac> reillyg: Up next would be Screen Wake Lock and removing the permission requirements
21:52:26 <tomayac> ... Then maybe system wake lock
21:52:51 <tomayac> ... Then some other things we can address
21:52:54 <jsbell> jsbell has joined #dap
21:54:20 <bneedham> bneedham has left #dap
21:56:49 <zkis_> zkis_ has joined #dap
22:19:36 <anssik> RRSAgent, draft minutes
22:19:36 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html anssik
22:21:09 <jsbell> jsbell has joined #dap
22:28:00 <tomayac> Topic: Screen Wake Lock API
22:28:21 <tomayac> reillyg: The implementation in Chromium always grants the permission to use a screen wake lock
22:28:30 <tomayac> ... It seems reasonable to remove the permission requirement
22:28:54 <tomayac> ... There was some accidental editorial issue, but there doesn't seem to be disagreement
22:29:40 <ghurlbot> https://github.com/w3c/screen-wake-lock/issues/326 -> Pull Request 326 Remove permission check (marcoscaceres)
22:30:13 <reillyg> RESOLUTION: Clean up and merge PR #326 to remove permission integration from Screen Wake Lock.
22:30:16 <tomayac> reillyg: The PR added a note that user agents may still deny
22:30:45 <diekus> diekus has joined #dap
22:31:09 <tomayac> ... Is there a standards position for screen wake lock? I think there's only a mailing list thread
22:31:22 <tomayac> Marcosc: Mozilla says "worth prototyping"
22:31:34 <diekus> present+
22:31:54 <tomayac> reillyg: Give the user agent information, and the user agent can then decide
22:32:38 <reillyg> ACTION: File WebKit standards position request for Screen Wake Lock API.
22:32:55 <tomayac> Marcosc: I file it now
22:34:00 <tomayac> q?
22:34:58 <tomayac> Topic: System Wake Lock
22:35:28 <tomayac> reillyg: There wasn't much progress on this, but I made some with an explainer
22:36:34 <tomayac> ... In the trend of APIs hinting declaratively to the user agent that they want to do something, if you play a video, this keeps the system awake and keeps the screen on, if you play audio, it keeps the system on, but not the screen,.
22:36:44 <tomayac> s/screen,./screen.
22:37:12 <tomayac> ... One of these requirements would be to tell the user agents that computation is going on
22:37:26 <tomayac> ... This might help with service worker lifetime issues.
22:38:30 <tomayac> ... If you want to keep the service worker alive for longer
22:38:43 <tomayac> tomayac: Isn't shared worker the tool for this
22:38:58 <tomayac> reillyg: Sometimes, but I want to convince folks that service worker is the response
22:39:38 <tomayac> tomayac: We talked once about background geolocation with system wake lock, would this be included?
22:40:22 <tomayac> reillyg: It could. The progress notification API (part of the upcoming explainer) could tell the service worker
22:40:55 <tomayac> ... I could imagine if you created a progress notification for a run for example, this could work
22:41:21 <tomayac> ... Every native platform seems to go in this direction. There's always some kind of notification required.
22:41:50 <tomayac> Marcosc: On iOS, it's modeled as "while using", "once", "always" for geolocation
22:41:57 <tomayac> ... For geolocation
22:42:37 <tomayac> reillyg: There is an entitlement for this
22:43:07 <tomayac> ... My mail app has an option to not use notifications, but to use IMAP
22:43:36 <tomayac> ... You really can dismiss the permanent notification. Users can remove it manually if they really want to
22:44:06 <tomayac> reillyg: Android historically had a lot of background powers that it granted to apps
22:44:24 <tomayac> reillyg: This was tightened up. The web model could be something in between.
22:45:17 <tomayac> Marcosc: I have Lyft, and if I turn off the permission, it asks me if I want to use it.
22:45:57 <tomayac> reillyg: One of the non-geolocation use cases is processing and uploading photos.
22:47:01 <tomayac> ... If you are a photo app, it will take, say 15s.
22:47:38 <tomayac> ... The model we've been using on the web is to force the user to keep the device on
22:48:05 <tomayac> ... I want to focus more on these use cases than on geolocation
22:48:27 <tomayac> ... I finish something like processing a file or so
22:49:19 <tomayac> Theodore_Olsauskas-Warren: Why is geolocation not a use case that's interesting?
22:49:35 <tomayac> reillyg: I want to not open this can of worms
22:50:33 <tomayac> Marcosc: Background fetch might be able to deal with some of these use cases
22:51:05 <tomayac> reillyg: We have a tool that uses WebUSB that loads new images to a device
22:51:27 <tomayac> ... If you close the tab, you don't want this to stop
22:52:04 <tomayac> ... We can't make a list of all the use cases for example on USB
22:52:17 <tomayac> Marcosc: I like the idea of a signal
22:53:03 <tomayac> reillyg: Do you want a screen wake lock signal on different things was an idea initially
22:54:01 <tomayac> ... The key thing is that a user agent cannot always tell what the user wants
23:06:59 <reillyg> RRSAgent, please generate the minutes
23:06:59 <RRSAgent> I have made the request to generate https://www.w3.org/2022/09/15-dap-minutes.html reillyg