This design adopts the requirements of the Generic Sensors API when exposing data based on sensors.
Further, when allowing access to any sensor-based data (ex. poses) or user configurable data (ex. IPD, bounds), the user agent must either apply all necessary mitigations to ensure user privacy, or obtain user consent at session creation in response to requestSession().
In some scenarios, mitigations may not be sufficient to ensure user privacy. In those situations, user consent is required. For example, user consent is always required when exposing data that might allow a site to profile the user. A summary of scenarios where user consent is required can be found under User Communication.
Further, some mitigations are always required even if user consent is obtained (ex. focused and visible is always required before exposing pose data).
User consent must be requested only in response to requestSession(). It is recommended that consent last as long as the browsing context. User consent cannot be obtained during an active session, as there is no known approach for a trusted user interface that works consistently across all platforms during an active session.
When creating a session, all privacy-sensitive data that could be exposed during that session must be considered when determining whether or not user consent is required. If user consent is not granted for a particular data type, then either:
- Other mitigations for that data type must be applied to ensure user privacy, or
- Any feature that would expose that data type must be disabled, or
- The session request must be rejected.
Not all sessions require user consent, such as:
- Sessions that do not include any sensor-based or user-configured data;
- Sessions that fully mitigate sensor-based privacy concerns (ex. pose quantization and position bounds) and which do not include user-configured data that could be used for profiling.
There is no distinction between different WebXR modes in this document. The requirements to expose any given data type are the same whether the session is inline, immersive, or otherwise. If a user agent wants to avoid user consent for a particular type of session, the user agent must meet the mitigation requirements to expose all of the data types available in that session.
However, not all modes and platforms support all types of data, and some mitigation strategies that work in one mode may not work in other modes or on other platforms. As a result, the actual requirements for each mode and platform will vary. For example, if in an inline session a user agent only supports the viewer reference space, does not support other forms of sensor-based data (e.g. from a 6DOF controller), and does not support multiple views, then all privacy requirements have been met and user consent is not required for that session. In contrast, an immersive session supporting the unbounded reference space type with a native origin that is tracked using sensors would have different requirements for user consent and privacy mitigations.
The user agent must ensure the following requirements are met before enabling the corresponding WebXR feature or allowing access to associated data. This table is intended as a summary, more detail on each requirement is available in subsequent sections.
Note: Some features have more than one requirement and appear in multiple rows.
| Feature | Requirements | Why |
| Any native origin or combination of native origins that allow calculation of real-world viewer movement. |
Position Limiting for all pose data generated by all XRSpaces in the session
OR User consent. |
The site may infer the user’s geographic location from unbounded pose data. |
| Pose data |
Same Origin
AND Focused and Visible |
Prevents Input Sniffing |
| Access to data generated by sensors |
Generic Sensor API requirements
AND Feature policies for underlying sensors are respected. |
Prevents access to sensor data outside the scope of the requirements for the lower-level sensors. |
| Viewer Height based on real world height | User consent | Site may profile user |
| Emulated Viewer Height set by user | Rounding | Site may fingerprint device |
| boundsGeometry | Rounding | Site may fingerprint device |
| Configurable IPD as exposed by multiple Views |
Rounding
AND User consent |
Site may profile user.
Site may fingerprint device based upon specific IPD distance. |
| Multiple displays whose positions and orientations have been configured by the user (e.g. a CAVE system) | Rounding | Site may fingerprint device |
| XRPose data generated by sensors |
Quantization
OR User consent |
Site may fingerprint device |
The user agent must verify that all mandatory conditions are satisfied to ensure it can create an XRSession and expose XRSession data in response to a call to XRRequestSession within a given active document.
The mandatory conditions for XRSession creation are the following:
- The document is a responsible document of a secure context.
- Currently focused area belongs to a document whose origin is same origin-domain with the origin of the given active document.
- The document is allowed to use all the policy-controlled features associated with the given sensor types of sensors used to generate data available in the XRSession. This includes sensors used to generate XRViewerPose, XRPose and XRBoundedReferenceSpace data, and any other data generated by sensors. Note: The intent of this requirement is to ensure that WebXR does not allow a site to isolate and extract sensor data that would otherwise be blocked by feature policy.
- User consent is required before creating an XRSession when the XRSession will support the creation and use of bounded-floor or unbounded reference space types.
- User consent is required before creating an XRSession when the XRSession will support the creation and use of a local-floor reference space type, and the floor level will reflect the real-world location of the user’s floor.
- User consent is required before creating an XRSession on a device with configurable interpupillary distance (IPD), if subsequent calls to XRFrame.getViewerPose() will return XRView.transforms that can be used to compute the configured IPD.
- User consent is required before creating an XRSession if the user agent does not otherwise mitigate sensor fingerprinting threats through data access to XRViewerPose or XRPose.
If user consent is required, it must be obtained as part of the XRRequestSession algorithm before the new XRSession object is created. If the required consent is not obtained, the user agent MUST reject the promise with a "SecurityError" DOMException.
Editor Note: The paragraph above suggests specific changes to the XRSession algorithm language.
The user agent must verify that all mandatory conditions are satisfied to ensure it can expose XRViewerPose data in response to each call to getViewerPose within a given active document.
The mandatory conditions for exposing XRViewerPose data are the following:
- Visibility state of the document is "visible".
- Currently focused area belongs to a document whose origin is same origin-domain with the origin of the given active document.
- The document is allowed to use all the policy-controlled features associated with the given sensor types of sensors used to generate XRViewerPose data.
- If the reference space is of type local, local-floor, or bounded-floor, then the XRViewerPose data must be limited to a region approximately the size of a large room, to prevent such data from being used to determine the user’s real-world location. Specific bounds are at the discretion of the user agent, but 30m x 30m is suggested as a reasonable limit. These bounds may be affected by previously created reference spaces.
- If XRViewerPose data is generated by sensors, at least one of the following conditions must be met to mitigate sensor fingerprinting threats; the user agent may choose the approach that provides the best user experience:
- User consent must have been obtained on devices with configurable interpupillary distance before creating an XRViewerPose that will return an XRView for each eye.
- If the device supports configurable or factory-calibrated interpupillary distance that may vary from device to device, then the XRView transform data must be rounded to prevent fingerprinting. Specific precision for rounding is at the discretion of the user agent.
- If the XRViewerPose will include multiple XRViews for displays whose positions and orientations have been configured by the user (e.g. in a CAVE) then the XRView transform data must be rounded to prevent fingerprinting.
The user agent must verify that all mandatory conditions are satisfied to ensure it can expose XRPose data in response to each call to getPose within a given active document.
The mandatory conditions for exposing XRPose data are the following:
- Visibility state of the document is "visible".
- Currently focused area belongs to a document whose origin is same origin-domain with the origin of the given active document.
- The document is allowed to use all the policy-controlled features associated with the given sensor types of sensors used to generate the inputs getPose.
- If an input to getPose has a native origin that tracks a real-world location (e.g. a 6DOF controller) then the resulting XRPose data must be bounded by the same position limiting as for getViewerPose, to prevent such data from being used to determine the user’s real-world location. Note: If getViewerPose is performed from a viewer reference space, then this position limiting requirement does still apply.
- If an input to getPose is a reference space of type local, local-floor, or bounded-floor, then the resulting XRPose data must be bounded by the same position limiting for that reference space as getViewerPose, to prevent such data from being used to determine the user’s real-world location. See: Providing XRViewerPose data.
- If an input to getPose includes data generated by sensors, at least one of the following conditions must be met to mitigate sensor fingerprinting threats; the user agent may choose the approach that provides the best user experience:
- User consent must have been obtained, or
- Any transform data generated by sensors must be quantized to prevent sensor fingerprinting, or
- The user agent must otherwise ensure that the underlying device sensors are not susceptible to sensor fingerprinting.
The user agent must verify that all mandatory conditions are satisfied to ensure it can create an XRReferenceSpace and expose XRReferenceSpace data within a given active document.
The mandatory conditions for creating an XRReferenceSpace are the following:
- User consent must have been obtained before creating a bounded-floor or unbounded reference space.
- User consent is required before creating a local-floor reference space type, if the floor level will reflect the real-world location of the user’s floor.
- When creating a local-floor or bounded-floor reference space type, if the origin of the reference space reflects the real-world location of the user’s floor, or if the floor level is emulated and set by the user to a non-default value, then the coordinates of the origin must be rounded sufficiently to prevent fingerprinting using floor level. Rounding to the nearest 1cm is suggested.
- When creating a bounded-floor reference space the boundsGeometry must be rounded sufficiently to prevent fingerprinting the user’s bounds. The region represented by the rounded bounds geometry must be a subset of the original bounds. Rounding to the nearest 5cm is suggested.
- Creating multiple bounded-floor, local-floor or local reference spaces during the same session that have different effective origins can expose the same threat vectors present in an unbounded reference space. User agents must either:
- Require the same user consent as for unbounded reference spaces, before allowing creation of multiple reference spaces with different effective origins in the same session, or
- Enforce the same position limiting bounds for XRViewerPose data within all those sessions, and require that all effective origins fall within those bounds.
Acquiring user consent is a mandatory condition for some types of object creation and data access. In addition to general considerations for obtaining user consent, the following considerations are specific to the WebXR Device API.
The following guidelines are suggested:
- User consent should only be considered valid for the browsing context within which it was obtained.
- Once a specific consent is obtained for a specific origin in a browsing context, that origin does not need to obtain that specific consent again during the lifetime of that browsing context. Specifically, if multiple same-origin XRSession objects are created in a browsing context, and all require the same user consent, then consent should only need to be obtained once.
- The user agent must ensure that all mandatory conditions for user consent are met before creating any XRSession object. As a result, the user agent may be required to ask for user consent multiple times in a browsing context if it is creating multiple XRSession objects each with different mandatory conditions for user consent.
The judgement on how to communicate to the user the known threats is up to the implementer. It is suggested that the following threat vectors be communicated to the user at the time of session creation:
| User consent is required if... | Why user consent is required |
| XRSession can create an unbounded reference space. | Site may be able to determine user’s specific geographic location, and may be able to perform gait analysis, allowing user profiling and fingerprinting. |
| XRSession can create an XRSpace and position limiting is not applied. | Site may be able to determine user’s specific geographic location. |
| XRSession can create multiple XRSpace objects with different native origins and suitable position limiting is not applied. | Site may be able to determine user’s specific geographic location. |
| XRSession can create a local-floor or bounded-floor reference space, where the origin of the reference space reflects the real-world location of the user’s floor. | Site may be able to infer the user’s height and may be able to perform gait analysis, allowing user profiling and fingerprinting. |
| XRSession can provide XRViewerPose data that is not quantized, and underlying device sensors may be susceptible to fingerprinting. | Site may be able to perform user fingerprinting. |
| On a device with configurable interpupillary distance, XRSession may create an XRViewerPose that will return an XRView for each eye | Site access to IPD data may allow user profiling and fingerprinting. |
The combination of camera data (e.g. using getUserMedia) with XRViewerPose data that is based on real-world viewer position and orientation may expose threat vectors related to real-world geometry that are not present when only camera data is available.
Such threat vectors assume that both types of data are available within a sufficiently short time interval that, given a camera frame, the viewer pose can be known at the time the frame was captured.
It is suggested that the user agent either prevent access to both types of data on the same origin within a short time interval (e.g. 2 seconds), or inform the user of the threat vectors and obtain user consent before making both types of data available.
User agents may support a mode (e.g., private browsing) of operation intended to preserve user anonymity and/or ensure records of browsing activity are not persisted on the client.
There are no additional requirements for such modes, as there is no persistent data or unique user identifier data generated by the WebXR Device API.
The following threats, and associated mitigations, are the basis of the above privacy requirements.
XRViewerPose or XRPose might be used for input sniffing. Same Origin and Focused and Visible mitigations address this threat.
XRViewerPose or XRPose might be used to identify the user’s location. Position Limiting addresses this threat for bounded-floor, local-floor or local reference spaces. User consent is required for unbounded reference spaces, or if the user agent allows the creation of multiple reference spaces in the same session that have different position limiting bounds.
XRViewerPose or XRPose might be used for gaze tracking. Same Origin and Focused and Visible mitigations address this threat.
XRViewerPose or XRPose may allow user fingerprinting when based on sensor data. The user agent may use quantization to address this threat, where data quantization will not affect the user experience. Otherwise, user consent is required.
XRViewerPose may allow user fingerprinting or user profiling on devices with configurable interpupillary distance. In this case, user consent is required.
XRViewerPose may allow user fingerprinting in situations where the user has configured several display orientations and positions that are represented as multiple XRViews (for example, a CAVE system). Rounding helps alleviate this threat.
Viewer height may be used for user profiling. User consent is required in situations where this may be determined by real-world floor level.
Viewer height may be used for user fingerprinting, particularly in situations where viewer height is emulated and set by the user. Rounding addresses this threat.
Within a bounded-floor reference space, boundsGeometry may be used for user fingerprinting. Rounding addresses this threat.
Users may become confused or fatigued if prompted excessively for user consent during a session. This is addressed by requiring user consent once, at time of session creation.
If the active document has access to the camera on a passthrough device, XRViewerPose may allow gaze tracking of the real world. This potential threat is not addressed by these requirements.
If the active document can read back pixels outside its own rendering context (e.g. during a screen recording), then XRViewerPose may allow gaze tracking. This potential threat is not addressed by these requirements.
Within a bounded-floor reference space, boundsGeometry might in theory be used for user profiling. This potential threat is not addressed by these requirements.
Data generated by XRInputSource might in theory be used for user profiling, for example measuring the length of a user’s arm. This potential threat is not addressed by these requirements.