Normatively mitigate privacy concerns related to poses outside presenting (e.g., magic window)

[ddorwin]

In general, WebVR presentation (exclusive session) requires a user gesture. However, magic window (non-exclusive) sessions do not currently require a user gesture. Providing pose data without requiring a user gesture or clear indication that such data is being provided presents privacy concerns, especially for mobile clients where the users is always holding the device.

While external desktop HMDs, may appear to pose less concern, there are potential issues for external desktop HMDs as well, including:

• Browsing in VR - VR user agents need to apply similar consideration if they choose to expose magic window in the browser in the HMD.
• There may be privacy concerns about access to high-frequency pose data even if the user is not wearing or touching the headset. See, for example, https://crbug.com/421691.

In addition, some future use cases/capabilities, such as Tango-style 6-DoF or "punchthrough" magic window in a VR browser, may enable the application to derive a lot more information, including data that might enable page-wide gaze tracking.

Since requiring a gesture for magic window would break a number of use cases, we need to consider other mitigations, require some, and allow user agents flexibility to implement others.

Examples include:

• Follow the Generic Sensor API’s security and privacy considerations (WebVR should follow security and privacy considerations for Generic Sensors #249)
• Only expose WebVR on secure origins (WebVR should follow security and privacy considerations for Generic Sensors #249)
• Only provide poses to the focused frame. (Likely implied by WebVR should follow security and privacy considerations for Generic Sensors #249.)
• Only provide poses for frames that are same origin to the top level document.
• Throttle frequency and/or provide reduced precision (e.g., a low-pass filter).
  • This could be applied to:
    • All tracking-only/non-presenting/non-gesture instances
    • OR just instances in unfocused or non-same-origin frames frames, though this could create unexpected behavior for users.
• Use permissions or other mechanisms to allow users to opt-out of tracking for individual sites or entirely.
  • Integration with the Permissions API should enable this option for user agents.
• Use indicators or other UI to inform users that device tracking is in use.
• Attempt to ensure that the use of pose data is legitimate.
  • For example, by ensuring it results in changes that are clearly visible to the user.
  • It may be difficult to ensure this since a malicious app could try to make subtle visual changes, but some ideas include:
    • Requiring that the UA only process frames for visible and non-obscured of a specific size or percentage of the window.
    • Requiring that the frame changes with pose changes.
    • Throttling frequency and/or precision as appropriate.
  • Note: Such mitigations may require an explicit link between VRSession.requestFrame() and an output area, such as is proposed for magic window in Detail magic window support #237.

We may also want to consider allowing the application to request specific ranges of accuracy. This would allow applications to ensure consistent resolution/frequency for all frames and for the user agent to make more intelligent decisions about whether to require permission, display indicators, etc. Similarly, it might make sense to require the page to request, though not necessarily be given, capabilities such as 6-DoF and "punchthrough."

[toji]

Further information about this topic in #77 and #217.

[NellWaliczek]

Closing in favor of the work being done in the privacy-and-security repo. When the explainer from that repo is complete, there will be a task to address the findings cohesively.

[ddorwin]

@NellWaliczek Do we have any reference to this issue or its contents in that repo? Maybe this should be in some list of deliverables? Otherwise, I worry that we'll lose some of the information in this and related issues.

Also, there should be at least one open issue to address privacy in WebXR Device API. Maybe we don't iterate on the text in that issue, but it is an issue that must be addressed for the spec to be complete.

[NellWaliczek]

Ah my mistake. I could have sworn I read a topic where folks were discussing 6DOF (and even 3DOF!) position data as needing to be addressed by that repo's explainer. But, now I can't find where I read that. I wonder if it was on a call instead? Either way, I'll reopen this issue and migrate it to the privacy-and-security repo for management there.
And yes, good idea to open a general issue for addressing the findings from the privacy-and-security repo. I'll get that filed in just a minute

[NellWaliczek]

This issue was moved to immersive-web/privacy-and-security#9