WebXR Privacy and Security Guidelines

1. Privacy and security

The WebXR Device API enables developers to build content for AR and VR hardware that uses one or more sensors to infer information about the real world, and may then present information about the real world either to developers or directly to the end user. In such systems there are a wide range of input sensor types used (cameras, accelerometers, etc), and a variety of real-world data generated. This data is what allows web developers to author WebXR-based experiences. It also enables developers to infer information about users such as profiling them, fingerprinting their device, and input sniffing. Due to the nature of the Web, WebXR has a higher responsibility to protect users from malicious data usage than XR experiences delivered through closed ecosystem app stores.

1.1. Concepts

1.1.1. Sensitive information

1.1.2. Device Fingerprinting

Some raw sensor data might be fingerprinted (e.g. IMU data) and thus on some user agents access to that raw sensor data outside of WebXR requires user consent. In cases where the same sensor fingerprinting risk exists for WebXR data, explicit consent is strongly recommended if the user agent does not anonymize the data sufficiently to mitigate the risk.

Specific approaches to mitigating device fingerprinting are up to the user agent, which is best equipped to evaluate the actual threat on a given platform.

1.1.3. User Profiling

Such consent is strongly recommended even if only _some_ users could be profiled. For example, user-configured IPD data might allow a site to determine the race, gender, or age of some users, so explicit consent is strongly recommended for all users (even though a strong signal might only be available for a small proportion of the total population).

This recommendation is _not_ made in cases where data provides only a weak signal for all users, or where the information inferred is not particularly sensitive. For example, while the size of a user’s room could (in theory) indicate a user’s wealth, it might just as easily indicate that a user is at work; this ambiguity suggests the signal is unreliable and thus explicit consent is not strongly recommended.

1.1.4. Private Browsing modes

There is no persistent data or unique user identifier data generated by the WebXR Device API. As such, there are no additional requirements for such modes.

2. Protection types

2.1. Trustworthy documents and origins

• Responsible

• Of a secure context

• The currently focused area

• Of the same origin-domain as the active document

• Of an origin not blocked by feature policy

2.1.1. Focus and visibility

In this situation, WebXR must be structured to protect users from 'input sniffing,' for example, using pose data to infer what keyboard input a user has typed during password entry. For this reason, pose data should only be available to a session that is visible and same-origin to the currently focused area while a Trusted UI is displayed to the user.

However, visible-blurred should not be viewed as a substitute for TrustedUI and applications should not infer that visible-blurred state indicates that the user is performing a sensitive task.

2.1.2. Feature policy

2.1.2.1. Underlying sensors feature policy

2.2. Trusted UI

In 2D browsers, Trusted UI is presented either exclusively around the outside of a web page’s visual container or overlapping with it partially. In the context of an immersive experience, the definition of a “Trusted Immersive UI” is a bit more complex due to the fact there is no “outside” of immersive content; all pixels the user sees are rendered by the immersive content.

User agents must support a Trusted UI with the following properties:

• non-spoofable

• indicates where the request/content displayed originates from

• if it relies on a shared secret with the user, the shared secret must be unobservable by an MR capture

• it is consistent between immersive experiences in the same UA

• avoid spamming/overloading the user with prompts

• easy to intentionally grant consent (e.g. the UI should be easily discovered)

• hard to unintentionally grant user consent (e.g. the UI should prevent clickjacking)

• provides clear methods for the user to revoke consent and verify the current state of consent

A Trusted UI may be immersive or non-immersive, provided it conforms to the above properties. A Trusted Immersive UI does not exit immersive mode. UAs are not required to provide a Trusted Immersive UI and may instead temporarily pause/exit immersive mode and provide a non-immersive Trusted UI.

Examples of Trusted UIs are:

• the default 2D mode browser in non-immersive mode

• a prompt shown within immersive mode which can only be interacted with via a reserved hardware button

• pausing the immersive session to show a form of non-spoofable native system environment

2.3. User intention

2.3.1. User activation

2.3.2. Implied consent

2.3.3. Explicit consent

2.3.4. Duration of consent

2.4. Data adjustments

2.4.1. Throttling

2.4.2. Rounding, quantization, and fuzzing

2.4.3. Limiting

3. Protected functionality

3.1. Immersiveness

Developers indicate the desire to create an immersive session by passing immersive-vr into xr.requestSession().

// VR button click handler
function onVRClick() {
  xr.requestSession('immersive-vr').then(onVRSessionCreated);
}

In response, the UA must ensure that:

• The function was invoked in response to a user activation event

• The request originates from a trustworthy document and origin

• The request originates from a document that is visible and has focus

• The request originates from a document allowed to use the WebXR feature policy as well as the underlying sensors' feature policies

• User intention is well understood, either via explicit consent or implied consent

If these requirements are not met, the promise returned from requestSession() must reject.

3.2. Poses

3.2.1. XRPose

Developers indicate the desire for XRPose data by calling XRFrame.getPose().

function onSessionRafCallback(XRFrame frame) {
    let motionControllerPose = frame.getPose(xrSession.inputSources[0], xrReferenceSpace);
}

