Skip to content

Clarify when tracking/input data is exposed via inline devices #985

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Mar 19, 2020
Merged

Clarify when tracking/input data is exposed via inline devices #985

merged 1 commit into from
Mar 19, 2020

Conversation

toji
Copy link
Member

@toji toji commented Mar 16, 2020

/fixes #984

This makes some changes to how we pick inline devices that make the spec line up more closely with the group's intent for when inline sessions are allowed to expose tracking data, as well as add a bit of non-normative text to more clearly explain the purpose of the default inline session that can be accessed without first gaining user consent.

CC: @pes10k

@toji toji requested a review from Manishearth March 16, 2020 22:18
@probot-label probot-label bot mentioned this pull request Mar 16, 2020
Closed
Manishearth
Manishearth approved these changes Mar 16, 2020
View reviewed changes
Copy link
Contributor

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about input events in the case when the XR device being used by the inline session is not the inline XR device (i.e. someone is in a 2D browser on a headset)? Should we file this separately?

@toji
Copy link
Member Author

toji commented Mar 17, 2020

I'm not sure I follow, @Manishearth? You mean 2D page inputs generated by an XR controller? The UA should be handling the management of those input into pointer events already, and those pointer events should be the only thing exposed. From this PR:

MUST NOT report [=XR input source=]s or events other than those created by pointer events.

Is there a case I'm overlooking here?

@Manishearth
Copy link
Contributor

Is there a case I'm overlooking here?

Yes, the case that the inline XR device that gets selected is not the default inline XR device. The spec is structured such that e.g. if you're in a 2D browser on a device, the inline XR device that gets selected is the same as the immersive one, so you can expose head poses.

@cabanier
Copy link
Member

Is there a case I'm overlooking here?

Yes, the case that the inline XR device that gets selected is not the default inline XR device. The spec is structured such that e.g. if you're in a 2D browser on a device, the inline XR device that gets selected is the same as the immersive one, so you can expose head poses.

Do you know of a UA that implements this?

@toji
Copy link
Member Author

toji commented Mar 18, 2020

I think that should be addressed by the change to obtaining the current device, which now states that if the features arrays are empty you always get the default device.

Manishearth
Manishearth approved these changes Mar 19, 2020
View reviewed changes
Copy link
Contributor

@Manishearth Manishearth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah! I missed that

@toji toji merged commit f140eeb into master Mar 19, 2020
@toji toji deleted the clarify-inline branch March 19, 2020 23:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Manishearth Manishearth Manishearth approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Clarify whats learn-able through an inline session re privacy
3 participants
@toji @Manishearth @cabanier