Spec: Reference space privacy considerations #762

toji · 2019-07-09T22:29:40Z

Describes the mitigations and checks that must be used when supporting
the various reference spaces. Pulls heavily from text originally in
privacy-security-explainer.md.

Posted as a draft because I'm not sure if I'm happy with the format yet.

toji · 2019-07-10T20:40:03Z

@johnpallett: Can't add you as a reviewer directly, but could you take a look at this?

johnpallett

Thanks @toji comments inline.

I have a couple of general questions. The text here largely focuses on accepting or rejecting features during session creation. The original explainer spoke more about promise rejection during session creation and when creating a reference space.

Are we comfortable that this approach gives sufficient direction to implementers? For example, the original explainer directed the implementer to reject the reference space request promise if the requirements for a reference space could not be met;
Are implicit features covered (particularly local reference spaces?)

index.bs

toji · 2019-07-11T20:35:03Z

Thanks for the feedback, John! Left some responses and made some tweaks.

Are we comfortable that this approach gives sufficient direction to implementers? ...

This has been my primary source of angst around this text. (And #761, to a slightly lesser degree.) It comes down to a couple of things, I think:

There's some of these privacy principles that must be validated at runtime (are you visible and focused?) and those slot well into spec algorithms. Then there's other limits that feel more like intrinsic properties of the implementation, and as such it sounds extremely weird to ask for it to be validated in an algorithm. (ie: "If the pose will not be sufficiently rounded to prevent fingerprinting return null and abort the rest of these steps." Um, no? Because if you're not doing that then it just mean's you're not a valid implementation?) It's not as clear what the appropriate mechanism is to surface those kind of behaviors is.
Some of this content could/should be moved up in the document to be closer to the definition of the mechanism in question. Like, we could move the bounded-floor bounds limitations up into the section dedicated to discussing that interface easily, and it would likely read well. I worry that doing so may dilute the overall privacy message, though? When you have all of the privacy-centric dicsussion in one place like this it helps sell that it's important and gives a better mental picture of how all the limits relate rather than just being a jumble of somewhat confusing lines scattered throughout the doc?

If you have any thoughts on how to ease that tension, I'm happy to hear it!

johnpallett

[EDIT: I realized my comment was already addressed. You can ignore this!]

index.bs

NellWaliczek

A few nits, but mostly my concern is around making those restrictions more algorithmic. For example forcing native origins to be the same isn't likely to be an intrinsic property of XR systems and is something that the UA will need to manage themselves. Similarly, limiting pose data to a specific distance from the native origin is not likely to be a feature of the underlying XR systems. These sorts of things seem like they can actually be done algorithmically as part of the requestReferenceSpace() algorithm flows.

index.bs

toji · 2019-07-19T22:45:41Z

Moved the reference space requirement bullet points around to the appropriate contexts and/or made them part of an algorthim. This feels like it "dilutes" the privacy-centric portion of the doc, because now some privacy driven limits are scattered throughout the doc, but it is probably easier for implementers this way and ultimately that's what counts.

NellWaliczek

More comments/questions!

index.bs

NellWaliczek · 2019-07-19T23:13:12Z

index.bs

+If {{XRReferenceSpaceType/"local"}} is included in an {{XRSession}}'s [=requested features=] the user agent MUST ensure [=user intent=] to allow {{XRReferenceSpaceType/"local"}} tracking is well understood, either via [=explicit consent=] or [=implicit consent=], or the feature MUST be rejected.
+
+Note: {{XRReferenceSpaceType/"local"}} is always included in the [=requested features=] of {{XRSessionMode/"immersive-vr"}} and {{XRSessionMode/"immersive-ar"}} sessions as a [=default feature=], as as such {{XRSessionMode/"immersive-vr"}} or {{XRSessionMode/"immersive-ar"}} sessions always need to obtain [=explicit consent=] or [=implicit consent=] to use {{XRReferenceSpaceType/"local"}} reference spaces.
+
 <section class="unstable">
 Gaze Tracking {#gazetracking-security}


Are we going to have a separate PR to remove the privacy sections that we've replaced with all this new text?

Yeah, a separate PR sounds best for this.

Before merging, can you file that? Are we intending to do it before VR complete (looks skeptically at the calendar)

#776. And while it would be nice, I don't think this is necessary for VR complete because it should mostly entail removing redundant information.

Ok, let's just make sure we didn't preemptively remove the 'unstable' banner from around it before we cut the next working draft.

index.bs

NellWaliczek · 2019-07-19T23:26:39Z

index.bs

+
+Note: It is suggested that points of the [=native bounds geometry=] be [=limiting|limited=] to 15 meters from the [=XRSpace/native origin=] in all directions.
+
+Each point in the [=native bounds geometry=] MUST also be [=rounding|rounded=] sufficiently to prevent fingerprinting.  For user's safety, rounded points values MUST NOT fall outside the bounds reported by the platform.


@johnpallett It just occurred to me... is rounding a sufficient mitigation here or should we also be applying fuzzing?

ping @johnpallett. If you think this is a concern, please file an issue!

No blocking concerns here. Thanks @NellWaliczek

toji · 2019-07-20T05:19:59Z

Thanks for the review! Made a partial update to hit some of the simpler changes. I'll get the remaining change on or before Monday.

toji · 2019-07-22T21:19:50Z

Okay, everything should be addressed one way or another now. PTAL!

index.bs

NellWaliczek · 2019-07-22T21:33:22Z

index.bs

+If {{XRReferenceSpaceType/"local"}} is included in an {{XRSession}}'s [=requested features=] the user agent MUST ensure [=user intent=] to allow {{XRReferenceSpaceType/"local"}} tracking is well understood, either via [=explicit consent=] or [=implicit consent=], or the feature MUST be rejected.
+
+Note: {{XRReferenceSpaceType/"local"}} is always included in the [=requested features=] of {{XRSessionMode/"immersive-vr"}} and {{XRSessionMode/"immersive-ar"}} sessions as a [=default feature=], as as such {{XRSessionMode/"immersive-vr"}} or {{XRSessionMode/"immersive-ar"}} sessions always need to obtain [=explicit consent=] or [=implicit consent=] to use {{XRReferenceSpaceType/"local"}} reference spaces.
+
 <section class="unstable">
 Gaze Tracking {#gazetracking-security}


Before merging, can you file that? Are we intending to do it before VR complete (looks skeptically at the calendar)

index.bs

NellWaliczek

Looking really good! A few more small nits.

Describes the mitigations and checks that must be used when supporting the various reference spaces. Pulls heavily from text originally in privacy-security-explainer.md.

Co-Authored-By: Nell Waliczek <nhw@amazon.com>

toji · 2019-07-22T22:01:48Z

Nits addressed. Thanks!

index.bs

NellWaliczek

Only one nit. Approving!

toji requested a review from NellWaliczek July 9, 2019 22:31

toji added this to the June 2019 milestone Jul 10, 2019

toji force-pushed the pose-spec branch from 5126dd0 to ce3297b Compare July 10, 2019 18:46

toji force-pushed the reference-space-privacy branch from d3dfe95 to 3b3d687 Compare July 10, 2019 18:47

johnpallett reviewed Jul 11, 2019

View reviewed changes

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

johnpallett reviewed Jul 11, 2019

View reviewed changes

johnpallett reviewed Jul 12, 2019

View reviewed changes

index.bs Outdated Show resolved Hide resolved

johnpallett mentioned this pull request Jul 12, 2019

Spec: Pose privacy considerations #761

Merged

toji force-pushed the reference-space-privacy branch from 4184f6a to bccf59e Compare July 12, 2019 22:38

toji marked this pull request as ready for review July 15, 2019 22:25

NellWaliczek reviewed Jul 19, 2019

View reviewed changes

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

toji force-pushed the pose-spec branch from e7c0184 to 3f1b793 Compare July 19, 2019 18:36

toji force-pushed the reference-space-privacy branch from e7c2f4b to bcf50a0 Compare July 19, 2019 18:50

NellWaliczek reviewed Jul 19, 2019

View reviewed changes

toji force-pushed the reference-space-privacy branch from 8931c95 to b28126f Compare July 22, 2019 20:56

NellWaliczek reviewed Jul 22, 2019

View reviewed changes

toji and others added 8 commits July 22, 2019 15:00

Spec: Reference space privacy considerations

661ae20

Describes the mitigations and checks that must be used when supporting the various reference spaces. Pulls heavily from text originally in privacy-security-explainer.md.

Restructuring for clarity

00d7900

Addressing feedback from John

91def77

Nell feedback

e0da6be

Merge in Nell's suggestion

0276c2c

Co-Authored-By: Nell Waliczek <nhw@amazon.com>

Breaking things out more algorithmically

23308db

Partially address new feedback

3c32392

Made a table for features that require consent

b852dd2

Addressed nits

2440f62

toji force-pushed the reference-space-privacy branch from 82f79b5 to 2440f62 Compare July 22, 2019 22:01

toji changed the base branch from pose-spec to master July 22, 2019 22:01

NellWaliczek reviewed Jul 22, 2019

View reviewed changes

index.bs Outdated Show resolved Hide resolved

index.bs Outdated Show resolved Hide resolved

NellWaliczek approved these changes Jul 22, 2019

View reviewed changes

Quantized!

e177982

toji merged commit 1ee2a22 into master Jul 22, 2019

toji deleted the reference-space-privacy branch July 22, 2019 22:20


		Note: It is suggested that points of the [=native bounds geometry=] be [=limiting\|limited=] to 15 meters from the [=XRSpace/native origin=] in all directions.

		Each point in the [=native bounds geometry=] MUST also be [=rounding\|rounded=] sufficiently to prevent fingerprinting. For user's safety, rounded points values MUST NOT fall outside the bounds reported by the platform.

Spec: Reference space privacy considerations #762

Spec: Reference space privacy considerations #762

Uh oh!

Conversation

toji commented Jul 9, 2019

Uh oh!

toji commented Jul 10, 2019

Uh oh!

johnpallett left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

toji commented Jul 11, 2019

Uh oh!

johnpallett left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NellWaliczek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

toji commented Jul 19, 2019

Uh oh!

NellWaliczek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

toji commented Jul 20, 2019

Uh oh!

toji commented Jul 22, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NellWaliczek left a comment

Choose a reason for hiding this comment

Uh oh!

toji commented Jul 22, 2019

Uh oh!

Uh oh!

Uh oh!

NellWaliczek left a comment

johnpallett left a comment •

edited

Loading

johnpallett left a comment •

edited

Loading