For every call to XRFrame.getPose(), the UA must ensure that:

• User intention is well understood, either via explicit consent or implied consent; alternatively, in cases where the user experience is not negatively affected, data adjustments may be applied to prevent the fingerprinting of underlying sensor data

• The request originates from the document which owns the XRFrame’s XRSession

• The document is visible and has focus

• The XRSession.visibility is set to visible

Note: On some systems it is possible that XRPose data may allow a site to fingerprint a device through sensor calibration data (ref: 1, 2, 3). This risk may vary depending upon hardware, operating system, and the methods used to generate pose data from sensors. User agents must either mitigate such fingerprinting risk, or be sure of user intent before exposing such data.

3.2.2. XRViewerPose

Developers indicate the desire for XRViewerPose data by calling XRFrame.getViewerPose().

function onSessionRafCallback(XRFrame frame) {
    let viewerPose = frame.getViewerPose(xrReferenceSpace);
}

In addition to meeting the XRPose requirements, every call to XRFrame.getViewerPose() which will return more than one XRView must additionally ensure that:

• User intention is well understood, either via explicit consent or implied consent

• If XRView data is affected by settings that may vary from device to device, such as static interpupillary distance, variations in screen geometry, or user-configured interpupillary distance, then the XRView data must be anonymized to prevent fingerprinting. Specific approaches to this are at the discretion of the user agent.

• If XRView data is affected by a user-configured interpupillary distance, then it is strongly recommended that the UA require explicit consent prior to the creation of the XRReferenceSpace passed into XRFrame.getViewerPose().

Note: Interpupillary distance may allow a site to reliably determine sensitive user characteristics such as age, race and gender. It is strongly recommended that user agents seek explicit consent before exposing data where a site could learn the user’s actual interpupillary distance. Given the sensitivity of this data, caution is advised when relying upon implicit signals.

3.3. Reference spaces

3.3.1. Unbounded reference spaces

Developers indicate the desire for unbounded viewer tracking at the time of session creation by adding unbounded to either XRSessionInit.requiredFeatures or XRSessionInit.optionalFeatures.

function onXRClick() {
  xr.requestSession('immersive-vr', { requiredFeatures: ['unbounded'] } )
  .then(onARSessionCreated);
}

In response the UA must ensure that:

• The document is allowed to use all the policy-controlled features associated with the sensor types used to track the native origin of an unbounded reference space

• User intention is well understood, either via explicit consent or implied consent

• The XR device is capable of unbounded tracking

If these requirements are not met and unbounded is listed in XRSessionInit.requiredFeatures then the promise returned from requestSession() must be rejected. Otherwise, the promise may be fulfilled but future calls to XRSession.requestReferenceSpace() must fail when passed unbounded.

Once a session is created, developers may attempt to create an unbounded reference space by passing unbounded into XRSession.requestReferenceSpace().

let xrReferenceSpace;
function onSessionCreated(session) {
  session.requestReferenceSpace('unbounded')
  .then((referenceSpace) => { xrReferenceSpace = referenceSpace; })
  .catch( (e) => { /* handle gracefully */ } );
}

Note: Unbounded coordinate systems may allow a site to determine the user’s geographic location, for example by matching trajectory data with known patterns such as roadways or paths. It is strongly recommended that user agents seek explicit consent with an explanation that the user’s location may be determined. Given the sensitivity of this data, caution is advised when relying upon implicit signals.

3.3.2. Bounded reference spaces

Developers indicate the desire for bounded viewer tracking at the time of session creation by adding bounded-floor to either XRSessionInit.requiredFeatures or XRSessionInit.optionalFeatures.

function onVRClick() {
  xr.requestSession('immersive-vr', { requiredFeatures: ['bounded-floor'] } )
  .then(onVRSessionCreated);
}

xr.requestSession('inline', { optionalFeatures: ['bounded-floor'] } )
  .then(onInlineSessionCreated);
}

In response, the UA must ensure that:

• The document is allowed to use all the policy-controlled features associated with the sensor types used to track the native origin of a bounded reference space

• User intention is well understood, either via explicit consent or implied consent

• The device is capable of bounded tracking

If these requirements are not met and bounded-floor is listed in XRSessionInit.requiredFeatures then the promise returned from requestSession() must be rejected. Otherwise, the promise may be fulfilled but future calls to XRSession.requestReferenceSpace() must fail when passed bounded-floor.

Once a session is created, developers may attempt to create a bounded reference space by passing bounded-floor into XRSession.requestReferenceSpace().

let xrReferenceSpace;
function onSessionCreated(session) {
  session.requestReferenceSpace('bounded-floor')
  .then((referenceSpace) => { xrReferenceSpace = referenceSpace; })
  .catch( (e) => { /* handle gracefully */ } );
}

In response, the UA must ensure that:

• Bounded reference spaces are allowed to be created based on the restrictions above

• Any group of local, local-floor, and bounded-floor reference spaces that are capable of being related to one another must share a common native origin; this restriction does not apply when unbounded reference spaces are also able to be created

• XRBoundedReferenceSpace.boundsGeometry must be limited to a reasonable distance from the reference space’s native origin; the suggested default distance is 15 meters in each direction

