#528: WebXR Layers
Discussions
2020-11-09
Present: Dan & Rossen
Rossen: From previous meeting, we do like the general direction and this session is about digging further into the spec and all functions that it brings with it.
Dan: on security & privacy questionnaie, they have not answered it, pointing only to answers being "in the spec" but there is a small one-item securty & privacy considerations section. Will ask them to expand. left comment
Rossen: When going through explainer it was difficult to understand what other options were considered and why these ones are the best. Perhaps they can add a section with that explanation.
Dan: loving the diagrams in the doc
[discussion of the nativeProjectionScaleFactor
]
Rossen: this isn't something we've had elsewhere in the platform... I don't believe we have a scale factor today that would give users the ability today to let users understand what the scale factor is for a layer or view. Could be effected by either the user (e.g. pinch zoom) or the content. As an author I don't have access to this info from the platform. This API will enable that but in an awkward way - creating a webGL binding etc.. Meta point is we're either missing a way to bubble this up a bit further as a more generic platform capability - more than just the webxr context - or be very careful here and maybe not expose it. These have been a pain in the platform - e.g adjusting content to prevent scroll bars - capability has been sought after since forever.
Dan: also - a potential fingerprinting issue.
Rossen: proogogating anything up from the underlying platforms should be done carefully. It's not obvious to me if there are platform layer violations in this spec. Another main scrutiy & privacy concern: how easily and quickly would such capability allow readbacks from unintended actors? Just because my bank added a twitter logo and pulled in some twitter iframe - i don't want them to be able to get a hold of my layer buffer.
2020-11-09
Rossen: we said "this is great" on face value - we need to go and look at the details. I will leave a comment. We need to spend a good time reviewing this.
[bumped to next week, rossen & dan to have breakout]
2020-12-07
Rossen: My take-away is that everything we asked for has been thought of... They are building closely on top of WebXR... There is essentially nothing new that's been added that's been concerning from API exposure. on scale factor - .. he got back to us ... he's saying it's the value of scale factor in consutruction... not what we were thinking.
... a few questions around security & Privacy - he did fill out the questionnaire...
... we asked him to possibly split it. He cited a heavy dependency on webXR to push back. I agree for the spec, I'm not sure about the explainer...
... they may want to break it down to new capabilities...
... the spec itself is split into 6 different logical submodules... lifetime, initialization, type system, event model, rendering model...
... it's marked as "early" but maybe not so early...
Dan: what are you suggesting?
Rossen: the explainer does a good job of reflecting concepts from the spec, but doesn't answer some key questions - goals and non-goals, other potential solutions considered, ... which parts of the examples are newly added capabilities vs new functionality...
... meta-question is do we "hold them back" ?
[taking a look at explainer, s&p questionnaire, etc...]
2021-01-11
Rossen: ability to create layers - which allows for optimisations etc.. in applications such as gaming, whatever... tons of details here. Huge spec. Extension to XR. APIs being added for construction, lifestyle, etc... It's a great addition to the platform but devil in the details. One question was whether they can break into pieces. They prefer not to. We asked if it's an eraly review - from our PoV early - may already be shipping in some places - where we are today is we asked for privacy & security review. We felt the overall direction is good and we are ready to close. We were going to spend more time on security & privacy.
... they have a doc ... They are falling back on "this is an extension of webxr".. so not so much added. Not 100% agree on security because they are adding new object lifetime management - if t's tied to the GPU then I can speculate that the security part is more complex.
Dan: Yeah in their response they didn't go into too much detail.
Rossen: i did post a question about malicious actors - mostly around the privacy side. which was a long way to say - can I obtain visuals from the hosting document and capture what you're seeing? They said "this is not possible". I have confidence in the response.
Dan: it should be in the security & privacy considerations section.
Rossen: I will ask for a bit more detail on lifecycle management of objects and primitives in the compositor. And we can propose closing after that. We're happy with what they're doing.
Ken: they should spell out the mitigations.
2021-01-Kronos
Rossen: The last comment added by Rik is what was missing. With that information we can have a clear expectation of the texture lifetime management and why this isn't a vector for security concerns.
Rossen: propose closing this.
Dan: A-OK
2021-02-15
Rossen: ... asking Rick to add his explanation / concerns to the actual spec or questionnaire...
Dan: I do see the change but not
[realized it's a branching issue]
Dan: [updates the links in the issue]
Rossen: OK I'll write the closing comment.
resolved to close
OpenedJun 19, 2020
Saluton TAG!
I'm requesting a TAG review of the WebXR Layers specification.
WebXR Layers offers a more efficient way of drawing immersive content than WebXR. In addition to support for native textures and texture arrays, it also provides support for different layer types that are managed by the system compositor (as opposed to javascript). This spec is an optional module that extends the feature set of WebXR.
Further details:
We'd prefer the TAG provide feedback as: 🐛 open issues in our GitHub repo for each point of feedback