#620: WebXR Plane Detection Module
Discussions
Discussed
Mar 29, 2021 (See Github)
[bumped]
Discussed
Apr 19, 2021 (See Github)
Dan: Proposed feedback...
Hi! I'm just having a look at the ex-*plane*r and coming up with a few questions. First of all, I think it could go into a bit more detail on the user need. Can you give a few examples of where plane detection becomes important in the context of a WebXR application? The answers to the security & privacy questionnaire look good but do not seem to be fully reflected in the explainer of the spec itself? For example, the quantization of planes is mentioned as a mitigation strategy against privacy attacks in the questionnaire response but this is not mentioned in the spec itself. I think this would be a lot stronger (and less prone to fingerprinting) if the quantization and other mitigation strategies were spelled out in the spec. Finally, you mention synchronous hit-test but it's not clear from the explainer how this fits together with the [hit testing](https://immersive-web.github.io/hit-test/) specification itself? What does this technology provide over and above what WebXR hit testing? We may also have feedback on the API to share - but I wanted to get this out to you quickly.
Dan: posts comment
Comment by @torgo Apr 19, 2021 (See Github)
Hi @bialpio! We're just having a look at the explaner in a TAG breakout session and I'm coming up with a few questions. First of all, I think it could go into a bit more detail on the user need. Can you give a few examples of where plane detection becomes important in the context of a WebXR application? The answers to the security & privacy questionnaire look good but do not seem to be fully reflected in the explainer of the spec itself? For example, the quantization of planes is mentioned as a mitigation strategy against privacy attacks in the questionnaire response but this is not mentioned in the spec itself. I think this would be a lot stronger (and less prone to fingerprinting) if the quantization and other mitigation strategies were spelled out in the spec. Finally, you mention synchronous hit-test but it's not clear from the explainer how this fits together with the hit testing specification itself? What does this technology provide over and above what WebXR hit testing? We may also have feedback on the API to share - but I wanted to get this out to you quickly.
Comment by @bialpio Apr 19, 2021 (See Github)
Can you give a few examples of where plane detection becomes important in the context of a WebXR application?
Sure! Access to information about flat surfaces detected in users' environment could be used by applications for example for object placement (hit test is also useful for that, but it's way more limited, i.e. w/ plane detection, the app could be fairly confident that the placed object actually fits in the user's space). The application could also attempt to display something like a game board / arena that could even be generated based on the plane's polygon. Another use case could be for example physics - a site could use the detected planes to compute how virtual objects should behave in order to make them look like they're interacting with the real world. I can also think of a bit more far-fetched scenarios - maybe the site could use the planes when computing how audio propagates in the scene and use that for some kind of echo effect? In general, the use cases could be considered similar to those of hit test, except that hit test API requires pre-subscribing to a hit test and describing the ray that will be used as relative to an XRSpace (which, roughly speaking, is something that the XR system needs to know how to track) - this limits the apps' options a bit. When an app retrieves a collection of planes from the XR system, it could use that information to hit test against those planes in a more ad-hoc manner, not being limited to using XRSpaces (but, on the other hand, the hit test API can potentially yield better results since XR system can use more information than just detected planes when computing hit test results). One more difference is that hit test was considered the lowest common denominator that all XR systems should be able to support and can serve as a fall-back for the apps that could offer better experiences with more information about the environment if those capabilities (like plane detection) are available.
For example, the quantization of planes is mentioned as a mitigation strategy against privacy attacks in the questionnaire response but this is not mentioned in the spec itself. I think this would be a lot stronger (and less prone to fingerprinting) if the quantization and other mitigation strategies were spelled out in the spec.
Thanks for the feedback! I'll add quantization to the spec draft - I have already mentioned other strategies in Privacy & Security Considerations section, but missed it. :frowning_face: I'll add a mention to those strategies into the algorithms explicitly as one of the optional steps that user agents could do, hopefully this would also serve as a forcing function to make sure that implementers consider privacy implications.
Comment by @torgo Apr 21, 2021 (See Github)
Hi @bialpio - regarding the use cases, that's great info. Can you please add it to the Explainer as well? We'll try to provide some additional feedback on the API design in the coming week.
Discussed
Apr 26, 2021 (See Github)
Dan: I left feedback, asked how it fits with HIT testing and for more examples and use cases. The requester has responded well. Not HIT testing, but did respond on additional use cases and quantization issue. Still more we're waiting for.
Rossen: since last time we talked, nothing much has changed. Discussion last time was around privacy and what that means for users. Through such API you can pretty quickly and easily map out somebody's physical environment. What does that mean from a privacy point of view? If I use this does company x all of a sudden have a map of my office or bedroom? Don't believe this was addressed.
Dan: one way they say they're addressing that is through quantization of planes. Could make it less possible to fingerprint you based on how high your desk is..
Rossen: might make it slightly harder. The actual API set they are bringing in is pretty straightforward.
Dan: note that the phrase quantization still does not appear in the spec. leaves comment
Proposed comment:
Hi @bialpio - we're just taking another look at this this week... Still missing the connection to hit testing and some additional info regarding the privacy & security. Do you want to ping us again when you're ready for us to re-review?
Rossen: re-read paragraph 6 in the spec which is on privacy and security, still not addressing it. Recognising the issue but not necessarily proposing concrete ways of why this is a non-issue or how it will be mitigated. Instead just saying general XR concerns apply. Look at general XR anchors module.
Hadley: is it possible to do all of that on device or in the user agent? To keep the information from leaking out of the users control. If we can keep it within the user agent as opposed to expose it throug the API such that the application can work with it rather than....
Dan: part of the idea of the API but they don't do enough to explain how that happens. That's part of the issue with the security and privacy thing, not really going in to detail on the abuse cases so its' not clear how the design doesn't allow for the information to be misused.
Rossen: we had similar concerns with hit test but they said at the time hit test is completely contained in the user agent and the only thing you get back is the object that you hit tested, not anything identifying about it. This one goes one level further, or more.
Comment by @torgo Apr 26, 2021 (See Github)
Hi @bialpio - we're just taking another look at this this week... Still missing the connection to hit testing and some additional info regarding the privacy & security. Do you want to ping us again when you're ready for us to re-review?
Comment by @bialpio Apr 28, 2021 (See Github)
I've just merged the PR that should address the initial feedback, please let me know if you think the changes are not sufficient.
Discussed
May 1, 2021 (See Github)
Dan: PR that addresses our feedback.
Rossen: things demystified.. added required name... good.. must not reveal details of people..
Dan: PR is merged. We should close this.
Rossen: [leaving comment]
Dan: this is a success story. Do we need wider review? Proposed closed?
Rossen: closed it.
Rossen: [closing with comment]
Comment by @atanassov May 11, 2021 (See Github)
@torgo, @rhiaro and myself did another pass through this issue during our May 2021 vf2f. Thank you for the quick turnaround addressing of all the issues we raised and even making the PRs to both explainer and spec. This is a really great example of effective TAG review and we are happy if you feel the same. We are also happy to see this work proceed forward, thus, resolving as satisfied. Thank you for working with us!
OpenedMar 24, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of WebXR Plane Detection Module.
WebXR Plane Detection API allows WebXR-powered experiences to obtain information about planes (flat surfaces) detected in the users' environment. The information about detected planes' poses (position + orientation) and approximate shapes is being surfaced to the application on every XR frame if the feature was enabled on an XR session. This will allow the applications to provide more immersive experiences, for example by leveraging the returned plane information when computing interactions of virtual objects with users' surroundings.
Further details:
You should also know that...
This is an early review request, although we already have a rough specification draft so I decided that "Specification review" may be more appropriate.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback