Meeting minutes
<reillyg> Self-hosted PWA: https://
Contact Picker API
Contact Picker API (from DAS WG Charter discussions)
anssik: Reilly found out via Google DevRel Contact Picker is being implemented by Apple
… an early version has been in this WG's charter earlier
Reilly: positive signal that Apple is implementing
… perhaps ask Apple to join this group and give a signal whether this API they're now implementing is good to progress
anssik: what is the minimal work to adopt this API to the WG?
Fuqiao: we need to run an AC review and HR that is restricted to the added deliverable?
anssik: Any status updates from the spec editors?
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
anssik: Chrome implementation is feature complete?
… can this be tested properly?
Reilly: w-p-t exists, the API surface is minimal, so complexity mainly in the UI elements
anssik: how is the privacy story?
<xfq> Privacy Considerations section
Reilly: strong mitigations against harvesting contacts,
… which is the key concern
Kenneth: the user can also deselect
<reillyg> https://
<reillyg> Demo:
proposed RESOLUTION: Start the process to add Contact Picker API to the DAS WG Charter
anssik: any comments or concerns with that proposed resolution?
Resolution: Start the process to add Contact Picker API to the DAS WG Charter
Screen Brightness API
Screen Brightness API (WICG proposal)
anssik: have folks followed up this incubation?
Reilly: there's a proposal but no work on the Chrome side to implement this yet, it is interesting
Kenneth: alternative was to extend Screen Wake Lock API
Raphael: explorations on whether we can extend Screen Wake Lock API or have a standalone and what the feature set it
anssik: it sounds like this needs a bit more incubation before advancing to mature stages of standardization
Reilly: things that are needed, more concrete plan around things like whether to integrate with Wake Lock
… we minimized the size of Wake Lock to mitigate misuse
… Google DevRel signals demonstrate developer interest
<willmorgan> Morning. Is the meeting still ongoing?
<oyiptong> yes
Reilly: the use case of face detection relies Ambient Lighting condition, Face Detection API, also wants to control screen brightness
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
… feature request is to be able to set screen to x % brightness for y secs
… if the tab is closed, revoke this request
Reilly: anssik: what would be needed from Chrome perspective to move this forward?
Reilly: prototyping would help, there's cost involved, the first step is to build the developer interest, with multiple developers interested in this API
… one of the use cases is QR code scanning, for example
proposed RESOLUTION: Seek more developer signals in support of Screen Brightness API to help advancement
Raphael: if we'd have Screen Brightness API would ALS API still be relevant to your use case?
Will: yes it is
Resolution: Seek more developer signals in support of Screen Brightness API to help advancement
Compute Pressure API
<oyiptong> https://
Olivier: We propose a new API that conveys the utilization of CPU resources on the user's device.
… Use cases: video conferencing, video games
… API design is in the explainer, and there are some concepts we take in consideration such as Turbo Boost
… privacy considerations discussed in the explainer too
… we're going to have an implementation soon and incubation in WICG
Marcos: what motivated this API?
Olivier: developers have requested the ability to know if the computer throttled
… in order to adapt to the device, need to understand how much resources are utilized and predict what's going to happen next
Marcos: any equivalent native API for this proposal?
Olivier: there are internal APIs e.g. procfs/sysinfo etc. pretty low-level
Reilly: has this been circulated among the privacy group, e.g. quantization scheme?
Olivier: some folks at Google have looked at this issue, but PING has not yet reviewed
Kenneth: TAG review issue has filed
<kenchris> * marcosc sure wait a sec
<kenchris> https://
User Presence API
Anssi: An implementation of User Presence API may combine information from multiple sources and adapt to varying environments, usages, and end-user behavior.
… some use cases, some of which may resonate for the web:
- 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.
- 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.
- Lock when the user leaves. Lock the system once the user leaves.
- No lock on presence. Keep the display on if the user in engaged, e.g. reading a document.
- Multiple faces. Can detect if multiple faces exist in the field of view, for enhanced privacy (no looking over the shoulder, think online banking).
- Browser auto-pause. When the user disengages, stop animations and videos, other expensive logic.
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.
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
… wake lock controlled by OS, maybe there are additional signals from this proposal we'd like to surface to web sites
<reillyg> > Idle Detection API: https://
Reilly: 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
… this API is similar to the proposed User Presence API
… detects active engagement in e.g. Zoom, Slack
… in this use case cannot figure out the engagement if the used switches from Zoom to e.g. document editing in another window
… use signals from OS whether the use is actively engaged on the particular device, and this proposed API solves that problem
anssik: it sounds like we could use the Idle Detection API surface with this more advanced implementation
Reilly: generalizing Idle Detection API signals would be an interesting effort, maybe add a third signal "user presence"
proposed RESOLUTION: Investigate Idle Detection API extension for a third signal "user presence"
marcos: I like this 3rd signal for user presence
Vincent: the critical thing to discover is how to differentiate between "idle" and "user presence"
… the key thing is to understand the use cases for User Presence and Idle Detection
Reilly: different apps have different apps, some apps are interested in screen lock state, e.g. when the screen is locked, stop recording on cam before the screen is locked
… this is user presence signal but also a security feature
… input activity is another signal
proposed RESOLUTION: Investigate Idle Detection API extension for a third signal "user presence"
Resolution: Investigate Idle Detection API extension for a third signal "user presence"