Requiring multiple frames of reference

[NellWaliczek]

In PR #409 an optional session creation argument was added that allows developers to block a session from being created if it will be unable to provide a specific type of frame of reference. The current design only allows pages to block on a single frame of reference type, but it’s possible that a scene may wish to block on more than one. For example an unbounded experience which wants to switch to a bounded experience and back again.

Naively, the simple solution would be to change the requiredFrameOfReference to accept an array rather than a single item. The question is, should the requestSession() call reject if none of the required frames of reference are available or if at least one is unavailable.

My inclination is to reject if none are available since the requestFrameOfReference() call accepts an array of desired types.

Any objections?

[johnpallett]

Nell is one outcome of this that the UA could enforce privacy/security requirements for all potential session types at creation time, instead of on-the-fly? For example, if the UA hypothetically applied different policies for bounded vs. unbounded, those policies could be evaluated at session creation?

[NellWaliczek]

For example, if the UA hypothetically applied different policies for bounded vs. unbounded, those policies could be evaluated at session creation?

I'm not entirely sure what you mean by this part... do you mean different policies based on immersive vs. inline sessions?

[NellWaliczek]

Also, to follow up, this issue was discussed at TPAC and the conclusion was that the single value should be expanded to an array in which only one type needs to be supported for session creation to succeed. I'll get a PR posted shortly with this change.

[johnpallett]

For example, if the UA hypothetically applied different policies for bounded vs. unbounded, those policies could be evaluated at session creation?

I'm not entirely sure what you mean by this part... do you mean different policies based on immersive vs. inline sessions?

A potential difference between bounded and unbounded sessions is how much position data the UA shares with the site. For example, a UA might limited a bounded session to 10m from center whereas an unbounded session might be unlimited in terms of how far the user can go.

In that case, it's theoretically possible that with the unbounded session a site could infer a user's geographical location by using trajectory information from the pose and correlating it with 'known pathways'. This probably wouldn't be a threat vector with the bounded session (because it's limited to such a small space).

Because of this difference in threat vectors, the UA might have a different policy for unbounded sessions (e.g. notifying the user that their geographical location might be disclosed while asking for consent) than for bounded sessions.

IIUC the approach here (providing an array of session types) could allow the UA to apply the superset of policy requirements for the requested session types. For example, suppose a site was going to start in a bounded session, and change to an unbounded one later. If the site provides both types at session creation, then the UA could notify the user about geographic location then, instead of requiring a prompt later when the session type changes. Is that part of the intent here?

[NellWaliczek]

Resolving this issue is on hold while we work on solutions for #423 and #424

[probot-label]

This issue is fixed by PR #739

[NellWaliczek]

Closed by #739