Duration of user consent

[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 user consent is required and granted, there are three options I’m aware of for how long user consent can last. (Note, this is not the issue for discussing what triggers UAs to request consent. That can be found in #720 )

• Session, which means each new XRSession would require new prompting
• Browsing-context, which is defined in the HTML Standard and implies user consent would be cumulative when multiple are XRSessions created in the same browsing context.
• Origin, which is defined in the HTML Standard and implies user consent would be cumulative for each XRSession created by that origin

Are there any other options I’ve left out? Is this a decision which can be left up to each User Agent or is this something that must be consistent across all? Are there minimum requirements for the duration based on the type of data being secured?

[toji]

Surfacing the relevant text from #638 privacy doc for easy reference:

Lifetime of Consent

The following guidelines are suggested:

• User consent should only be considered valid for the browsing context within which it was obtained.
• Once a specific consent is obtained for a specific origin in a browsing context, that origin does not need to obtain that specific consent again during the lifetime of that browsing context. Specifically, if multiple same-origin XRSession objects are created in a browsing context, and all require the same user consent, then consent should only need to be obtained once.
• The user agent must ensure that all mandatory conditions for user consent are met before creating any XRSession object. As a result, the user agent may be required to ask for user consent multiple times in a browsing context if it is creating multiple XRSession objects each with different mandatory conditions for user consent.

Note that this text uses the terms "guidelines" and "suggested", implying that there's room for UA discretion here. I feel that's appropriate, since most of the major UAs will likely want to take a more limited view of consent scope, but more purpose-built UAs (like Supermedium) or more app-like contexts such as PWAs may very reasonably want to allow for consent to persist across multiple browsing contexts.

And one clarification on Nell's original issue text: I presume that she intended the second "Browsing-context" bullet point to be scoped by both browsing context AND origin (this is what the text from #638 advocates for), with the third "Origin" bullet point implicitly meaning that the per-origin consent would persist across multiple browsing contexts.

[ddorwin]

The session-based Augmented Reality Mode concept is also relevant. It allows applications to provide detailed information about the implications of granting consent and defines a scope of consent that is easily understandable by users

[NellWaliczek]

To Brandon's question, I sort of avoided including origin because I didn't want to accidentally trigger a rat hole about cross-origin consent. However, yes, in the context of this particular discussion you are totally correct.

[NellWaliczek]

Ok, so maybe this was my misunderstanding... but when I read

The following guidelines are suggested:

I somehow interpreted that to mean the document was putting forward a suggestion but that the suggestion was for requirements everyone MUST follow. As opposed to the suggestion being a SHOULD in the spec. Does that even make sense? Was that a misinterpretation on my part?

[avadacatavra]

Deleted my previous comment because I'd misunderstood something and it turned into a red herring :)

I think that browsing context seems like a good default for the XR sensor lifetimes; however; we would like to give users the option to persist consent longer (i.e. origin).

[NellWaliczek]

@johnpallett, would the suggestion by @avadacatavra be acceptable based on your investigations?

If so, I'm gonna go forward with this approach and put a PR with some text together.

[johnpallett]

I somehow interpreted that to mean the document was putting forward a suggestion but that the suggestion was for requirements everyone MUST follow. As opposed to the suggestion being a SHOULD in the spec.

@NellWaliczek I can see how that would be confusing! The term "Suggest(ion)" in the design doc was intended to propose non-"MUST" requirements (whether a "SHOULD" or a "MAY" or something else such as a non-normative design consideration) because I wasn't sure how you and @toji wanted to handle them in the spec. I've added a note to the PR comment thread to reflect that as well. Sorry for the confusion.

@johnpallett, would the suggestion by @avadacatavra be acceptable based on your investigations?

Yes.

As one approach, the Permissions API has text related to 'New information about user's intent'. Is it worth considering similar text to give user agents flexibility in terms of how they determine user intent, and thus the duration of consent? Such text might also be useful more generally in terms of how user consent is solicited. That text reads as follows:

The UA may collect information about a user’s intentions in any way its authors believe is appropriate. This information can come from explicit user action, aggregate behavior of both the relevant user and other users, or implicit signals this specification hasn’t anticipated.

The implicit signals could be, for example, the install status of a web application or frequency and recency of visits. A user that has installed a web application and used it frequently and recently is more likely to trust it. Implementations are advised to exercise caution when relying on implicit signals.

[NellWaliczek]

Good to know! I'm working on a PR right now that I can incorporate that approach into. It's not at the spec text level yet, but that will be super helpful when we get there.

[probot-label]

This issue is fixed by PR #734