Open
Description
This is still draft version.
Detail analyses are also at privacy and security explainer.
- What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
- Initially, the WebXR Device API exposes a boolean indicating whether or not the user's device is capable of displaying VR or AR content. To query any further information from the API an XRSession must be started, which requires user consent. For the duration of the session, continuous position, orientation, and optical information for the user's XR device (such as a headset) and any associated controllers are reported on an ongoing basis.
- Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
- Some modules of WebXR Device API will expose hardware capability, e.g. WebXR Gamepads API, or surrounding environment information, e.g. WebXR Raw Camera Access Module. All of these API requires explicit user concent to use features of API via Permissions.
- Warning is provided for specific information which could be exposed as background information, e.g. mention about IPD value in WebXR Device API.
- The values reported during a session are required in order to allow the page to render appropriately tracked imagery. If the data is not present or inaccurate then the resulting rendering may make the user sick.
- XRSessions are typically presented full screen on the device, and upon exiting the full screen mode the session ends and the data is no longer reported.
- How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
- WebXR APIs use Permissions API as its basis for exposing feature with user concent.
- Considerations are taken carefully for PII, including ones which are not clearly related, such as height from e.g. distance between eye and floor.
- APIs do not expose PII on device identification, like device serial number nor user names.
- How do the features in your specification deal with sensitive information?
- similar to above. identified potential items are marked and described in specifications.
- Do the features in your specification introduce new state for an origin that persists across browsing sessions?
- Basically no.
- Incubation is on going for geo alignment which enables linking to external geolocation data.
- Do the features in your specification expose information about the underlying platform to origins?
- WebXR Device API and related modules exposes some level of hardware capability through API call, but all are behind Permissions. Also exposure of relevant hardware capabilities are reviewed and limited as minimum.
- Does this specification allow an origin to send data to the underlying platform?
- WebXR Device API sends image stream to the underlying platform which is shown as VR or AR (XR). These streams are simple image stream just to be shown on displays.
- Do features in this specification enable access to device sensors?
- Some modules, such as WebXR Raw Camera Access Module will grant access to sensor. Most of which will lock sensor (or camera) to be fully used by the module.
- APIs does not expose raw sensor values, nor provide direct access to them. Only data derived from device sensors are reported.
- Do features in this specification enable new script execution/loading mechanisms?
- no.
- A module in future incubation within immersive-web WG/CG space, model element may load 3D asset bundle with script, but is a totally separated specification and will never be a part of WebXR Device API as module.
- Do features in this specification allow an origin to access other devices?
- No.
- Do features in this specification allow an origin some measure of control over a user agent’s native UI?
- Full head device based XR has non Web browser based control, like most of applications or UIs are rendered as full screen XR. For in browser context, this API and modules will follow usual user concent or Permissions handling by browser UI.
- What temporary identifiers do the features in this specification create or expose to the web?
- no.
- How does this specification distinguish between behavior in first-party and third-party contexts?
- WebXR specifications themselves do not have resource loading mechanism from external parties, but script needs to feed after retrieved via fetch or else.
- How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
- WebXR specifications themselves do not have a feature to save or load from/to browser persistent data store, and will follow working mode of underlying browser.
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
- Yes, and explainer over whole WebXR ecosystem exists. Also most of WebXR modules have.
- Do features in your specification enable origins to downgrade default security protections?
- No.
- For future incubation, there is some discussion about XR enable permission on XR based devices, such as FHD.
- How does your feature handle non-"fully active" documents?
- API has state indicates active or not, and there are several steps to check and disable any other active sessions as disable, e.g. XRSystem.
- What should this questionnaire have asked?
Metadata
Metadata
Assignees
Labels
No labels