04:46:34 <RRSAgent> RRSAgent has joined #dap
04:46:34 <RRSAgent> logging to https://www.w3.org/2021/04/06-dap-irc
04:58:14 <anssik> anssik has joined #dap
04:58:56 <oyiptong> oyiptong has joined #dap
05:00:45 <xfq> present+
05:00:49 <anssik> Zakim, prepare meeting
05:00:49 <Zakim> RRSAgent, make logs Public
05:00:50 <Zakim> please title this meeting ("meeting: ..."), anssik
05:00:54 <anssik> Present+ Anssi_Kostiainen
05:01:00 <oyiptong> present+ Olivier Yiptong
05:01:11 <anssik> Agenda: https://www.w3.org/events/meetings/756f098f-08f0-4230-80fb-4762754996a9
05:01:20 <anssik> Meeting: Devices and Sensors WG - 2021 Q2 virtual meeting - New work
05:01:22 <reillyg> present+ Reilly Grant
05:01:24 <rakuco> present+ Raphael Kubo da Costa
05:02:00 <kenchris> kenchris has joined #dap
05:02:37 <anssik> RRSAgent, draft minutes v2
05:02:37 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
05:02:45 <reillyg> Self-hosted PWA: https://thelounge.chat/
05:03:12 <anssik> Chair: Anssi, Reilly
05:03:23 <anssik> RRSAgent, draft minutes v2
05:03:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
05:04:43 <anssik> Present+ Vincent_Scheib
05:05:55 <anssik> Scribe: Anssi
05:06:04 <anssik> scribeNick: anssik
05:07:52 <anssik> Topic: Contact Picker API
05:08:25 <anssik> -> https://github.com/w3c/dap-charter/issues/97 Contact Picker API (from DAS WG Charter discussions)
05:08:57 <anssik> -> https://wicg.github.io/contact-api/spec/ Contact Picker API
05:09:51 <anssik> anssik: Reilly found out via Google DevRel Contact Picker is being implemented by Apple
05:10:04 <anssik> ... an early version has been in this WG's charter earlier
05:10:16 <anssik> Reilly: positive signal that Apple is implementing
05:10:38 <anssik> ... perhaps ask Apple to join this group and give a signal whether this API they're now implementing is good to progress
05:11:29 <anssik> anssik: what is the minimal work to adopt this API to the WG?
05:12:14 <anssik> Fuqiao: we need to run an AC review and HR that is restricted to the added deliverable?
05:12:49 <anssik> anssik: Any status updates from the spec editors?
05:13:27 <anssik> Reilly: there has been internal discussion whether this spec should graduate, the position from Google is the spec should migrate from WICG to a WG
05:13:53 <anssik> anssik: Chrome implementation is feature complete?
05:13:59 <anssik> ... can this be tested properly?
05:15:01 <anssik> Reilly: w-p-t exists, the API surface is minimal, so complexity mainly in the UI elements
05:15:11 <anssik> anssik: how is the privacy story?
05:15:16 <xfq> Privacy Considerations section -> https://wicg.github.io/contact-api/spec/#privacy
05:15:44 <anssik> Reilly: strong mitigations against harvesting contacts,
05:16:15 <anssik> ... which is the key concern
05:16:30 <anssik> Kenneth: the user can also deselect
05:17:25 <reillyg> -> https://web.dev/contact-picker/
05:17:38 <reillyg> -> Demo: https://contact-picker.glitch.me/
05:18:15 <anssik> proposed RESOLUTION: Start the process to add Contact Picker API to the DAS WG Charter
05:18:21 <anssik> RRSAgent, draft minutes v2
05:18:21 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
05:19:18 <anssik> anssik: any comments or concerns with that proposed resolution?
05:21:17 <anssik> RESOLUTION: Start the process to add Contact Picker API to the DAS WG Charter
05:21:25 <anssik> RRSAgent, draft minutes v2
05:21:25 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
05:21:31 <anssik> Topic: Screen Brightness API
05:22:25 <anssik> -> https://github.com/WICG/proposals/issues/17 Screen Brightness API (WICG proposal)
05:24:17 <anssik> anssik: have folks followed up this incubation?
05:24:40 <anssik> Reilly: there's a proposal but no work on the Chrome side to implement this yet, it is interesting
05:25:28 <anssik> Kenneth: alternative was to extend Screen Wake Lock API
05:26:22 <anssik> Raphael: explorations on whether we can extend Screen Wake Lock API or have a standalone and what the feature set it
05:27:26 <anssik> anssik: it sounds like this needs a bit more incubation before advancing to mature stages of standardization
05:28:08 <anssik> Reilly: things that are needed, more concrete plan around things like whether to integrate with Wake Lock
05:28:38 <anssik> ... we minimized the size of Wake Lock to mitigate misuse
05:28:51 <anssik> ... Google DevRel signals demonstrate developer interest
05:30:51 <xfq_> xfq_ has joined #dap
05:31:29 <willmorgan> willmorgan has joined #dap
05:31:51 <willmorgan> Morning. Is the meeting still ongoing?
05:32:00 <oyiptong> yes
05:32:29 <anssik> Reilly: the use case of face detection relies Ambient Lighting condition, Face Detection API, also wants to control screen brightness
05:36:04 <anssik> Will: Screen Brightness API is something iProov is interested in, we're using light reflection to do bidir security, we have iOS and Android apps, but would like to bring this experience to the web
05:36:42 <anssik> ... feature request is to be able to set screen to x % brightness for y secs
05:36:59 <anssik> ... if the tab is closed, revoke this request
05:39:32 <anssik> Reilly: anssik: what would be needed from Chrome perspective to move this forward?
05:40:31 <anssik> Reilly: prototyping would help, there's cost involved, the first step is to build the developer interest, with multiple developers interested in this API
05:40:50 <anssik> ... one of the use cases is QR code scanning, for example
05:42:18 <anssik> proposed RESOLUTION: Seek more developer signals in support of Screen Brightness API to help advancement
05:45:15 <anssik> Present+ Marcos_Caceres
05:46:47 <anssik> Raphael: if we'd have Screen Brightness API would ALS API still be relevant to your use case?
05:46:56 <anssik> Will: yes it is
05:48:24 <anssik> RESOLUTION: Seek more developer signals in support of Screen Brightness API to help advancement
05:49:10 <anssik> Topic: Compute Pressure API
05:49:22 <oyiptong> https://github.com/oyiptong/compute-pressure
05:49:44 <anssik> -> https://github.com/oyiptong/compute-pressure Compute Pressure API
05:50:01 <marcosc> marcosc has joined #dap
05:51:11 <anssik> Olivier: We propose a new API that conveys the utilization of CPU resources on the user's device.
05:51:34 <anssik> ... Use cases: video conferencing, video games
05:51:53 <anssik> ... API design is in the explainer, and there are some concepts we take in consideration such as Turbo Boost
05:52:05 <anssik> ... privacy considerations discussed in the explainer too
05:52:26 <anssik> ... we're going to have an implementation soon and incubation in WICG
05:52:31 <anssik> Marcos: what motivated this API?
05:52:53 <anssik> Olivier: developers have requested the ability to know if the computer throttled
05:53:14 <anssik> ... in order to adapt to the device, need to understand how much resources are utilized and predict what's going to happen next
05:54:02 <anssik> Marcos: any equivalent native API for this proposal?
05:54:33 <anssik> Olivier: there are internal APIs e.g. procfs/sysinfo etc. pretty low-level
05:55:05 <anssik> Reilly: has this been circulated among the privacy group, e.g. quantization scheme?
05:55:15 <xfq> xfq has joined #dap
05:55:27 <anssik> Olivier: some folks at Google have looked at this issue, but PING has not yet reviewed
05:55:38 <anssik> Kenneth: TAG review issue has filed
05:57:05 <kenchris> * marcosc  sure wait a sec
05:57:13 <anssik> q?
05:57:36 <kenchris> https://github.com/w3ctag/design-reviews/issues/621
05:57:50 <anssik> Topic: User Presence API
05:59:49 <anssik> ... An implementation of User Presence API may combine information from multiple sources and adapt to varying environments, usages, and end-user behavior.
05:59:56 <anssik> ... some use cases, some of which may resonate for the web:
06:00:25 <anssik> - Auto dim. Can dim backlight when the user has disengaged and quickly turn off the display when the user is not paying attention or not present.
06:01:04 <anssik> - Wake on face. Can wake when user comes into view, without physically interacting with the device (cookbook use case!!). Can differentiate from other movement, only triggered by a human face.
06:01:31 <anssik> - Lock when the user leaves. Lock the system once the user leaves.
06:01:46 <anssik> - No lock on presence. Keep the display on if the user in engaged, e.g. reading a document.
06:02:46 <anssik> - Multiple faces. Can detect if multiple faces exist in the field of view, for enhanced privacy (no looking over the shoulder, think online banking).
06:02:58 <anssik> - Browser auto-pause. When the user disengages, stop animations and videos, other expensive logic.
06:03:53 <reillyg> q+
06:04:01 <anssik> anssik: Wanted to test with you folks if this resonates to signal whether we should incubate this further? There are some interesting interactions with Proximity API and Screen Wake Lock API at play, also possibly other APIs could be improved with this tech. But an explicit API would offer web developers means to innovate directly.
06:04:27 <anssik> q?
06:04:30 <anssik> ack reillyg
06:04:38 <marcosc> q+
06:05:02 <anssik> Reilly: I think a lot of the use cases sound great OS and browser features, less certain whether they can be pushed to the sites directly
06:05:41 <anssik> ... wake lock controlled by OS, maybe there are additional signals from this proposal we'd like to surface to web sites
06:05:47 <reillyg> > Idle Detection API: https://wicg.github.io/idle-detection/
06:06:18 <anssik> ... however there's work I'm doing called Idle Detection API, this API is currently in WICG incubation and working on prototype with developers, currently testing if it improves UX
06:06:35 <anssik> ... this API is similar to the proposed User Presence API
06:07:00 <anssik> ... detects active engagement in e.g. Zoom, Slack
06:07:43 <anssik> ... in this use case cannot figure out the engagement if the used switches from Zoom to e.g. document editing in another window
06:08:31 <anssik> ... use signals from OS whether the use is actively engaged on the particular device, and this proposed API solves that problem
06:09:55 <anssik> anssik: it sounds like we could use the Idle Detection API surface with this  more advanced implementation
06:10:31 <anssik> Reilly: generalizing Idle Detection API signals would be an interesting effort, maybe add a third signal "user presence"
06:11:31 <anssik> proposed RESOLUTION: Investigate Idle Detection API extension for  a third signal "user presence"
06:11:37 <anssik> q?
06:12:01 <anssik> q?
06:12:04 <anssik> ack marcosc
06:12:34 <anssik> marcos: I like this 3rd signals for user presence
06:12:44 <anssik> s/signals for/signal for
06:12:46 <willmorgan_> willmorgan_ has joined #dap
06:13:29 <anssik> Vincent: the critical thing to discover is how to differentiate between "idle" and "user presence"
06:14:10 <anssik> ... the key thing is to understand the use cases for User Presence and Idle Detection
06:14:48 <anssik> Reilly: different apps have different apps, some apps are interested in screen lock state, e.g. when the screen is lcoked, stop recording on cam before the screen is locked
06:15:01 <anssik> ... this is user presence signal but also a security feature
06:15:16 <anssik> ... input activity is another signal
06:15:32 <anssik> RRSAgent, draft minutes v2
06:15:32 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
06:16:11 <anssik> proposed RESOLUTION: Investigate Idle Detection API extension for  a third signal "user presence"
06:16:31 <anssik> RESOLUTION: Investigate Idle Detection API extension for  a third signal "user presence"
06:18:25 <anssik> RRSAgent, draft minutes v2
06:18:25 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
06:20:49 <anssik> s/Kenneth: An/An
06:20:55 <anssik> RRSAgent, draft minutes v2
06:20:55 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
06:23:14 <xfq> s/Kenneth: An implementation of User/Anssi: An implementation of User/
06:23:20 <anssik> RRSAgent, draft minutes v2
06:23:20 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
06:23:21 <xfq> RRSAgent, make minutes
06:23:21 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html xfq
06:30:59 <anssik> s/lcoked/locked
06:31:14 <anssik> RRSAgent, draft minutes v2
06:31:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
06:34:21 <xfq> rrsagent, bye
06:34:21 <RRSAgent> I see no action items
14:53:24 <RRSAgent> RRSAgent has joined #dap
14:53:24 <RRSAgent> logging to https://www.w3.org/2021/04/06-dap-irc
14:53:27 <Zakim> Zakim has joined #dap
15:01:30 <xfq> rrsagent, make log public
15:01:32 <xfq> rrsagent, make minutes
15:01:32 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html xfq
15:03:06 <anssik> RRSAgent, draft minutes v2
15:03:06 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
15:03:37 <anssik> Meeting: Devices and Sensors WG - 2021 Q2 virtual meeting - New Work and Other device capabilities
15:03:38 <anssik> RRSAgent, draft minutes v2
15:03:38 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html anssik
15:05:15 <xfq> xfq: test
15:05:15 <xfq> RRSAgent, draft minutes
15:05:15 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-dap-minutes.html xfq
15:10:58 <xfq> rrsagent, on
15:11:15 <xfq> rrsagent, this meeting spans midnight
15:46:18 <anssik> anssik has changed the topic to: We're now on #das channel
16:04:46 <pete_snyder> pete_snyder has joined #dap
16:17:02 <pete_snyder> pete_snyder has left #dap
17:19:57 <Zakim> Zakim has left #dap