Timing of user consent requests

[NellWaliczek]

[Disclaimer: This issue is one of several being filed to capture discussions that began either on #638, on #689, or at the most recent F2F]

When getting user consent is required to protect sensitive information, there appear to be three options for when the User Agent can ask for the consent. (Note, this is not the issue for discussing the duration of consent. That can be found in a #721)

1. At the time a session is created
2. At the time an API is invoked which developer intent to use information that requires user consent (e.g. requestReferenceSpace())
3. Some combination of the above depending on the thing consent is being requested for

From what I’ve been able to gather, the following questions need to be answered before we’ll be able to come to a conclusive design:

• Do all User Agents need to align on a single option from the list above? This is really a question of principle rather than how developers would use such an API in practice. In other words, if it would be possible for a developer to write a single predictable code path that would allow User Agents the choice of when to prompt, is that acceptable? Desirable? Concerning?
• Does requesting consent in the middle of an immersive session require the use of Trusted Immersive UI (see What is Trusted Immersive UI? #718)? IIRC, John mentioned this might be necessary to ensure end users don’t get confused or tricked by a website spoofing Trusted Immersive UI if they’ve gotten used to consent prompts not being Trusted. (Note, resolving this bullet point may cause a dependency on Is Trusted Immersive UI a conformance requirement? #719 )

Are there other considerations I’ve missed?

[NellWaliczek]

Also related to #423

[ddorwin]

Related to the first bullet, I think it's important that developers understand what could happen and are not surprised. For example, if most implementations do one thing and another makes a different decision, developers shouldn't be surprised by a poor user experience, multiple or repeated prompts, etc. In other words, the specification should make it clear to developers - and implementations via normatively specified points where user interaction might be required - when there might be consent prompts so they can avoid patterns that may cause undesirable results. It may also help with compatibility if there are fewer ways things can vary across implementations.

Some additional concerns/considerations:

• Granting additional access during the session can change the session's privacy properties, which the user agent may have carefully explained to the user when creating the session. This could lead to user confusion, frustration, etc. This is especially relevant if the spec or implementations choose to clearly scope the duration of consent (Duration of user consent #721) and explain the implications of the consent up front in the consent request UI (i.e., the "Augmented Reality Mode" approach; see also add permissions proposal #689 (comment)). For example, if an entry interstitial says "the application has access" then the application is allowed to request more access - the user may be confused or not understand the implications of combining those levels of access. (Originally discussed in add permissions proposal #689 (comment).)
• There is a similar issue related to existing/non-XR permissions - both those already granted and those that may be requested during the session. See Privacy: Interaction of existing permission-based features with WebXR feature consent #702.
• In both cases (additional consent for XR access and, especially, non-XR permissions, the UI may not be sufficient to explain such interactions, so the initial interstitial is a unique opportunity.

[NellWaliczek]

100% agree that if we allow UAs to defer requesting consent (assuming they have a Trusted Immersive UI to do so with) that we must normatively specifiy what API calls may trigger consent prompts. In fact, when we get there, I'm sort of imagining a set of internal variables which indicate the user consent status of various protections. Then we'd be able to update the function call algorithms to check the specific variable and trigger consent requests if necessary and allowed on that UA (otherwise reject). Does that make any sense?

For the bullets, I'm really curious to hear if other UAs share the sentiment that users may be confused by mid-session consent requests.

[ddorwin]

@NellWaliczek, that makes sense.

Separately, as noted in #719 (comment), a design where some user agents must always reject a request is another form of unexpected behavior that could be added to the first paragraph of #720 (comment) above.

[toji]

There's some relevant prior text in the privacy and security repo. In that document it sounds to me like "Traditional web permissions" can be understood as "mid-session prompt" for the purposes of this discussion, since the all prior web permissions have the behavior of being shown just-in-time at the point that the first call to access the permission-gated data is made. I'm not going to copy the entire text here, but the high-level considerations it puts forward regarding mid-session prompts are:

• Over-prompting and fatigue
• Ambiguity, Complexity
• Data access beyond the life of the session
• Consent vs. Notification
• User Control

It then lists a couple of mitigations that, as presented, were obviously written against an earlier stage of the spec's development but can still inform our current discussion: Time-limited permissions (The subject of #721) and what it labels "Augmented Reality Mode". (This was from a bygone era when we still through inline AR was a nifty idea.) AR mode in this case simply means requesting user consent prior to starting the session and/or notifying the user of the data in use, with the expectation that all consent was granted only while the session was active.

I'm operating on the assumption that enabling session creation time prompts is broadly seen as a useful option, and therefore the biggest question marks are around the potential use of mid-session prompts. My read on how the above text might apply here is largely that the we should clearly and consistently scope the duration of any mid-session consent with the creation-time consent, as will be determined by #721. Additionally in some cases notification rather than explicit consent may be appropriate to avoid over prompting. (Please note that I'm not attempting to evaluate how traditional web permissions, such as camera or location access, interact with XR sessions.)

[Edit: I see that David already linked the same doc. Sorry for re-treading a bit of the same ground!]

[avadacatavra]

100% agree that if we allow UAs to defer requesting consent (assuming they have a Trusted Immersive UI to do so with) that we must normatively specifiy what API calls may trigger consent prompts.

Also 100% agreed. Mid-session prompts should require a Trusted Immersive UI to prevent spoofing.

For the bullets, I'm really curious to hear if other UAs share the sentiment that users may be confused by mid-session consent requests.

We want to enable sophisticated and consciously developers to build web apps that provide as much opportunity for users as possible, even for those who are uncomfortable or unwilling provide all permissions that might be needed. (e.g., camera access).

Other issues(#723) have pointed out the mid-session requests require (a) leveraging the permissions API to enable developers to query if certain permissions have been granted, and (b) knowing what calls will trigger permissions requests, so they can tell users why a certain permission popup is about to happen. This seems essential if we're going to do mid-session.

It seems logical to do an initial permission request at XRSession startup, which includes all consent required for functionality. If there are advanced or optional features that may be enabled during the session (e.g. a camera enhancement), ideally, those should be handled as a mid-session request. For example, if I am using an app to help me pick out a new couch, initially, I only grant world geometry access to pick a couch that looks good in my room. Then, I want to enhance the experience by allowing camera access so the application can help me pick the right color.

I do think that UAs should have the option to choose to do all consent requests prior to session startup if they want, especially since mid-session requests will require the trusted immersive UI (which we don't have yet). In the future, when we do have this trusted UI, if UAs would like to do mid-session progressive enhancement, they should be allowed to. (One concern is that since we don't have the capability to do trusted mid-session prompts at the moment, developers will get used to having all consent requests handled at startup and never do the things required to support users with any progressive enhancement (even when we have that capability))

[NellWaliczek]

Chatted with Diane a bit over the phone and I think we maybe sorted through a few things...

1. For folks following along at home, there's an important distinction between "optional" and "deferrable" XR features. Optional XR features will be used from the very beginning of the session and shouldn't cause immediate prompting. Deferrable XR features are things that the developer will not use until later. This is discussed in much more detail in Required, optional, deferrable, and not-needed features #723.
2. There appears to be consensus that a deferrable feature must not cause a consent prompt in the middle of an Immersive session unless the UA has an acceptable Trusted Immersive UI solution (What is Trusted Immersive UI? #718)
3. There does not yet appear to be consensus on what a Trusted Immersive UI must do to satisfy normative security requirements (What is Trusted Immersive UI? #718)
4. There does not yet appear to be consensus on whether developers should be able to query if a mid-session function call will result in a consent prompt. There also does not appear to be consensus on whether that ability is a requirement for a UA to support deferrable features. (Querying user consent status #722, Should applications be able to determine that the user declined consent? #725)
5. Pretty much all of the contention around when consent can be requested seems to be based on the existence of deferrable features. In other words, everyone is on board with prompting for required and optional features before a session is created.

If that's an accurate summary, I'd like to propose we start off by landing text explainer/spec text for the timing of consent requests for required/optional features and that we should file a new issue to track the set of requirements for adding the concept of a deferrable feature. Given our timelines, I'd also like to propose that the new issue and #718 be assigned to the July milestone rather than the June one.

What do folks think?

[toji]

Nell's comment tracks with my feelings on this issue as well. I'm very much in favor of enabling sessions to defer enabling certain features, but it needs more design love than the current milestone can offer, while the two requestSession-time requirement levels appear to be well understood by everyone involved and can be implemented in a way that allows deferred options to be implemented additively.

[NellWaliczek]

Oh, and because I promised Diane and then failed to deliver... I'd like to clarify that my stance is that deferrable features are deferrable. ^_-

[joshmarinacci]

Works for me.

[avadacatavra]

@NellWaliczek summarized our conversation beautifully (with the addendum)--I'm on board with what she outlines above.

[blairmacintyre]

I think that makes sense, although some things aren’t clear from @NellWaliczek’s summary, so I wanted to check.

My understanding from chatting with @avadacatavra is that

• all features should be listed up front (required, optional, deferred)
• all deferrable features are optional. There are not “required but deferrable” features. Whiles it’s east to imagine that there are features you “must have but want to defer prompting till they are issued” this is explicitly not supported. So, if you want to defer “pose aligned camera” access till later since it’s only needed by one part of your experience, then camera access is optional, and that part of your experience is (by definition) not guaranteed to get access to the camera.

[toji]

To expand just a bit on the "There are not “required but deferrable” features." statement, to make sure everyone's on the same page:

In this context we're considering "required" to mean "The session isn't created unless you meet this criteria." As such "Required but deferrable" doesn't make sense for our narrow definition because we won't know if the requirement can be met until well after session creation, when the user is given the option to give consent or not. Developers, of course, have the option of ending the session if the deferred "requirement" is not met at the time it's finally requested. Whether or not that's a positive user experience is another thing entirely. 😉

[blairmacintyre]

That was my understanding @toji, I just wanted to make sure it’s explicit. Since on first blush, you can imagine someone thinking “I absolutely need X, so I don’t want to create the session unless it’s possible, but I don’t want to bug the user until later”

[NellWaliczek]

Ok, barring any last minute dissent, I'm gonna go forward with this approach and put a PR with some text together.

[probot-label]

This issue is fixed by PR #734