• Each point in the XRBoundedReferenceSpace.boundsGeometry must be rounded sufficiently to prevent fingerprinting while still ensuring the rounded bounds geometry fits inside the original shape. Rounding to the nearest 5cm is suggested.

• If the floor level is based on sensor data or is set to a non-default emulated value, the y value of the native origin must be rounded sufficiently to prevent fingerprinting of lower-order bits; rounding to the nearest 1cm is suggested

• All XRPose and XRViewerPose 6DoF pose data computed using a bounded-floor reference space must be limited to a reasonable distance beyond the boundsGeometry in all directions; the suggested distance is 1 meter beyond the bounds in all directions

If these requirements are not met, the promise returned from XRSession.requestReferenceSpace() must be rejected.

Note: Viewer height may allow a site to reliably determine sensitive user characteristics such as age. It is strongly recommended that user agents seek explicit consent while warning the user that their height may be determined. Given the sensitivity of this data, caution is advised when relying upon implicit signals.

3.3.3. Local-floor spaces

Developers indicate the desire for local-floor viewer tracking at the time of session creation by adding local-floor to either XRSessionInit.requiredFeatures or XRSessionInit.optionalFeatures.

function onVRClick() {
  xr.requestSession('immersive-vr', { requiredFeatures: ['local-floor'] } )
  .then(onVRSessionCreated);
}

In response, the UA must ensure that:

• The document is allowed to use all the policy-controlled features associated with the sensor types used to track the native origin of a local-floor reference space

• User intention is well understood, either via explicit consent or implied consent

• The device is capable of local-floor tracking

If these requirements are not met and local-floor is listed in XRSessionInit.requiredFeatures then the promise returned from requestSession() must be rejected. Otherwise, the promise may be fulfilled but future calls to XRSession.requestReferenceSpace() must fail when passed local-floor.

Once a session is created, developers may attempt to create local-floor reference spaces by passing local-floor into XRSession.requestReferenceSpace().

let xrReferenceSpace;
function onSessionCreated(session) {
  session.requestReferenceSpace('local-floor')
  .then((referenceSpace) => { xrReferenceSpace = referenceSpace; })
  .catch( (e) => { /* handle gracefully */ } );
}

In response, the UA must ensure that:

• local-floor reference spaces are allowed to be created based on the restrictions above

• Any group of local, local-floor, and bounded-floor reference spaces that are capable of being related to one another must share a common native origin; this restriction does not apply when unbounded reference spaces are also permitted to be created

• If the floor level is based on sensor data or is set to a non-default emulated value, the y value of the native origin must be rounded sufficiently to prevent fingerprinting of lower-order bits; rounding to the nearest 1cm is suggested

• All XRPose and XRViewerPose 6DoF pose data computed using a local-floor reference space is limited to a reasonable distance from the reference space’s native origin; the suggested default distance is 15 meters in each direction

If these requirements are not met, the promise returned from XRSession.requestReferenceSpace() must be rejected.

Note: Viewer height may allow a site to reliably determine sensitive user characteristics such as age. It is strongly recommended that user agents seek explicit consent while warning the user that their height may be determined. Given the sensitivity of this data, caution is advised when relying upon implicit signals.

3.3.4. Local reference spaces

When creating an immersive session, developers do not need to explicitly request the desire for local viewer tracking. However, this desire must be indicated when creating an inline session by adding local to either XRSessionInit.requiredFeatures or XRSessionInit.optionalFeatures.

xr.requestSession('inline', { optionalFeatures: ['local'] } )
  .then(onInlineSessionCreated);
}

function onVRClick() {
  xr.requestSession('immersive-vr')
  .then(onVRSessionCreated);
}

In response, the UA must ensure that:

• The document is allowed to use all the policy-controlled features associated with the sensor types used to track the native origin of a local reference space

• If the session mode is inline, user intention is well understood, either via explicit consent or implied consent

• The device is capable of local tracking

If the session is immersive and these requirements are not met then the promise returned from requestSession() must be rejected. If the session is inline and has local listed in XRSessionInit.requiredFeatures then the promise returned from requestSession() must also be rejected. Otherwise, the promise may be fulfilled but future calls to XRSession.requestReferenceSpace() must fail when passed local.

Once a session is created, developers may attempt to create local reference spaces by passing either local into XRSession.requestReferenceSpace().

let xrReferenceSpace;
function onSessionCreated(session) {
  session.requestReferenceSpace('local')
  .then((referenceSpace) => { xrReferenceSpace = referenceSpace; })
  .catch( (e) => { /* handle gracefully */ } );
}

In response, the UA must ensure that:

• local reference spaces are allowed to be created based on the restrictions above

• Any group of local, local-floor, and bounded-floor reference spaces that are capable of being related to one another must share a common native origin; this restriction does not apply when unbounded reference spaces are also permitted to be created

• All XRPose and XRViewerPose 6DoF pose data computed using a local reference space is limited to a reasonable distance from the reference space’s native origin; the suggested default distance is 15 meters in each direction

If these requirements are not met, the promise returned from XRSession.requestReferenceSpace() must be rejected.