xr-session-supported and handling in non-automatically granted cases

[pes10k]

This issue is a result of the PING review of w3cping/privacy-request#142

I appreciate that isSessionSupported is gated behind the xr-session-supported permission, which is a helpful step for ensuring compatibility with user agents that do not want to grant xr-session-supported automatically (in some or all cases).

However, I am concerned that there is no user activation requirement for the permission request. I worry that this will cause sites to expect the permission to be automatically granted on page load (as it is in large browsers currently) and so not handle the case where the permission is denied (or even prompted for).

Can the group explain more about why this decision was made? What would be lost to require the user activation (or other ways discouraging sites from assuming they'll be granted the permission automatically, on page load, and so not adequately handling and explaining to users whats happening in cases where the permission is not automatically granted?

[Manishearth]

or other ways discouraging sites from assuming they'll be granted the permission automatically, on page load

It's a core part of the design of the feature that sites can assume they might be granted the permission automatically on page load. We explicitly spec out cases where this is okay for websites to do!

There is no fingerprinting risk of an Oculus Browser user-agent revealing that it does in fact support immersive-vr, nor is there a fingerprinting risk of an Android phone revealing that it doesn't.

There's a bit of a tension here between enabling websites to choose to show a "enter vr" button on devices where that may be the primary way of interacting with the website, and having websites bombard the user with permissions queries.

[toji]

@Manishearth captured the main points (thanks!) but I wanted to address this question specifically:

Can the group explain more about why this decision was made? What would be lost to require the user activation (or other ways discouraging sites from assuming they'll be granted the permission automatically, on page load, and so not adequately handling and explaining to users whats happening in cases where the permission is not automatically granted?

I think that the PING is aware of this breakdown, but I want to review it briefly again for the sake of clarity. The bulk of the API's interaction and data come from an XRSession created with the navigator.xr.requestSession() method. This method does require user activation and does require user consent, explaining to the user what access is being granted. Crucially, it does so in the appropriate context, which helps the user understand what is being asked for. That method is almost always called in response to the user clicking a button that indicates via text or icon that it will begin displaying VR or AR content. As such when the user clicks such a button and is then asked for access to the XR hardware and data they understand why that is happening.

However, pages do not want to advertise that they are VR or AR capable to all of their users, given the relative rarity of the necessary hardware. Presenting a button to users that only exists to tell you "Pushing this button was useless" is a terrible user experience. As such, we provide isSessionSupported() to provide the absolute minimum information needed (a single boolean) to hint to the page whether or not showing such a button would be appropriate.

Requiring user activation or a permission prompt to call that method, however, would be an unworkable and frustrating experience. Changing the layout of a page on first interaction isn't desirable, and showing a permission prompt unexpectedly and out of context is the type of behavior users hate. (See: The Geolocation API) Not to mention you would at that point be showing a permission prompt to ask if you can show a button which will show a permission prompt.

We've worked hard to both be very cautious with the sensitive data that our API handles while also enabling developers to create experiences that are user friendly. In that process we decided as a group that exposing a single bit (which is not guaranteed to be reliable) outside of user activation and consent was an appropriate balance, and I continue to feel good about that balance today.