Skip to content

Switch isSessionSupported from using user intent to using permissions #1136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 9, 2020
Merged

Switch isSessionSupported from using user intent to using permissions #1136

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 29 additions & 9 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -343,7 +343,7 @@ When this method is invoked, it MUST run the following steps:
1. Let |device| be the result of [=ensure an immersive XR device is selected|ensuring an immersive XR device is selected=].
1. If |device| is null, [=/resolve=] |promise| with <code>false</code> and abort these steps.
1. If |device|'s [=list of supported modes=] does not [=list/contain=] |mode|, [=queue a task=] to [=/resolve=] |promise| with <code>false</code> and abort these steps.
1. If [=user intent=] to [[#issessionsupported-fingerprinting|avoid advertising their system's XR capabilities]] is well understood, [=queue a task=] to [=/resolve=] |promise| with <code>false</code> and abort these steps.
1. [=request permission to use=] the [=powerful feature=] {{PermissionName/"xr-session-supported"}} with {{XRSessionSupportedPermissionDescriptor}} with {{XRSessionSupportedPermissionDescriptor/mode}} equal to |mode|. If it returns {{PermissionState/"denied"}} [=queue a task=] to [=/resolve=] |promise| with <code>false</code> and abort these steps.
1. [=queue a task=] to [=/resolve=] |promise| with <code>true</code>.

</dl>
Expand Down Expand Up @@ -373,19 +373,39 @@ if (supported) {

### Fingerprinting considerations ### {#issessionsupported-fingerprinting}

A set of user agents is <dfn>indistinguishable by user-agent string</dfn> if they all report the same {{NavigatorID/userAgent}} and {{NavigatorID/appVersion}}. Such classes are typically identified by the browser version and platform/device being run on, but cannot be distinguished by the status of any connected external device. We can use the concept of user agents that are [=indistinguishable by user-agent string=] to properly assess fingerprinting risk.
Because {{XRSystem/isSessionSupported()}} can be called without user activation it may be used as a fingerprinting vector despite the limited amount of information it reports.

<dfn enum-value for="PermissionName">"xr-session-supported"</dfn> [=powerful feature=] gates access to the {{XRSystem/isSessionSupported()}} API in cases where there are fingerprinting concerns.

The {{PermissionName/"xr-session-supported}}’s permission-related algorithms and types are defined as follows:

Because {{XRSystem/isSessionSupported()}} can be called without user activation it may be used as a fingerprinting vector despite the limited amount of information it reports. To reduce the amount of unique information that can be derived from the method, user agents should consider the following mitigations:

Some user agents [=indistinguishable by user-agent string=] will <dfn>never support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents running on a model of phone that is known to not meet requirements for mobile AR support.</span> In these cases there is little fingerprinting risk in {{XRSystem/isSessionSupported()}} always reporting the {{XRSessionMode}} is not supported because every such device will consistently report the same value and it's assumed that device type and model can be inferred in other ways, such as through {{NavigatorID/userAgent}}.
<dl>
<dt>[=permission descriptor type=]</dt>
<dd>

<pre class="idl">
dictionary XRSessionSupportedPermissionDescriptor: PermissionDescriptor {
XRSessionMode mode;
};
</pre>

{{PermissionDescriptor/name}} for {{XRPermissionDescriptor}} is {{PermissionName/"xr-session-supported"}}.


{{PermissionName/"xr-session-supported}} MAY be granted automatically for systems.

A set of user agents is <dfn>indistinguishable by user-agent string</dfn> if they all report the same {{NavigatorID/userAgent}} and {{NavigatorID/appVersion}}. Such classes are typically identified by the browser version and platform/device being run on, but cannot be distinguished by the status of any connected external device. We can use the concept of user agents that are [=indistinguishable by user-agent string=] to properly assess fingerprinting risk.

Some user agents [=indistinguishable by user-agent string=] will <dfn>never support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents running on a model of phone that is known to not meet requirements for mobile AR support.</span> In these cases there is little fingerprinting risk in {{XRSystem/isSessionSupported()}} always reporting the {{XRSessionMode}} is not supported because every such device will consistently report the same value and it's assumed that device type and model can be inferred in other ways, such as through {{NavigatorID/userAgent}}. Thus, on such systems, the user-agent SHOULD automatically deny {{PermissionName/"xr-session-supported}} for the relevant {{XRSessionMode}}.

Other user agents will [=indistinguishable by user-agent string=] <dfn>usually support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents known to support WebXR that run exclusively within VR headsets are likely to support {{XRSessionMode/"immersive-vr"}} sessions unless specifically blocked by the user.</span> In these cases reporting that the {{XRSessionMode}} is not supported, while accurate, would offer more uniquely identifying information about the user. As such reporting that the {{XRSessionMode}} is always available and allowing {{XRSystem/requestSession()}} to fail is more privacy-preserving while likely not being a source of confusion for the user.
Other user agents will [=indistinguishable by user-agent string=] <dfn>usually support</dfn> sessions of a given {{XRSessionMode}}. <span class='note'>For example: User agents known to support WebXR that run exclusively within VR headsets are likely to support {{XRSessionMode/"immersive-vr"}} sessions unless specifically blocked by the user.</span> In these cases reporting that the {{XRSessionMode}} is not supported, while accurate, would offer more uniquely identifying information about the user. As such reporting that the {{XRSessionMode}} is always available and allowing {{XRSystem/requestSession()}} to fail is more privacy-preserving while likely not being a source of confusion for the user. On such systems, the user-agent SHOULD automatically grant {{PermissionName/"xr-session-supported}} for the relevant {{XRSessionMode}}.

User agents [=indistinguishable by user-agent string=] for which availability of XR capabilities is highly variable, such as desktop systems which support XR peripherals, present the highest fingerprinting risk. User agents on such devices MUST NOT allow the {{isSessionSupported()}} API to provide additional fingerprinting bits without there being [=explicit consent=] from the user to do so. This MAY involve one of the following techniques:
User agents [=indistinguishable by user-agent string=] for which availability of XR capabilities is highly variable, such as desktop systems which support XR peripherals, present the highest fingerprinting risk. User agents on such devices SHOULD NOT automatically grant {{PermissionName/"xr-session-supported}} in a way that allows the {{isSessionSupported()}} API to provide additional fingerprinting bits. Some acceptable approaches to handle such cases are as follows:

- Always judging [=explicit consent=] (with a potentially cached permissions prompt or similar) when {{XRSystem/isSessionSupported()}} is called.
- Have {{XRSystem/isSessionSupported()}} always report <code>true</code> even on platforms which do not consistently have XR capabilities available, regardless of whether or not the appropriate hardware or software is present. <span class=note>This comes at the cost of user ergonomics, as it will cause pages to advertise XR content to users that cannot view it.</span>
- Have {{XRSystem/isSessionSupported()}} request [=explicit consent=] when the appropriate hardware is present, and when such hardware is _not_ present, return <code>false</code> after an appropriately random length of time. In such an implementation content MUST NOT be able to distinguish between cases where the user agent was not connected to XR hardware and cases where the user agent was connected to XR hardware but the user declined to provide [=explicit consent=].
- Always judging [=explicit consent=] for {{PermissionName/"xr-session-supported}} (with a potentially cached permissions prompt or similar) when {{XRSystem/isSessionSupported()}} is called.
- Automatically granting {{PermissionName/"xr-session-supported}} but having {{XRSystem/isSessionSupported()}} always report <code>true</code> even on platforms which do not consistently have XR capabilities available, regardless of whether or not the appropriate hardware or software is present. <span class=note>This comes at the cost of user ergonomics, as it will cause pages to advertise XR content to users that cannot view it.</span>
- Have {{XRSystem/isSessionSupported()}} request [=explicit consent=] for {{PermissionName/"xr-session-supported}} when the appropriate hardware is present, and when such hardware is _not_ present, return <code>false</code> after an appropriately random length of time. In such an implementation content MUST NOT be able to distinguish between cases where the user agent was not connected to XR hardware and cases where the user agent was connected to XR hardware but the user declined to provide [=explicit consent=].

Whatever the technique chosen, it MUST NOT reveal additional knowledge about connected XR hardware without [=explicit consent=].

Expand Down