type: dfn; text: responsible; url: webappapis.html#responsible-document

type: dfn; text: same origin-domain; url: origin.html#same-origin-domain

type: dfn; text: active document; url: browsers.html#active-document

spec: SecureContexts; urlPrefix: https://w3c.github.io/webappsec-secure-contexts/#

type: dfn; text: secure context; url: secure-contexts

Sensitive Information {#sensitive-information-header}

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

In the context of XR, <dfn>sensitive information</dfn> includes, but is not limited to, user configurable data such as interpupillary distance (IPD) and sensor-based data such as {{XRPose}}s. All {{XRSessionMode/"immersive-vr"}} and {{XRSessionMode/"immersive-ar"}} sessions will expose some amount of sensitive data, due to the user's pose being necessary to render anything. However, in some cases, the same sensitive information will also be exposed via {{XRSessionMode/"inline"}} sessions.

### 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 of a [=secure context=], return <code>false</code>

1. If |document|'s origin is blocked by [[#feature-policy|feature policy]], return <code>false</code>

1. Return <code>true</code>

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

In addition to being [=trustworthy=], 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>

1. Return <code>true</code>

User intention {#user-intention}

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

It is often necessary to be sure of <dfn>user intent</dfn> before exposing sensitive information or allowing actions with a significant effect on the user's experience. This intent may be communicated or observed in a number of ways.

### User activation ### {#user-activation}

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

### Implicit and Explicit consent ### {#user-consent}

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.

It is often useful to get <dfn>explicit consent</dfn> from the user before exposing [=sensitive information=]. When gathering explicit user consent, user agents present an explanation of what is being requested and provide users the option to decline. Requests for user consent can be presented in many visual forms based on the features being protected and user agent choice.

### Duration of consent ### {#consent-duration}

It is recommended that once [=explicit consent=] is granted for a specific [=/origin=] that this consent persist until the [=/browsing context=] has ended. User agents may choose to lengthen or shorten this consent duration based upon implicit or explicit signals of [=user intent=], but implementations are advised to exercise caution when deviating from this recommendation, particularly when relying on implicit signals. For example, it may be appropriate for a web application installed with the express intent of running immersive content to persist the user's consent, but not for an installed web application where immersive content is a secondary feature.

Regardless of how long the user agent chooses to persist the user's consent, [=sensitive information=] MUST only be exposed by an {{XRSession}} which has not [=ended=].

Given that the API describes hardware available to the user and its capabilities it will inevitably provide additional surface area for fingerprinting. While it's impossible to completely avoid this, user agents should take steps to mitigate the issue. This spec limits reporting of available hardware to only a single device at a time, which prevents using the rare cases of multiple headsets being connected as a fingerprinting signal. Also, the devices that are reported have no string identifiers and expose very little information about the devices capabilities until an XRSession is created, which requires additional protections when [=sensitive information=] will be exposed.

In addition to the <code>"xr"</code> feature policy, feature policies for underlying sensors must also be respected if a site could isolate and extract sensor data that would otherwise be blocked by those feature policies.