[Feature Policy] What should be the policy-controlled features for WebXR?

[ddorwin]

[This is one of the decisions to make as part of resolving #308.]

We need to decide what categories of functionality we want applications to be able to enable/disable via Feature Policy, especially for third-party iframes. These will be new policy-controlled features.

This might be "xr" for access to the API, "vr" for VR functionality, and/or "ar"/"rwu"for real world understanding.

However, note that policy-controlled features tend to cover types of powerful access and be one per API or even cover multiple APIs.

Thus, it's possible that we'll want to instead define policy-controlled features that describe the type of information the application will have access to.

Note also that not all VR headsets present the same level of privacy concerns. For example, a site that allows an iframe to use WebXR for a VR video may not expect that iframe to also get access to eye tracking.

[ddorwin]

Assuming there are multiple WebXR-related policy-controlled features, we'll also need to decide whether there are any "implies" relationships (i.e., "ar" implies "vr"). It seems like this might have the potential to be regrettable as hardware evolves. This decision should come after addressing the main questions above.

[ddorwin]

Expanding on the original description:

• It's perhaps relevant to consider that the most common use of Feature Policy is an "On" switch for third-party iframes (where the default is "Off" for most new policy-controlled features). Thus, developers are deciding whether to grant access to an untrusted party. (While Feature Policy can also be used to prevent your own pages from doing things, this seems less relevant for XR.)
• We'll need to decide whether to divide things based on type of experience, API, or capabilities enabled.
  • The learnings and outcome of [Feature Policy] Confirm whether WebXR features can/should reuse existing feature names #765 are probably relevant here.
• One difficulty is that even "VR" is not a finite space. For example, VR systems might add tracking or other capabilities that raise concerns similar to those for AR.
  • Should we give developers the option of differentiating such access?
  • Conversely, should we take steps to avoid implying that XR-related policy controls are intended to provide control over the specific types of data that are exposed?

In addition, note that we can't practically add granularity later - going with ""xr" implies VR" (the outcome of #308) now means that developers will need to assume that "xr" gives access to all data that might fall under "VR" even if future versions of the specification and/or implementations move some functionality to separate policy-controlled features.

[ddorwin]

The outcome of #308 is that all features included in "VR complete" are controlled by "xr". Thus, the question this issue poses is partially answered. It's perhaps worth reviewing the text above to see if there are any concerns with this outcome.

Beyond that, this issue mainly applies to future features and serves as background for #770.

[probot-label]

This issue is fixed by PR #842