Hi @cabanier - We are just in the process of reviewing in our virtual f2f. One quick suggestion: I feel like the explainer would be a bit more explainy if you took the firs paragraph from the "use cases" section and moved it to the very top of the document – that way it could provide important context for what I'm reading right under it.

Hi @cabanier. @atanassov and I are just reviewing now in a special break-out. I noticed that you didn't answer the security & privacy questionnaire, opting instead to point us to the spec, but in the spec there is only a very short privacy & consideration section. Can you please try to answer the actual security & privacy considerations questions (in a separate doc - doesn't need to be fancy - a text or markdown doc is fine)? I think there may be more factors you need to consider then what you have listed in the considerations section.

Thanks Dan! I will do so today.

@cabanier one more editorial feedback about the explainer. The two introduction sections offer little motivation to users who aren't deeply familiar with WebXR, rendering or composition. It will go a long way if you can add a bit more details to that end.

Towards the end of the explainer there is usually a section that describes other approaches that were considered and why this is one the best. Given there are so many capabilities in this spec I can see why that could be difficult and hope you can offer at least some view into your decision making.

@cabanier couple of more questions as we read the spec.

It seems that exposing nativeProjectionScaleFactor will enable authors using the feature to obtain the scale factor for a given context (assuming post transform?). If this is the case, my assumption is that such capability will be very sought after many other places in the platform (users of CSSOM have been asking for something like this forever). Could this be either omitted or made available outside the WebXR context?

Have you thought through some of the threat vectors that could abuse such capability? How quickly and easily could a malicious actor create a WebXR context in a different content and obtain the composition layers?

One final meta question. Have you considered, or at least do you think it is feasible to break down this review into few logical pieces that build on top of each other? Layer Types, Spaces, Creation, Rendering etc. That model of reviews will be much more expedient to all of us.

It seems that exposing nativeProjectionScaleFactor will enable authors using the feature to obtain the scale factor for a given context (assuming post transform?). If this is the case, my assumption is that such capability will be very sought after many other places in the platform (users of CSSOM have been asking for something like this forever). Could this be either omitted or made available outside the WebXR context?

nativeProjectionScaleFactor is the value of scaleFactor that was passed in during the construction of the projection layer. It's basically the same as the framebufferscalefactor value in the WebXR spec It is NOT to the "scale factor for a given context (assuming post transform?)". WebXR Layers can only be used in immersive sessions so it has no relation with what is rendered on the page.

Have you thought through some of the threat vectors that could abuse such capability?

There's no new capability with the scale factor. The system will just allocate a buffer where the native buffer size is scaled by this number.

How quickly and easily could a malicious actor create a WebXR context in a different content and obtain the composition layers?

It wouldn't be possible. Immersive WebXR sessions can only be created after a user action and consenting to go immersive. This is not something new that the WebXR Layers spec introduces; this is already covered in the WebXR spec.

One final meta question. Have you considered, or at least do you think it is feasible to break down this review into few logical pieces that build on top of each other? Layer Types, Spaces, Creation, Rendering etc. That model of reviews will be much more expedient to all of us.

As I mentioned earlier, this spec heavily depends on the WebXR specification so in order to review it, one has to be familiar with that one as well. I am planning on adding examples and non-normative explainers to clarify the intent. Right now it's mostly a list of interfaces and flow diagrams which makes it hard to follow.

Can you please try to answer the actual security & privacy considerations questions (in a separate doc - doesn't need to be fancy - a text or markdown doc is fine)?

I added a markdown document here. Please let me know if I need to elaborate more.

I think there may be more factors you need to consider then what you have listed in the considerations section.

Apart from timing of the composition, I'm unsure if there are any other considerations. The spec at its most basic level just exposes new textures to render content to. I'd be happy to have a conversation or to add more to the specification to clarify.

@atanassov @torgo Do I need to do anything else to have this picked up again by the TAG?

@cabanier we're just reviewing in today's TAG call. Thanks for filling out the security & privacy questionnaire - much appreciated. We have no red flags per se, but this is such a big piece of work that we're worried we're missing something. We could do with some more detail in the explainer - specifically "goals and non-goals, other potential solutions considered," also it's not clear to us which parts of the examples are newly added capabilities vs new functionality. Would it be possible for you to join one of our calls in the new year to go through it?

Certainly! I will work on cleaning up the explainer.

@torgo FYI I added "goals and non-goals, other potential solutions considered" to the spec and a couple more clarifications.

Thanks for this Rik - we are generally positive - we're going to spend a little bit more time on the security & privacy review and we will try to close this one off very early in the new year.

@cabanier, we had another look at the security & privacy document, thanks for completing. One question and concern that came up (security more than privacy) is around the lifetime management of layers. Can you elaborate on the coupling between the layer objects and underlying GPU textures or other lower level primitives? How is this proposal ensuring that lower primitives are protected from malicious use?

Ideally this can go directly into the the security & privacy document or the explainer.

@atanassov can you elaborate your concern a bit? The textures are defined to only be valid during a Raf call and after a call to getSubImage/getViewSubImage. If you use them at any other time, they are considered invalid. Is this what you are looking for in the explainer?

ping @atanassov

@cabanier sorry about the delay. @torgo and myself had this scheduled for completion during our current "Kronos" VF2F.

The textures explanation above is what I was missing. If you don't mind adding it to the security section of the spec and/or the privacy and security document.

With that added we are happy to close the review as satisfied.

Thanks @atanassov! I updated the explainer with that information and added some more details. Let me know if you still have questions or concerns.

Thank you @cabanier! Took me a bit to see the change in your explainer only to realize the link here was to 'maser' not 'main' branch :) Anyway, everything looks good and we are excited to see progress being made at W3C Immersive Web WG. Thank you for opening this review and working with us, good luck.