Should applications be able to determine that the user declined consent?

[ddorwin]

This issue tracks determining whether it is okay for the API to expose (directly) that the user declined a request for user consent or otherwise chose not to allow the application to use XR functionality - vs., for example, just didn't have support in their user agent or platform.

Allowing the application to query user consent status (#722) is a direct route, but this can also be leaked in other ways, even if consent is not persisted.

For example, if requestSession() returns a different DOMException when consent is not given, this can also be used as a direct signal. On the other hand, if requestSession() always rejects with "NotSupportedError", it would no longer be trivial to determine that the user denied the request vs. doesn't have hardware. (This same concern may apply to use of different DOMException codes - and messages - for other failures that might expose information about the user's configuration. This specific case might still be inferred via timing.)

For consent that is persisted, with a little knowledge about specific implementations, applications might also be able to infer that the user has previously visited the origin even if they have cleared site data. For example, if a site always requests geolocation, the fact that the query result is not "prompt" could be a good signal that the user has previously visited the site (unless they have this disabled for all sites in the user agent's settings).

The ability to silently querying various permissions might also provide data for fingerprinting, especially for tracking across multiple visits to the same origin even after clearing site data.

(This was originally discussed in item 5 of #689 (comment).)

[johnpallett]

Relevant: The Permissions API privacy section outlines concerns about fingerprinting.

IIRC it was discussed on a call/at a f2f that sites could take punitive or repetitive action if they know that a feature is disabled due to user choice. Specific scenarios included repetitive prompts asking the user to change their mind, or outright refusing the entire experience unless the user enables the feature. Both scenarios depend upon the site knowing that the user has control over the feature (meaning, they could enable it) as opposed to the feature being unavailable for other reasons out of the user's control.

@blairmacintyre @avadacatavra I think you had thoughts on this?

[NellWaliczek]

Grabbing the section in the Permissions API and putting in here for reference

Privacy considerations

This section is non-normative.

An adversary could use a permission state as an element in creating a "fingerprint" corresponding to an end-user. Although an adversary can already determine the state of a permission by actually using the API, that often leads to a permission request UI being presented to the end-user (if the permission was not already "granted"). Thus, even though this API doesn’t expose new fingerprinting information to websites, it makes it easier for an adversary to have discreet access to this information. Thus, implementations are encouraged to have an option for users to block (globally or selectively) the querying of permission states.

[NellWaliczek]

I keep coming back to two questions:

1. How much does the 2D web worry about a given problem?
2. Is there a substantive difference in concerns introduced by becoming immersive?

To be honest, I'm not super clear on the answer to question 1. Though if I'm just to examine the text from the Permissions API seems to give user agents a lot of leeway, it leads me to believe WebXR doesn't need to address this normatively unless we also think the answer to question 2 is "yes". Reading through the comments in this thread so far, I'm not seeing anything that's leading me to believe that to be the case, though.

Perhaps I'm missing something?

[avadacatavra]

I don't believe there's a substantive difference--the 2D web seems to have found consensus on the permissions API (unless I'm unaware of something and if so, let me know). It's important to maintain consistency so we don't violate user expectations around consent, which seems to imply that we should follow the lead of the permissions API unless there's different considerations for the XR consent (and I don't think there are).

Am I missing something?

[johnpallett]

For context, I spoke with our team about this a bit more. The query() part of the Permissions API has indeed been adopted by several browsers including Chrome and Firefox.

As a consideration, my understanding is that some sites have written logic based on this capability, in some cases disabling features not because the user didn't want them, but to avoid prompt friction. That scenario arguably isn't ideal as it hides capabilities from the user that they might want. As we move into exploration around 'optional' WebXR features (particularly features that offer incremental improvements to the experience), a consideration might be whether the site, or the user agent, should manage prompting for those features to ensure that the user knows the features are available.

None of this is to say that query() is 'good' or 'bad', rather that there are some patterns that might be worth considering.

[rcabanier]

User agents and user very likely want to use the same permission workflow to keep track of the WebXR permission status.
The group should reach out the group that maintains the permission API so we standardize on a new value for XR. (This is the value that an author would pass to the query or requestPermision APIs)

FYI This is the workflow that Magic Leap implemented

[Manishearth]

/agenda to be discussed alongside #722

[mounirlamouri]

User agents and user very likely want to use the same permission workflow to keep track of the WebXR permission status.
The group should reach out the group that maintains the permission API so we standardize on a new value for XR. (This is the value that an author would pass to the query or requestPermision APIs)

FYI This is the workflow that Magic Leap implemented

I am in support of that. I believe that XR would benefit from relying on the Permissions API.

[rcabanier]

I believe @toji filed an issue against the permission spec but I can no longer find where we had that conversation on github

[toji]

@rcabanier: You may be thinking of w3c/webappsec-permissions-policy#343, which is against the feature policy repo, not the permissions spec. (Also, it was un-findable because I apparently completely misunderstood GitHub's inline editing tool and missed that I needed to manually submit a pull request with the branch that it created for me until just now. 🙄)

[rcabanier]

@toji I see.
Then we should also file an issue against the Permissions Spec. As I mentioned during TPAC, Magic Leap is using another permission name because the spec hadn't defined one yet and we wanted to rely on the existing permission architecture.