Spec: Define sensitive information and user intent #757
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pulls a lot of text directly out of privacy-security-explainer.md to define some of the various terms necessary to discuss user consent and the data that it protects.
NellWaliczek
reviewed
Jul 8, 2019
NellWaliczek
approved these changes
Jul 8, 2019
johnpallett
reviewed
Jul 8, 2019
index.bs
Outdated
|
|
||
| In the context of XR, <dfn>sensitive information</dfn> includes, but is not limited to, user configurable data such as interpupillary distance (IPD) and sensor-based data such as {{XRPose}}s. All {{XRSessionMode/"immersive-vr"}} and {{XRSessionMode/"immersive-ar"}} sessions will expose some amount of sensitive data, due to the user's pose being necessary to render anything. However, in some cases, the same sensitive information will also be exposed via {{XRSessionMode/"inline"}} sessions. | ||
|
|
||
| Trustworthy Documents and Origins {#trustworthy-documents} |
There was a problem hiding this comment.
TIL that the term "potentially trustworthy" has an established meaning within secure contexts. Any concerns about using similar terminology in WebXR? Sorry @NellWaliczek that I didn't catch this before.
| @@ -2128,7 +2171,7 @@ Also, to prevent CORS-related vulnerabilities each page will see a new instance | |||
| Fingerprinting {#fingerprinting-security} | |||
| -------------- | |||
|
|
|||
| Given that the API describes hardware available to the user and its capabilities it will inevitably provide additional surface area for fingerprinting. While it's impossible to completely avoid this, steps can be taken to mitigate the issue. This spec limits reporting of available hardware to only a single device at a time, which prevents using the rare cases of multiple headsets being connected as a fingerprinting signal. Also, the devices that are reported have no string identifiers and expose very little information about the devices capabilities until an XRSession is created, which may only be triggered via user activation in the most sensitive case. | |||
| Given that the API describes hardware available to the user and its capabilities it will inevitably provide additional surface area for fingerprinting. While it's impossible to completely avoid this, user agents should take steps to mitigate the issue. This spec limits reporting of available hardware to only a single device at a time, which prevents using the rare cases of multiple headsets being connected as a fingerprinting signal. Also, the devices that are reported have no string identifiers and expose very little information about the devices capabilities until an XRSession is created, which requires additional protections when [=sensitive information=] will be exposed. | |||
There was a problem hiding this comment.
There are explicit requirements for user agents to anonymize values which may be unique to the device. Do you want to call out those scenarios here? For reference, those requirements apply to:
- XRPose data, when based on underlying raw sensor data (to avoid fingerprinting sensor calibration data)
- Factory-configured data including IPD or screen geometry data
- User-configured data including IPD, viewer height, or display locations for CAVE systems
There was a problem hiding this comment.
Also, sensitive data that could be used for user profiling does not appear to be addressed. Will that be in a different PR?
| Sensitive Information {#sensitive-information-header} | ||
| --------------------- | ||
|
|
||
| In the context of XR, <dfn>sensitive information</dfn> includes, but is not limited to, user configurable data such as interpupillary distance (IPD) and sensor-based data such as {{XRPose}}s. All {{XRSessionMode/"immersive-vr"}} and {{XRSessionMode/"immersive-ar"}} sessions will expose some amount of sensitive data, due to the user's pose being necessary to render anything. However, in some cases, the same sensitive information will also be exposed via {{XRSessionMode/"inline"}} sessions. |
There was a problem hiding this comment.
Do you want to include information about data that could be used to profile the user (e.g. viewer height, IPD data?)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pulls a lot of text directly out of privacy-security-explainer.md to
define some of the various terms necessary to discuss user consent and
the data that it protects. This PR does not include several things from
the privacy explainer such as the restrictions on pose data and data
mitigation strategies. I expect to address them in a follow-up PR.