Re: [w3ctag/design-reviews] WebXR Raw Camera Access API (#652)

> I am a bit worried of us making parallel camera APIs expecially as this seems to be lacking a lot of features that I believe people would want at some later point.
> 
> * How do I select which camera to use (external vs internal etc)
> * How to select quality, SD, HD, 4K?
> * How to do pan/tilt/zoom etc?

The goal here was to provide something that is tied to the camera that is currently being used by the XR system to provide the AR experience (for example, AR implementation in Chrome currently composes the camera feed with site's WebGL-rendered content, w/o offering any of those configuration knobs, and also w/o exposing the pixels to the site). I imagine that some of those settings would have to be exposed at XRSession creation (quality & camera selection, pan/tilt/zoom would not be available since the current spec text requires that camera image is aligned with XRView), but it may be something that remains fixed for the entire duration of the session (depending on whether it is allowed the underlying AR framework that the implementations use). There was a long [discussion](https://github.com/bialpio/webxr-raw-camera-access/issues/1), whose outcome was to pursue a simpler, XRView-aligned camera access API in order to cater for smartphone-specific use cases, while leaving the door open for a more general solution which would integrate with `getUserMedia()` APIs.

> I'm still concerned that with the presence of this API developers will always choose to request _raw camera access_ even if they don't need it, thereby rendering the privacy-preserving aspects of regular _camera access_ meaningless... Can the explainer or the spec go into more detail on why this won't be the case?

I do not think it is possible for us to guarantee that this won't ever be the case, we can only try to incentivize the developers to ask for what they need. We do not attempt to specify the UX in the normative text, but I'd like the UAs to make the distinction between "lower-privilege session" (w/o granting the app access to camera pixels, but exposing the information that ultimately is derived from camera pixels and IMU sensors) and "higher-privilege session" (the camera pixels are accessible to the app) understandable by the user when displaying permission prompts - if the distinction is clear, the raw-camera-access sessions should hopefully be more frequently rejected by the users. I'll add more text to the explainer.

With all that said, the privacy efforts made by WebXR can all be sidestepped if the app asks for camera via `gUM()` & the user allows it. :frowning_face: 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/652#issuecomment-906609530