Privacy: Interaction of existing permission-based features with WebXR feature consent

[ddorwin]

We should ensure that the feature selection and privacy design addresses the interaction of existing permission-based features with the WebXR feature and/or consent mechanism(s).

A concrete example involves AR, which involves rendering what the user sees, which may come from the camera, and existing camera-access APIs. The idea behind "AR Mode" and the entry interstitial was to be able to convey to the user the privacy implications and scope of consent. However, (unless we do something to prevent it) applications can still have access to camera via getUserMedia().

Thus:

• If the origin already has camera access, the message displayed to the user is incorrect - the application could be recording the user's (visual) environment even though it's not WebXR that enabled this.
• The application could request camera access from within the session, which could change the implications about which the user had been carefully informed when consenting to the session creation.
  • Worse yet, this camera access permission is likely to be persisted beyond the XR session (the scope about which the user was told).
  • This will become additionally confusing when aligned camera access is added to WebXR because the lifetimes of the consent will likely be different for the two APIs for which users will not understand the difference.
    • Furthermore, applications may thus be incentivized to use getUserMedia() inside AR sessions to avoid future prompts.
• In both cases, users are unlikely to understand the implications of combining the various types of access. There is more discussion of this here.

Related to this, a aligned camera access API will need to decide whether it interacts with or is orthogonal to the existing camera permission (and policy-controlled feature).

[avadacatavra]

As mentioned here, I think it's important to maintain consistency between existing permissions and XR permissions.

@ddorwin to see if I understand what you're saying:

1. I grant camera access to foo.com, then enter an XR experience. Camera access is then persisted throughout the XR session and upon XR termination, I return to foo.com and still have camera access
2. I grant camera access when entering an XR experience from foo.com explicitly for the XR session. Upon termination, the camera access should also be terminated otherwise we would persist the consent outside of the context in which it was granted

[ddorwin]

As mentioned here, I think it's important to maintain consistency between existing permissions and XR permissions.

It's not clear that XR-related consent will be permission-based. Please see the last few paragraphs of #689 (comment), especially the part about the distinction between "permissions" and "user consent." Session-scoped consent (relevant: #721) makes that distinction especially important.

@ddorwin to see if I understand what you're saying:

1. I grant camera access to foo.com, then enter an XR experience. Camera access is then persisted throughout the XR session and upon XR termination, I return to foo.com and still have camera access

If all of that is getUserMedia(), then there is no real change in the introduction of XR. The main concern would be if the user agent had told the user that the application doesn't have camera access when, for example, starting an AR session. Things get more complicated, however, when a WebXR-specific frame-aligned camera data API is added. At that time, we would need to decide whether this new API respects the existing camera permission or requires explicit XR-specific consent.

2. I grant camera access when entering an XR experience from foo.com explicitly for the XR session. Upon termination, the camera access should also be terminated otherwise we would persist the consent outside of the context in which it was granted

This seems a bit odd since the duration of consent for getUserMedia() depends on whether it was called inside an XRSession. (That doesn't mean this isn't better for the user.)

There may not be anything specifically wrong with persisting such consent outside the session if we're talking about getUserMedia() - except that the different durations of consent could be confusing to users. Additionally, there may be good reason to handle an XR-specific frame-aligned camera data API differently as described above.

[NellWaliczek]

Do we have an example we can use that isn't getUserMedia() since sort of straddles the line between being tied into WebXR vs. orthogonal (and as of yet there actually a design for how we'd expose device-aligned camera feeds.). What about perhaps geolocation or uh... notifications... or bluetooth?

[probot-label]

This issue is fixed by PR #900