[Feature Policy] Consider implications and practicality of requiring authors to enable policy-controlled features for underlying sensors

[ddorwin]

https://immersive-web.github.io/webxr/#feature-policy currently says:

In addition to the "xr" feature policy, feature policies for underlying sensors must also be respected if a site could isolate and extract sensor data that would otherwise be blocked by those feature policies.

While the motivation (in the explainer and more details in #732 (comment)) makes sense, the implications and practical considerations might mean this is not the best decision for users, developers, and implementations.

Perhaps most importantly, should user agents implement this requirement and application developers grant the necessary policies (i.e., the union of policy-controlled features required for all implementations devices), those developers would be allowing (direct) access to all such features (i.e., for cross-origin iframes) regardless of whether the underlying XR implementation needs it.

As an illustrative example, consider the case where a specific underlying sensor is used by a small portion of all user devices. In order to support them, an application must allow (direct) access to that underlying sensor data across all user agents. Or consider the case where an underlying sensor's data was previously accessible but this "back door" has been closed by the implementation or such devices are no longer in use; most applications that supported such devices would likely continue to allow (direct) access to that underlying sensor data across all user agents (either because the application is no longer maintained or the developer is unaware that it is safe to make the change).

In addition, it is worth considering the implications for both developers and implementers and whether this is the best solution.

For application developers:

• What developers really want to say is "I want this site to be able to use XR hardware."
• Developers must know all such underlying sensors that might be used and include all of them.
• As new underlying sensor technologies are used, developers will need to update their code to support new devices that use them.
• Similarly, as underlying sensors that aren't currently directly exposed by the web platform get exposed, new policies will become required for implementations and devices that previously worked without them.
• If developers fail to do the three previous items, their applications may not work - or stop working - across user agents and devices.
• Developers may not want to allow the dedicated API as they only care about WebXR, which has explicit intent, usage indication, use case-specific privacy considerations, etc. (Caveat: It's unclear whether Feature Policy enables APIs or capabilities - see [Feature Policy] Confirm whether WebXR features can/should reuse existing feature names #765.)
• Feature Policy for WebXR is already going to be complex (i.e., [Feature Policy] Validate the plan for dependent policy-controlled features #763).
• Developers are equally likely not to understand what data access "xr" allows if we do not require feature policies for underlying sensors as they are to not understand that they need to allow the underlying sensor features if we do require them. At least in the latter (current) case, they will (hopefully) see failures, though it's not clear that this will lead them to consider whether they want to allow such access.

For implementations:

• This puts a lot of responsibility on implementers to understand the underlying sensor data used by a device and make an evaluation of whether "a site could isolate and extract sensor data." This might be a different evaluation and/or more complicated than ensuring the user is adequately informed per other privacy-related requirements.
• This seems like an area that could see a lot of divergence - both across XR devices and even across browsers supporting the same XR device.
• Implementations may be incentivized to not follow this requirement, especially if others have not or made different interpretations or when supporting a device that makes use of a new underlying sensor.
• As is the case for developers, implementers will need to continually re-evaluate and upgrade as a) new underlying sensors are exposed by new web platform APIs and/or b) new devices are released (for existing supported runtimes) that use different underlying sensors.

Other considerations:

• The conclusion of Should the Feature Policy feature name be changed from "vr"? #308 appears to be that allowing the "xr" feature implies that VR is allowed regardless of the way in which VR is implemented (i.e., [Feature Policy] Should "inline" with sensors ("magic window") be controlled by the same feature policy as immersive VR (headsets)? #730 but also more advanced mechanisms among HMDs). Does it not follow that this feature also allows access to all related necessary data - even if that is not otherwise directly allowed?
• If Feature Policy is intended to cover features/APIs rather than capabilities (see [Feature Policy] Confirm whether WebXR features can/should reuse existing feature names #765), then this requirement would not make sense because it is addressing capabilities (access to sensor data).
• New functionality may (see [Feature Policy] Confirm whether WebXR features can/should reuse existing feature names #765) reuse existing permissions where possible, which might mean this is mostly an issue for pose data.

[johnpallett]

I agree with the reasoning here and I share the concern about the anti-pattern of developers adding feature policies for sensors that may or may not be needed for a given platform, but which would give the origin access to those sensors outside of the XR session.

An open concern however is how to handle the situation where a sensor feature policy is explicitly blocked either in the http header field or by an iframe allow attribute. This can be done by using the none keyword when creating an allowlist.

I'd suggest that this is unlikely for iframes. AFAICT feature policies for Generic Sensors will be disabled in x-origin iframes by default, because the default for Generic Sensors features is 'self' and x-origin iframes do not inherit a 'self' policy from their parent. This suggests that a developer would be unlikely to explicitly block those sensors, since they are already blocked by default.

Such explicit blocking might however be part of the http header field and AFAICT it is possible that such a policy could be in place for the top-level parent to block a sensor, without similarly blocking WebXR. In that case, WebXR might be used as a workaround to access a meaningful approximation of the blocked sensor data in spite of a feature policy that is clearly intended to prevent such access.

It's not immediately clear to me how to specify the situation where a feature policy is explicitly blocked. Until we resolve this, I'd suggest we remove the restriction on underlying sensor data policies to avoid the anti-pattern mentioned above. I'll add suggestions to #761 to that end for consideration.

As a final note, some other sensor types (e.g. deviceorientation) do not appear to have a feature policy.

[probot-label]

This issue is fixed by PR #842