Privacy & Security explainer: Clarify threat vectors

[johnpallett]

Per feedback on #746 this issue is to track some additional text (in a new PR) to:

• Provide more detail about pose quantization threat vectors and UA mitigation
• Profiling threat vectors of sensitive user information

A few specific topics that probably should be covered...

XRPose section

• Alignment between consent requirements for pose data and the permission requirements for Device Orientation
• Explanation of the fingerprinting threat vector (underlying sensor hardware calibration can be fingerprinted), quantization as a possible approach, but up to user agent
• Clarification on how IPD can be used to reliably infer sensitive user characteristics; explicit consent is reecommended

Unbounded reference space

• Clarify how geographic location can be determined from trajectory data and pattern matching (meaning, the user's location can be inferred even if the coordinates aren't geo-locked in any way); explicit consent is recommended

local-floor and bounded-floor

• Clarify how age can be reliably inferred from viewer height; explicit consent is recommended
• Do we want to specify that rounding should make the viewer taller, or shorter?

[johnpallett]

Suggested additions to the XRPose section:

Note: XRPose data may allow a site to fingerprint a user 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 XRPose data.

Note: In situations where XRPose data could reasonably be used as an alternate method for obtaining device orientation, user agents are encouraged to align their consent requirements for XRPose with their consent requirements for DeviceOrientation events.

Suggested additions to the XRViewerPose section:

Note: User-configured 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 XRViewerPose data on devices that support configurable IPD. Given the sensitivity of this data, caution is strongly advised when relying upon implicit signals.

Suggested additions to the unbounded reference space:

Note: Unbounded coordinate systems may allow a site to determine the user's geographic location, for example by matching trajectory data with known patterns. 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 strongly advised when relying upon implicit signals.

Suggested additions to the bounded and local-floor sections:

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 strongly advised when relying upon implicit signals.

[NellWaliczek]

I'm gonna try to get the PR landed as-is, but as soon as it is, please post a follow-up PR with these changes :)

[johnpallett]

I'm gonna try to get the PR landed as-is, but as soon as it is, please post a follow-up PR with these changes :)

👍 SGTM!

[NellWaliczek]

Note: In situations where XRPose data could reasonably be used as an alternate method for obtaining device orientation, user agents are encouraged to align their consent requirements for XRPose with their consent requirements for DeviceOrientation events.

Feedback as requested! Mainly we just need to make sure we're describing the right objects/calls as having the protections applied to them. For example, the text quoted above isn't quite right because the consent requirements aren't actually for XRPose because getPose() isn't asynchronous and as a result it isn't an api that can gather consent. Instead, we need to call out that any XRSpace passed into getPose() which can be used to compute poses in such a way that could reasonably used as an alternate method blah blah blah. Does that make sense?

[johnpallett]

@NellWaliczek I think that makes sense. I'd like to try again in an a PR, it'll be easier to match the logic in the context of the actual doc. SGTY?

One approach that might work here is for that paragraph to be in the XRSession section, with XRPose largely removed...

Note: In situations where pose data could reasonably be used as an alternate method for obtaining device orientation, user agents are encouraged to align their consent requirements with their consent requirements for DeviceOrientation events.

[johnpallett]

Note: Per discussion, also add principles for when sensitive data is/is not considered a threat to the 2nd paragraph of the privacy & security explainer. An overview of principles from the above comment thread (IMO this needs to be edited for clarity and length):

Fingerprinting

• The user agent must take steps (where possible) to prevent exposing data that is unique to the device. This is true even if consent has been obtained for other reasons. For example, even if user consent is obtained to expose IPD data (for reasons of user profiling) it is still in the user's best interests that the IPD data be anonymized to prevent fingerprinting.
• Some raw sensor data might be fingerprinted (e.g. IMU data) and thus access to that raw sensor data outside of WebXR requires user consent. The user agent must either ensure WebXR data based on those sensors is anonymized sufficiently to prevent fingerprinting, otherwise user consent is required.
• Mitigating the threat of fingerprinting is a requirement, but specific mitigation details are up to the user agent who is best equipped to evaluate the actual threat on a given platform using the platform's APIs. The approaches (e.g. values for rounding thresholds) in the design are intended as suggestions, not firm requirements.

User Profiling

• Consent is required before exposing data that sites might use to reliably infer sensitive user characteristics (such as race, gender, or age) for some population of users. For example, user-configured IPD data might allow a site to determine the age of some users. Note: Even if most users couldn't be profiled, if some users can be reliably profiled then this requirement holds for all users.
• This design prioritizes the protection of sensitive user characteristics. If there is a reasonable possibility that a reliable signal for a sensitive characteristic exists, then user consent is required.
• User profiling concerns are not sufficient to require consent before exposing data that either provides a weak signal for all users, or where the information that can be inferred is not particularly sensitive. For example, the size of a user's room could (in theory) indicate a user's wealth, but it might just as easily indicate that a user is at work; this ambiguity suggests the signal is unreliable and thus user consent is not required.

[johnpallett]

Note to self: The language in the last bullet of this section suggests a particular timing for user consent, we can address this more precisely while elaborating on the IPD threat: https://github.com/immersive-web/webxr/blob/master/privacy-security-explainer.md#xrviewerpose