"responsible" is not an adjective that can be applied to documents

[bzbarsky]

There are a few places in https://immersive-web.github.io/webxr/ that talk about "a responsible document" or "document is not responsible" with links to https://html.spec.whatwg.org/multipage/webappapis.html#responsible-document

That linked-to thing is a definition of a property of script settings object, and the property's name is "responsible document". There is no separate concept of "responsible" that applies to documents in the specs right now.

Maybe the spec means "is the responsible document of some settings object"? Does the spec really mean that, as opposed to, say "a document that has a browsing context" in the sense of https://html.spec.whatwg.org/multipage/browsers.html#concept-document-bc? (Those concepts are not identical, but they are for documents that are the active document of their browsing context, and doing the browsing context check would lead to a somewhat-natural fix to #872 as well, since you would then have a browsing context.)

[bzbarsky]

@a2sheppy

[bzbarsky]

Of course not all places that check for "responsible" check for "active", and the "active" check in "active and focused" doesn't check for "active" either.... so I am really not sure what this is aiming to check for and hence what the right check should be.

[asajeffrey]

see also #497, especially #497 (comment)

[asajeffrey]

my rough plan for this is to make every object created by XR to be created in the realm of a particular XR object, which in turn is in the realm of a Navigator, which determines the browsing context. This will at least give a settings object, from which we can get the responsible document.

Now, what the right check then is I'm not sure about; I suspect it's that the document is fully active.

[asajeffrey]

@bzbarsky if you want some more head-scratching, the corner case I'm currently mulling over is that the WebGL context can come from a canvas in a different document from the XR object, so isn't necessarily in the same realm. So, should the same-origin policy apply? If so, when do we do the same-origin checks, do we do it on every rAF just on the off chance that someone has set document.domain?

[bzbarsky]

So the entry points involved here are .. what?

I see XR.prototype.requestSession. There's no particular WebGL context there; just an XR object, right? This does a "immersive session request is allowed" check, which does one of the "responsible" checks. Presumably this should all operate on the relevant document of the XR object? But what security policy is it actually trying to enforce and why?

The other entrypoint I see is still requestSession, this time doing "inline session request is allowed". Again, what is the purpose of the check?

None of that seems to involve a WebGL context in any obvious way at first glance.

In general, if things you don't want to be reacting to document.domain changes in any way. IF you have your hands on objects, you can work with them.

[asajeffrey]

@bzbarsky the XR session gets it's GL context given to it as part of https://immersive-web.github.io/webxr/#dom-xrsession-updaterenderstate, which includes a baseLayer https://immersive-web.github.io/webxr/#xrwebgllayer that includes a https://immersive-web.github.io/webxr/#typedefdef-xrwebglrenderingcontext context, which can be a WebGLRenderingContext accessed from any canvas.

The XR session implicitly updates the state of the context, for example by flushing its GPU pipeline, swapping buffers on the XR framebuffer, and presenting the XR framebuffer contents to the user via the XR device. None of that calls any methods on the context, so there's no security checks, but like you said "IF you have your hands on objects, you can work with them."

I think the important parts of https://immersive-web.github.io/webxr/#immersive-session-request-is-allowed are 1 and 3, which are "triggered by user activation or launching a web application" and "explicit consent or implicit consent," I share your confusion around 2 "the requesting document is not considered trustworthy", which requires the document (I presume the one associated with the XR object) to be "responsible" (which like you say, is a category error) and active and focused.

Looking over the git history, this seems to be #761. @toji do you know what the motivation for https://immersive-web.github.io/webxr/#trustworthy was?