Suppress the VR permission UI when no VR runtimes are detected
Categories
(Core :: WebVR, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox73 | --- | fixed |
People
(Reporter: kip, Assigned: kip)
References
Details
Attachments
(1 file)
We currently show the VR permission UI prompt any time the WebVR api is accessed if the user hasn't already blocked or whitelisted the origin attempting to access VR devices.
This prompt is displayed before enumerating hardware, as the enumeration itself often results in physical devices powering on or software launching persistently in the background (Eg. SteamVR).
We would like to reduce the occurrence of these prompts for users which do not have VR hardware, without causing these inadvertent side-effects of performing enumeration.
This bug track the implementation of a lightweight VR hardware run-time detection routine that will guarantee that can suppress the VR permission UI when it's guaranteed that there will not be any VR hardware attached. This routine will simply check for the presence of runtimes without calling any enumeration API's that have such side effects. The full enumeration would only occur after the VR permission UI is accepted by the user.
|
Assignee | |
Comment 1•5 years ago
|
||
Will this mean that the speed difference between what the API does when runtimes are versus aren't present adds fingerprinting surface? (That is, there would be a difference between the essentially instantaneous response if there's no prompt versus the time it takes the user to accept or dismiss the prompt if there is one.) What portion of users have VR runtimes present, and will the response time of the API be noticeably different to pages between the cases where they are or aren't present?
|
|
Assignee | |
Comment 3•5 years ago
|
||
(In reply to David Baron :dbaron: 🏴 ⌚UTC-8 from comment #2)
Will this mean that the speed difference between what the API does when runtimes are versus aren't present adds fingerprinting surface? (That is, there would be a difference between the essentially instantaneous response if there's no prompt versus the time it takes the user to accept or dismiss the prompt if there is one.) What portion of users have VR runtimes present, and will the response time of the API be noticeably different to pages between the cases where they are or aren't present?
Thanks for taking a look at this, @dbaron!
Indeed, that would be the case. A site would be able to infer the presence of VR runtimes by measuring the time it takes for API calls to return or promises to resolve. The runtime detection could take multiple seconds to complete, as it depends on spinning up the VR process to perform such checks.
Please note that the WebVR successor, WebXR, introduces navigator.xr.isSessionSupported:
https://immersive-web.github.io/webxr/#dom-xr-issessionsupported
isSessionSupported is intended to enable sites to determine if they should show an "Enter VR" button, with the explicit requirement that the UA does not display a permission prompt for this check. This would expose a boolean "supports VR" and boolean "supports AR", but no other details about the hardware or runtimes. My proposed implementation of isSessionSupported for Firefox is to apply the same "runtime detection" logic as used in this patch.
Effectively, WebXR will purposefully allow the results of the runtime detection to be accessed directly without need to perform a timing-based attack on the WebVR API.
I recognize the concern about such timing attacks -- with some effort, it could be possible to infer not just the boolean "supports VR" but also what kind of VR runtime is installed.. As the runtime detection results are cached in subsequent requests, it would also be possible to infer if the page was the first to detect the runtimes within a browser session.
There are two kinds of runtimes detected by Firefox -- Oculus and OpenVR. If such a timing attack was utilized, the user could be classified into one of 4 buckets (No-VR runtimes, Oculus, OpenVR, Oculus+OpenVR) rather than the intended 2 (No-VR runtimes, Any VR runtimes).
@dbaron - Would the risk of such fingerprinting be a large enough concern to require adding some randomized delay to the API?
Please see also:
Bug 1579243 - navigator.xr.isSessionSupported should always return true when privacy.resistfingerprinting is enabled.
There, I am proposing that the "runtime detection" logic always return "true" when resistfingerprinting mode is enabled. This would have the side-effect that users with "resistfingerprinting" enabled would see "enter vr" buttons even if hardware and runtimes are not present for WebXR sites. A prompt would always be presented before a site can perform an actual enumeration of capabilities or further details.
@dbaron - Would the risk of such fingerprinting be a large enough concern to require adding some randomized delay to the API?
I'm not sure. I don't think we have a consensus on how to make tradeoffs between fingerprinting concerns and other issues right now. (It also only seems worthwhile if it would really work, which I'm not fully convinced it would, although I think it likely sounds doable. The random behavior might need to be compared with actual user behavior when prompted.)
|
|
Assignee | |
Comment 5•5 years ago
|
||
|
|
Assignee | |
Comment 6•5 years ago
|
||
I've updated the patch so that it doesn't break immersive VR content on FxR Android.
A corresponding PR has been added to the FxR Android repo:
|
|
Assignee | |
Comment 7•5 years ago
|
||
(In reply to :kip (Kearwood Gilbert) from comment #5)
Try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d19b7e354774769a65787276458d19ade1a08854
It appears that the permission UI was suppressed while under test, causing some failures in the try run. I'll add a pref to allow this to be bypassed, address @bz's review feedback and resubmit for review.
|
|
Assignee | |
Comment 8•5 years ago
|
||
|
|
Assignee | |
Comment 9•5 years ago
|
||
Patch updated again with @daosheng's feedback.
Added many comments and moved some MOZ_ASSERTS..
|
|
Assignee | |
Comment 10•5 years ago
|
||
Cancelled last try push jobs. Updated try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d5f3b61749b6854ea33b6b8a2f6761b13acf823
|
|
Assignee | |
Comment 11•5 years ago
|
||
Attempt to fix test failures in last try push. dom.vr.always_support_vr and dom.vr.always_support_ar can now be changed without restarting the browser.
Updated try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8ceddd0cd943c804aa3b16433be728ca0bb68b4
|
|
Assignee | |
Comment 12•5 years ago
|
||
The patch has been updated with @bzbarsky's feedback and now includes a crash test for the scenario @bzbarsky identified.
Updated try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba7927b8e738177f7e203c9f975f3b3faf2d9d3b
|
||
Comment 13•5 years ago
|
||
|
||
Comment 14•5 years ago
|
||
| bugherder | ||
Description
•