Re: [ambient-light] Add camera permission requirement to spec? (#79)

This was discussed at the 2022 TPAC: https://www.w3.org/2022/09/15-dap-minutes.html#t18

The specifics of how this would work have varied over time, so let me try to see if I've captured the latest proposal correctly.

The idea is to tie ALS and video capture (via `navigator.mediaDevices.getUserMedia()`) together, so that an ALS is active if and only if there is at least one "live" MediaStreamTrack whose source is a local video capture device (regardless of whether it's a front-facing camera, a virtual device or something else).
- By definition, this means that permission to use a camera has already been granted by the user at this point.
- `AmbientLightSensor.start()` does not request the "camera" permission itself, it just expects it to have been granted for it to work.
- The "ambient-light-sensor" powerful feature and permission policy name remain; developers are expected to use both "camera" and "ambient-light-sensor" for the permissions policy integration to work.
 
We'd have an "ALS readings can be exposed" algorithm like this for an AmbientLightSensor object `sensor`:
- Let `global` be `sensor`'s relevant global object
- For each `source` in `global`'s `[[mediaStreamTrackSources]]` internal slot:
 + If `source` is a video source and it is not stopped, return true.
- Return false.

It's similar to https://w3c.github.io/mediacapture-main/#context-capturing-state, and it would be run whenever the [`[[devicesLiveMap]]`](https://w3c.github.io/mediacapture-main/#dfn-deviceslivemap) internal slot changes. In practice, it's similar to what https://w3c.github.io/mediacapture-main/#privacy-indicator-requirements mandates for the indicators in the UI.

The Media Capture spec is a bit hand-wavy when it comes to the concepts of sources and devices, and I think we'd be the first to have this sort of integration, so I'd like to double check that this is the right direction.

Opens:
- Do we still need the "ambient-light-sensor" powerful feature if the idea is for implementations not to prompt for it explicitly?
- Does a lack of active video sources cause an ALS to stop or just stop provide readings?
- Similarly, does `ALS.start()` fail if there are no active video sources or should the sensor just not provide readings?
- If the idea is to tie an ALS to an active track, maybe we do not even need to worry about the "camera" permission name or permission policy name at all?
- Maybe it makes sense to explicitly take a `MediaStreamTrack` instance in the constructor and tie an ALS to a specific track's lifetime?

-- 
GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/ambient-light/issues/79#issuecomment-1310600459 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 November 2022 16:57:56 UTC