1. If [=user intent=] to [[#issessionsupported-fingerprinting|avoid advertising their system's XR capabilities]] is well understood, [=queue a task=] to [=/resolve=] |promise| with <code>false</code> and abort these steps.

A set of user agents is <dfn>indistinguishable by user-agent string</dfn> if they all report the same {{NavigatorID/userAgent}} and {{NavigatorID/appVersion}}. Such classes are typically identified by the browser version and platform/device being run on, but cannot be distinguished by the status of any connected external device. We can use the concept of user agents that are [=indistinguishable by user-agent string=] to properly assess fingerprinting risk.

Because {{XRSystem/isSessionSupported()}} can be called without user activation it may be used as a fingerprinting vector despite the limited amount of information it reports. To reduce the amount of unique information that can be derived from the method, user agents should consider the following mitigations:

Some user agents [=indistinguishable by user-agent string=] will <dfn>never support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents running on a model of phone that is known to not meet requirements for mobile AR support.</span> In these cases there is little fingerprinting risk in {{XRSystem/isSessionSupported()}} always reporting the {{XRSessionMode}} is not supported because every such device will consistently report the same value and it's assumed that device type and model can be inferred in other ways, such as through {{NavigatorID/userAgent}}.

Other user agents will [=indistinguishable by user-agent string=] <dfn>usually support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents known to support WebXR that run exclusively within VR headsets are likely to support {{XRSessionMode/"immersive-vr"}} sessions unless specifically blocked by the user.</span> In these cases reporting that the {{XRSessionMode}} is not supported, while accurate, would offer more uniquely identifying information about the user. As such reporting that the {{XRSessionMode}} is always available and allowing {{XRSystem/requestSession()}} to fail is more privacy-preserving while likely not being a source of confusion for the user.

User agents [=indistinguishable by user-agent string=] for which availability of XR capabilities is highly variable, such as desktop systems which support XR peripherals, present the highest fingerprinting risk. User agents on such devices MUST NOT allow the {{isSessionSupported()}} API to provide additional fingerprinting bits without there being [=explicit consent=] from the user to do so. This MAY involve one of the following techniques:

- Always judging [=explicit consent=] (with a potentially cached permissions prompt or similar) when {{XRSystem/isSessionSupported()}} is called.

- Have {{XRSystem/isSessionSupported()}} always report <code>true</code> even on platforms which do not consistently have XR capabilities available, regardless of whether or not the appropriate hardware or software is present. <span class=note>This comes at the cost of user ergonomics, as it will cause pages to advertise XR content to users that cannot view it.</span>

- Have {{XRSystem/isSessionSupported()}} request [=explicit consent=] when the appropriate hardware is present, and when such hardware is _not_ present, return <code>false</code> after an appropriately random length of time. In such an implementation content MUST NOT be able to distinguish between cases where the user agent was not connected to XR hardware and cases where the user agent was connected to XR hardware but the user declined to provide [=explicit consent=].