Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security and privacy questionnaire on WebXR Device API #1379

Open
18 tasks
himorin opened this issue Jul 31, 2024 · 4 comments
Open
18 tasks

security and privacy questionnaire on WebXR Device API #1379

himorin opened this issue Jul 31, 2024 · 4 comments

Comments

@himorin
Copy link
Member

himorin commented Jul 31, 2024

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?
  • 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?
@toji
Copy link
Member

toji commented Aug 7, 2024

Thanks for putting together this initial draft! I've got a few comments:

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This seems to be asking more about what information the API surfaces, while your draft response is more about pulling data from external servers. I think something along the following would be more accurate:

"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?

I'd add a bullet point to this stating:

"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."

We can also mention:

"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?

We may want to clarify that we don't expose any "typical" PII (like serial numbers or user names).

Do features in this specification enable access to device sensors?

For clarity, we should mention that the reported position and orientation data is derived from device sensors such as gyroscopes or cameras, but the sensor values themselves are not reported outside of the module that you mentioned.

A module in future incubation, model element may load 3D asset bundle with script.

While we are discussing the model element under the Immersive Web banner I don't see it becoming a WebXR API module, so we probably don't need to discuss it as part of this questionnaire.

@himorin
Copy link
Member Author

himorin commented Aug 20, 2024

Thanks for putting together this initial draft! I've got a few comments:

Thank you so much for review.

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This seems to be asking more about what information the API surfaces, while your draft response is more about pulling data from external servers. I think something along the following would be more accurate:

ah, from Does your feature expose information to origins? and following question on expose the minimum amount of information necessary to enable their intended uses, I actually thought this was a question on the API itself accessing to the external service including ones at the origin.

"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.

replaced with this.

Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

I'd add a bullet point to this stating:

"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."

We can also mention:

"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."

added both

How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

We may want to clarify that we don't expose any "typical" PII (like serial numbers or user names).

added one bullet for clarification.

Do features in this specification enable access to device sensors?

For clarity, we should mention that the reported position and orientation data is derived from device sensors such as gyroscopes or cameras, but the sensor values themselves are not reported outside of the module that you mentioned.

added one bullet.

A module in future incubation, model element may load 3D asset bundle with script.

While we are discussing the model element under the Immersive Web banner I don't see it becoming a WebXR API module, so we probably don't need to discuss it as part of this questionnaire.

added clarification. (I suppose we should, at least, mention since it's within IWWG/CG space)

@toji
Copy link
Member

toji commented Aug 20, 2024

Looks good, thank you! One more comment:

APIs do not expose PII on device identification, like device serial number nor user names.

I feel like this sentence was intended to go under the previous section about PII rather than the section about "sensitive information"?

@himorin
Copy link
Member Author

himorin commented Aug 21, 2024

@toji Ah! yes, thank you for pointing.

@himorin himorin changed the title [Draft] security and privacy questionnaire on WebXR Device API security and privacy questionnaire on WebXR Device API Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants