Permissions and ongoing user control

[blairmacintyre]

Access to real-world-geometry brings up the questions of permissions and levels of permissions and how they might work in practice.

The implementation I am working toward has 3 levels of permissions, with the UA also supporting a "reduced information" (lite) mode.

An app can request one of these progressive levels (each includes the previous):

• minimal, basic WebXR: spatial tracking, hitTesting, creating anchors from absolute matrices or hitTest results
• world sensing: real-world-geometry, illumination, detection and tracking of well-defined things the platform supports (images, objects, QRCodes, etc), world relocalization maps, etc
• camera / sensor data: originally this was "camera" access, but it includes, I think, access to any of the low level sensors a device might have.

There are questions, obviously. How can we standardize on some of the sensing bits. Where do things like eye trackers and other invasive sensors (like "affect" sensors, or facial tracking of the user in an HMD for creating their avatar elsewhere) fit?

For both the "minimal" and "world sensing" levels, there is a "limited" option, which (for our iOS app) has the user select a plane; that is the only world structure that gets exposed, or hit test against.

Finally, we are displaying the current state in the URL bar (when it's exposed), akin to the HTTPS icon or camera or microphone icon on a browser. Clicking on it brings up a detailed permissions sheet, where specific information can be turned on/off, including the most basic access. The web page is NOT notified of these changes; the data just stops flowing. The user can change this at any time.

This relates to the real-world-geometry in two ways:

• I am adding an option to request session, called "worldSensing". If true, when the user is asked for permission to use XR, it also includes permission to use "worldSensing". The advantage of doing this is that the user only gets one permission request, instead of getting a WebXR permission and then a worldSensing permission. We have not decided yet what to do about failure: does the user have the option to say "yes" to "webxr" but "no" to world sensing? Or does the webpage need to deal with requestSession failing, and then request a session with less access (or display and error?)
• if the app requests anything requiring worldSensing later, and didn't put worldSensing in the original request, we could trigger a new permission. Apps might do this if they want to wait until the user does something that requires world sensing, if they don't require it all the time. It would be nice if there was a way for the app to provide a string or description of why they want this. if not, pages can display info before they request (since they know it's going to trigger one).

Thoughts?

[bialpio]

This can move to https://github.com/immersive-web/privacy-and-security? In general, it’s a good point but I’d like to defer trying to solve this to a later time as it has to do more with session creation - that to me seems like the only reasonable time for the application to express the need to access more fine-grained data (we don’t want to fatigue the user with too many prompts, although one might be fine).

[blairmacintyre]

I agree we don't want to solve it; but, I posted here so that we keep this in mind. We don't want to go down a path that will be incompatible with these issues, for example.

For example, asking during session creation is one part of the solution. But, as smartphone app developers have found, waiting until a specific permission is needed is better for user understanding (i.e, the work flow of saying something like "We need access to X in order to provide the feature Y you just asked for. Click the button to request permission", then requesting the feature that may cause a permission prompt).

I can see both being needed in a WebXR situation.

• small, dedicated webxr pages may ask up front, for the very reason you suggest (don't bug the user with many permissions)
• large sites (e.g., youtube, ikea, etc) that have XR features (e.g., VR video viewing, put-the-furniture-in-the-room) may want to defer asking until needed. Now, it may very well be that those sites will just defer initializing WebXR until then, so it ends up being the same.

But, as you say, I don't really want to solve this here, I just want to make a note of the issue. Creating a similarly issue in privacy-and-security, and linking it back here is a good idea, I duplicated and linked it here.

[bialpio]

Link to PR: immersive-web/webxr#689.

[bialpio]

Closing stale issue - I believe we have this problem solved by requiredFeatures/optionalFeatures passed in to session request. The use of plane detection needs to be signaled at session creation (to give the UA a chance to ask for permissions), and then the API (whatever shape we end up with) can be used w/o prompts.