For now, block mid-session consent requests for non-xr features

[NellWaliczek]

We're still figuring out what we'd like to do about mid-session requests for user consent for features that have nothing directly to do with XR (e.g. usb, geolocation, etc) in #726. Given that issue isn't a "VR Complete" issue, it might be prudent to temporarily add spec text which blocks allowing any form of consent from being requested mid-session. Perhaps we can allow for the exception of if the UA has a Trusted Immersive UI solution, even though the actual requirements for such a solution have not been finalized (see #718)

[blairmacintyre]

The first part does not seem reasonable. I think the second half does: make it clear that permission requests must only go through a Trusted Immersive UI, or they should be disallowed.

Even if a permission request, such as geolocation, requires popping all the way back out to the top level shell, and is ugly and breaks immersion, that is far better than impossible-to-get-around failure.

[NellWaliczek]

Yeah, I definitely don't think that blocking would be a long term solution. My main concern was simply that we might be currently unsafe by not having an answer to #718. If @avadacatavra and @johnpallett are ok with it, I'm perfectly happy to go with the second approach listed.

[avadacatavra]

I think that as long as the spec makes it clear that blocking the mid-session requests is a stopgap measure while we enumerate what a Trusted Immersive UI is, it would be fine. We could add something like @blairmacintyre suggests saying that this only applies to mid immersive session requests, so if UAs want to pause the immersive session in order to do a non-immersive request and then reenter immersion after it's been handled, that's fine.

make it clear that permission requests must only go through a Trusted Immersive UI, or they should be disallowed.

👍

[johnpallett]

Perhaps we can allow for the exception of if the UA has a Trusted Immersive UI solution

Thanks @NellWaliczek for logging this issue, it seems like a trickier question than deferred WebXR features. I have a couple of questions on the exception, curious to hear everyone's thoughts...

Q: How would a developer determine whether or not the above exception was available? If they can't, developers might view it as a 'safe' approach to always request permissions before session creation. It's also possible that developers might not realize that different UAs behave differently, leading to experiences that depend on the exception (@ddorwin touched on similar concerns here).

Q: Do we want to add a requirement for a trusted user interface? For context, I haven't found another spec that does this (disclaimer: my search was not exhaustive.) Some user agents will want to use a trusted user interface, but is there a reason to require it for all user agents? (note: This is also being discussed in #719.)

@avadacatavra @blairmacintyre what do you think?

[johnpallett]

In discussion with @blairmacintyre (I am taking notes):

• Developers cannot detect using the existing API whether a platform will or will not allow mid-session consent prompts.

• A primary concern with the exception is that developers will get failed permission requests without knowing whether they were due to lack of trusted UX or not (there is no way to detect this ahead of time today).

• There is a potential for failure patterns where UA strings are used by developers to detect the ability to generate prompts mid-session, and such apps would not update with new UA strings or new behaviors.

• Developers using libraries may not have control over when permissions appear.

• Not everything with user consent is in the Permissions registry (e.g. EME) and this is a deeper problem than we may be able to solve right now.

• Some platforms may not support suspend/resume capabilities for displaying user consent.

• Desktop (i.e., Vive, Rift) may be a primary development platform; if mid-session consent is not supported there, then that becomes a strong signal to developers on how things would work cross-platform. Conversely, if permissions worked on desktop, developers might assume they'd work everywhere.

Proposal:

1. For now, say in the spec that "Mid-session user prompts are not allowed. But we're working on it!"
2. Create an issue right away to start iterating on approaches to mid-session consent

@blairmacintyre would love feedback from @avadacatavra and @kearwood on this

[kearwood]

I agree with this approach, as long as there is some clarification in the spec text / language:

• That although mid-session permission prompts are not allowed, permission requests that don't need a visual prompt (eg, previously accepted for the origin), would be accepted.
• Specify what happens when permissions are requested mid-session - Eg, does the UA act as though the user declined the permission?
• Specify what happens in an XR link traversal scenario. Are permission prompts possible while loading the destination page during immersive sessions traveling between URL's?

[johnpallett]

From the face-to-face call today, @kearwood indicated general agreement to this approach.

Further @kearwood pointed out that the spec language should be precise on that it's user consent being prevented, not permissions. If a user already has given consent for an origin to use a feature outside the immersive session, then that feature should be allowed mid-session.

Further, @kearwood pointed out that we should specify how the user agent should behave if user consent is requested mid-session. For example, a user agent probably should not assume the user would reject a permission request, as this could permanently block that feature on the origin.

Two suggested approaches for how a user agent should respond to mid-session consent requests were:

1. Terminate the immersive session. This has the advantage of giving developers a clear signal that consent is not supported, but might be complicated for developers using third-party libraries that could request consent-based features in unpredictable ways.

2. Ignore the consent request. For example, if consent is triggered through the request for a feature, refuse access to that feature, but don't change permission state (e.g. 'ignore' instead of 'block')

I'm not sure I described these options well, so feedback welcome on language... there could be other options as well. @kearwood @blairmacintyre @avadacatavra @AdaRoseCannon any thoughts?

(Also if I missed any important notes please do comment) :)

[johnpallett]

• Specify what happens in an XR link traversal scenario. Are permission prompts possible while loading the destination page during immersive sessions traveling between URL's?

@kearwood good question, this seems related to mid-session navigation, I added Navigation#6 to capture the question. Outside of mid-session navigation is there a scenario you have in mind here?

[johnpallett]

Several participants mentioned on the call today that while this might be an appropriate stopgap, it's important for us to find a solution to mid-session consent prompts. I couldn't find an issue specific to that question, so I've created #766 to track finding such as solution. There are a number of linked issues there (including this one).