Potentially resolving the privacy sensitivity issue

[AdaRoseCannon]

I understand there has been TAG feedback regarding the privacy concerns and how we can inform users of the risks.

Where it's difficult to explain to users the potential risks in giving a website unfettered access to their camera as they move around their environment pointing it at possessions and loved ones.

I would like to propose that WebXR features could be split in a way that is similar to position tracking's fine grain coarse grain approach. Where for us coarse grain are the privacy preserving approaches and fine grain are the ones that give more power to the developer at the risk of user's privacy.

This way we can encourage developers to not rely on the availability of the API because user's may choose not to allow it if they are in an inappropriate place and the developer should instead try to use a fallback behaviour to provide an approximate experience or an alternative experience.

[bialpio]

I understand there has been TAG feedback regarding the privacy concerns and how we can inform users of the risks.

Yes, I still need to update the spec draft to account for the feedback. My plan is to add phrasing to the spec that brings it more in line with getUserMedia()'s approach & make the changes to our implementation (most notable difference was that our initial impl. in Chrome did not display a "camera in use" indicator).

As for the mock that you included (BTW, would you mind if I included it in the spec as one of the options to solve the problem of informing the users?), I am getting closer to obtaining agreement internally on the specifics of the UI that we will display, but unfortunately we are limited to two permission prompts in a row (edit: note that this is mostly relevant to Chrome, it won't be mandated by the spec and should result in obtaining the same level of consent as your mock does).

I would like to propose that WebXR features could be split in a way that is similar to position tracking's fine grain coarse grain approach. Where for us coarse grain are the privacy preserving approaches and fine grain are the ones that give more power to the developer at the risk of user's privacy.

I think this is mostly in line with how I've been thinking about AR permissions - internally in Chrome, we have an AR permission (used for the privacy-preserving APIs), and Camera (used for raw camera access, or camera-equivalent APIs; the thinking being that for example a high-res depth texture would only be returned if an origin has Camera-level permissions).

This way we can encourage developers to not rely on the availability of the API because user's may choose not to allow it if they are in an inappropriate place and the developer should instead try to use a fallback behaviour to provide an approximate experience or an alternative experience.

Full agreement here! I think we'll need to have a solution for immersive-web/webxr#1205 to make it easier for the devs to check enabled features, but I don't think this is a blocker.

[AdaRoseCannon]

As for the mock that you included (BTW, would you mind if I included it in the spec as one of the options to solve the problem of informing the users?)

Please do, yeah avoiding multiple consecutive permission prompts would be ideal.

display a "camera in use" indicator

Do you have any ideas for this? Since there is no URL bar would it be something like a red dot recording indicator in video cameras? Or a red frame?

[bialpio]

display a "camera in use" indicator

Do you have any ideas for this? Since there is no URL bar would it be something like a red dot recording indicator in video cameras? Or a red frame?

I'm aiming for an approach that getUserMedia() takes now - we display a notification in a status bar that informs that the site has camera access (if you have an Android phone with Chrome[1] lying around somewhere, you can try it at https://webrtc.github.io/samples/src/content/getusermedia/gum/, I've also attached screen capture of how it looks for me[2]). This also means that immersive AR sessions that have camera access will now show a status bar so that the notification is noticeable (normally, we'd enter fullscreen). The consequence of this approach is that if we ever add an API that allows sites to add features to sessions at runtime (immersive-web/webxr#1190), I think it'd mean that we'll always need to show a status bar (i.e. never enter true fullscreen) because we'd need space for the indicator in case the session wants to ask for camera later.

[1] Brave also behaves the same way, I also checked Firefox, but I didn't see any indicator shown there. :(

[2]
In status bar, next to the time:

When looking at the notification list: