W3C

– DRAFT –
Devices and Sensors WG - 2021 Q2 virtual meeting - New work

06 April 2021

Attendees

Present
Anssi_Kostiainen, Fuqiao_Xue, Marcos_Caceres, Olivier Yiptong, Raphael Kubo da Costa, Reilly Grant, Vincent_Scheib, Will_Morgan
Regrets
-
Chair
Anssi, Reilly
Scribe
Anssi, anssik

Meeting minutes

<reillyg> Self-hosted PWA: https://thelounge.chat/

Contact Picker API

Contact Picker API (from DAS WG Charter discussions)

Contact Picker API

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://web.dev/contact-picker/

<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://github.com/oyiptong/compute-pressure

Compute Pressure API

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://github.com/w3ctag/design-reviews/issues/621

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://wicg.github.io/idle-detection/

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"

Summary of resolutions

  1. Start the process to add Contact Picker API to the DAS WG Charter
  2. Seek more developer signals in support of Screen Brightness API to help advancement
  3. Investigate Idle Detection API extension for a third signal "user presence"
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

Diagnostics

Maybe present: anssik, Fuqiao, Kenneth, Marcos, Olivier, Raphael, Reilly, Vincent, Will