bialpio
commented
2 years ago 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
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.