Cross-origin iframe calls to xr.requestSession()

[NellWaliczek]

We've got a number of issues discussing the specifics of feature policy (#308, #729, #730, #731), the outcomes of which will apply to any document. Perhaps I missed it, but I don't see any specific discussion on whether we should allow cross origin calls to requestSession(). In other words, should we be disallowing cross-origin iFrames to create sessions regardless of what we end up doing with feature policy?

To be suuuuper clear, I'm not taking a stance one way or the other. I'm just writing up explainer/spec text and wanted to make sure I wasn't missing subtle opinion that might need digging into more.

[klausw]

By "cross-origin calls to requestSession", I assume you mean the iframe has a separate origin from the outer document, but the requestSession() call itself would be done by the iframe page's code? In other words, the iframe content basically does the same thing it would be doing as if it were running as a standalone page. (An alternate interpretation would be that the outer document would initiate requestSession for the iframe content or vice versa.)

If I remember right, this scenario previously came up in the context of WebVR 1.1, and one argument of allowing iframes to start sessions was to support interactive code editors such as codepen and jsfiddle which may internally be using other-origin iframes for hosting user-edited content. It would be unfortunate if such sites would be blocked from letting people experiment with WebXR.

[johnpallett]

For context, the proposed privacy design in #638 allows the creation of cross-origin experiences, provided all of the general session creation options are met, and feature policies are observed. Those requirements were largely modeled after the requirements for exposing sensor readings using the Generic Sensor API. As Klaus suggests, my understanding is that this requires the code requesting the session to be same-origin as the iframe itself.

The privacy design proposal does not currently include a WebXR-specific feature policy, only because that topic was still in open discussion when the design was written.

The privacy design proposal does require that feature policies for underlying sensors be respected, if the x-origin site could isolate and extract sensor data that would otherwise be blocked by sensor feature policy. The rationale for this is that it'd be undesirable for WebXR to be a 'back door' to accessing data that is otherwise prevented by feature policy - for example, if pose data could be used to extract device orientation data, and there is a feature policy disabling access to orientation data. Whether this was required on a given platform would likely vary depending upon which sensors are used to generate XR data, and how they're used.

[Squareys]

(Context: I'm one of the devs of the VR browser games platform Construct Arcade)

We have a use case were allowing cross-origin use of the API is beneficial: currently we embed WebVR/WebXR games in same-origin iframes since we need to be able to shim WebVR/WebXR API versions in addition to what the official polyfill and version-shims provide (plus some inject some Construct Arcade SDK credential stuff).

Some developers want to keep control of their game's code and assets: they want to host those themselves what would make it awesome if some day our "same-origin" requirement on the iframes could be removed.

As far as I understood, this would still be possible with the policies, if explicitly given permission to requestSession to the iframe?

(Btw: It would be super interesting to be able to forward an existing session to an iframe, but I would assume that takes the discussion way off topic and is achievable with same-origin iframes, so feel free to ignore this part.)

[NellWaliczek]

Ok, sounds like we're in agreement on this one and the appropriate spec text is already in place, so I'm going to go ahead and close this.

@Squareys, I'm not entirely sure I follow the last part of your comment. If you mean moving a session object between same origin iFrames, that would really be an example of moving an object between iFrames and wouldn't really be a WebXR specific thing.

[Squareys]

@NellWaliczek Suppose the parent document already acquired a session (e.g. a in-VR loading screen for some game, which will be loaded in the iframe) and now wants to give control of that session to the iframe (the loaded VR game) without exiting VR and requiring another user gesture.

While this is a matter of moving objects between iframes, I am unsure if this will work with a WebXR session object. As everything serializable with the "Structured clone algorithm" can be sent to an iframe via window.postMessage, that includes most types, but not DOM nodes for example.