1. Check if an [=immersive session request is allowed=], and if not [=reject=] |promise| with a "{{SecurityError}}" {{DOMException}} and return |promise|.

1. If |immersive| is <code>false</code>:

1. Check if an [=inline session request is allowed=], and if not [=reject=] |promise| with a "{{SecurityError}}" {{DOMException}} and return |promise|.

The combined list of [=feature names=] given by the {{XRSessionInit/requiredFeatures}}, {{XRSessionInit/optionalFeatures}}, and [=default features=] are collectively considered the <dfn>requested features</dfn> for an {{XRSession}}.

1. Check if [=poses may be reported=] and, if not, throw a {{SecurityError}} and abort these steps.

### Active and focused document ### {#active-and-focused-document}

A document MUST be [=active and focused=] at the time that [=sensitive information=] is requested.

To determine if a given {{Document}} |document| is <dfn>active and focused</dfn> the user agent MUST run the following steps:

1. If the [=currently focused area=] does not belong to |document|, return <code>false</code>

1. If |document| is not of the [=same origin-domain=] as the [=active document=], return <code>false</code>

### Trustworthy documents and origins ### {#trustworthy-documents}

In order to expose any [=sensitive information=] the requesting document MUST be considered [=trustworthy=].

To determine if a given {{Document}} |document| is <dfn>trustworthy</dfn> the user agent MUST run the following steps:

1. If |document| is not a [=responsible=] document, return <code>false</code>

1. If |document| is not [=active and focused=], return <code>false</code>

1. If |document|'s origin is not allowed to use the WebXR [[#feature-policy|feature policy]], return <code>false</code>

Events which are [=triggered by user activation=] MAY serve as an indication of [=user intent=] in some scenarios.

### Launching a web application ### {#application-launch}

In some environments a page may be presented as an application, installed with the express intent of running immersive content. In that case <dfn>launching a web application</dfn> MAY also serve as an indication of [=user intent=].

A user agent MAY use <dfn>implicit consent</dfn> based, for example, on the install status of a web application or frequency and recency of visits. Given the sensitivity of XR data, caution is strongly advised when relying on implicit signals.

Data adjustments {#data-adjustments-header}

----------------

In some cases, security and privacy threats can be mitigated through <dfn>data adjustment</dfn>s such as throttling, quantizing, rounding, limiting, or otherwise manipulating the data reported from the [=/XR device=]. This may sometimes be necessary to avoid fingerprinting, even in situations when [=user intent=] has been established. However, [=data adjustment=] mitigations MUST only be used in situations which would not result in user discomfort.

### Throttling ### {#throttling}

Throttling is when [=sensitive information=] is reported at a lower frequency than otherwise possible. This mitigation has the potential to reduce a site's ability to infer user intent, infer location, or perform user profiling. However, when not used appropriately throttling runs a significant risk of causing user discomfort. In addition, under many circumstances it may be inadequate to provide a complete mitigation.

### Rounding, quantization, and fuzzing ### {#rounding-and-friends}

Rounding, quantization, and fuzzing are three categories of mitigations that modify the raw data that would otherwise be returned to the developer. Rounding decreases the precision of data by reducing the number of digits used to express it. Quantization constrains continuous data to instead report a discrete subset of values. Fuzzing is the introduction of slight, random errors into the the data. Collectively, these mitigations are useful to avoid fingerprinting, and are especially useful when doing so does not cause noticeable impact on user comfort.

### Limiting ### {#limiting}

Limiting is when data is reported only when it is within a specific range. For example, it is possible to comfortably limit reporting positional pose data when a user has moved beyond a specific distance away from an approved location. Care should be taken to ensure that the user experience is not negatively affected when employing this mitigation. It is often desireable to avoid a 'hard stop' at the at the end of a range as this may cause disruptive user experiences.

Protected functionality {#protected-functionality}

-----------------------

The [=sensitive information=] exposed by the API can be divided into categories that share threat profiles and necessary protections against those threats.

### Immersiveness ### {#protect-immersiveness}

Users must be in control of when immersive sessions are created because the creation causes invasive changes on a user's machine. For example, starting an [=immersive session=] will engage the [=/XR device=] sensors, take over access to the device's display, and begin presentating immersive content which may terminate another application's access to the XR hardware. It may also incur significant power or performance overhead on some systems or trigger the launching of a status tray or storefront.

To determine if an <dfn>immersive session request is allowed</dfn> the user agent MUST run the following steps:

1. If the request was not [=triggered by user activation=] or [=launching a web application=], return <code>false</code>

1. If the requesting document is not considered [=trustworthy=], return <code>false</code>

1. If [=user intent=] to begin an [=immersive session=] is not well understood, either via [=explicit consent=] or [=implicit consent=], return <code>false</code>

1. Return <code>true</code>

Starting an {{XRSessionMode/"inline"}} session does not implicitly carry the same requirements, though additional requirements may be imposed depending on the session's [=requested features=].

To determine if an <dfn>inline session request is allowed</dfn> the user agent MUST run the following steps:

1. If the session request contained any [=required features=] or [=optional features=] and the request was not [=triggered by user activation=] or [=launching a web application=], return <code>false</code>

1. If the requesting document is not [=responsible=], return <code>false</code>

1. If requesting document's origin is not allowed to use the WebXR [[#feature-policy|feature policy]] return <code>false</code>

1. Return <code>true</code>

### Poses ### {#protect-poses}

When based on sensor data, {{XRPose}} and {{XRViewerPose}} will expose [=sensitive information=] that may be misused in a number of ways, including input sniffing, gaze tracking, or fingerprinting.

To determine if <dfn>poses may be reported</dfn> to an {{XRSession}} |session|, the user agent MUST run the following steps:

1. Let |document| be the document that owns |session|.

1. If the request does not originate from |document|, return <code>false</code>.

1. If |document| is not [=active and focused=], return <code>false</code>.

1. If |session|'s {{XRSession/visibilityState}} in not {{XRVisibilityState/"visible"}}, return <code>false</code>.

1. Determine if the pose data can be returned as follows:

<dl class="switch">

<dt> If the pose data is known by the user agent to not expose fingerprintable sensor data

<dd> Return <code>true</code>.

<dt> If [=data adjustments=] will be applied to the underlying sensor data to prevent fingerprinting or profiling

<dd> Return <code>true</code>.

<dt> If [=user intent=] is well understood, either via [=explicit consent=] or [=implicit consent=]

<dd> Return <code>true</code>.

<dt> Otherwise

<dd> Return <code>false</code>.

</dl>

Note: The method by which a user agent determines that poses do not expose fingerprintable data is left to the user agent's discretion.

The primary difference between {{XRViewerPose}} and {{XRPose}} is the inclusion of {{XRView}} information. When more than one view is present and the physical relationship between these views is configurable by the user, the relationship between these views is considered [=sensitive information=] as it can be used to fingerprint or profile the user.

If the relationship between {{XRView}}s could uniquely identify the [=/XR device=], then the user agent MUST anonymize the {{XRView}} data to prevent fingerprinting. The method of anonymization is at the discretion of the user agent.

Note: Furthermore, if the relationship between {{XRView}}s is affected by a user-configured interpupillary distance, then it is strongly recommended that the user agent require [=explicit consent=] during session creation, prior to reporting any {{XRView}} data.