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

> What do you think of @Sauski's suggestion that the prompting should highlight to the user that the app has requested special permission over and above regular WebXR AR?

I think we're on the same page here, I definitely agree we need to ensure the implementations give sufficient information to the users regarding potential implications of the choices they are presented with and I'll look at WebNFC for inspiration on how to best include this in the spec. I'm mostly wary of including normative text that would mandate the UAs to do one thing or the other, independent of the circumstances. One thing that comes into play here is that WebXR allows the implementations to infer [user intent](https://immersive-web.github.io/webxr/#user-intent) / consent.

To shed some light on the current, behind-the-flag implementation in Chrome: we display a different prompt based on the set of features that an app is requesting to be enabled in a given session (if raw camera access is requested, we will use a prompt that is distinct from what is displayed to the user when an app requires access to the less privacy-invasive features). This is still something that we want to iterate on with our privacy and UX teams, which is one more reason that makes me want to avoid mandating concrete UX in the spec.

> Again to be clear I don't think we can solve this issue only by adjusting prompts because of the problematic nature of prompts but it can be one mitigation.

I'd like for the mitigations to stay on the UX side of things, but that does not necessarily mean that they will be limited to consent prompts (one other example: displaying some visual indicator for the entire duration of a session in which the camera pixels are accessible to the app). Unfortunately, I do not think it would be possible to introduce the limitations in the API shape itself without causing the API to fail to meet its purpose, but I admit the only thing that currently comes to my mind is to throttle how often the site would be able to get the camera texture.

In general, do you think that the problem with the current spec lies in the API shape itself (implying that we should change something in it, including at the Web IDL level), or do you expect that we should be able to address the concerns by ensuring that the users can make an informed decision and keep being informed about the camera being in use (implying that the solution can stay at the UX level)?

-- 
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-928289154