1579243 - navigator.xr.isSessionSupported should always return true when privacy.resistfingerprinting is enabled

Status: NEW

(Core :: WebVR, task, P3)

Description

[:kip (Kearwood Gilbert)]

When privacy.resistfingerprinting is enabled, WebXR should be disabled.

This should be handled and tested in the same way as geolocation, in Bug 1372069.

A test should be implemented, similar to:

browser/components/resistfingerprinting/test/mochitest/test_geolocation.html

Comment 1

[Tom Ritter [:tjr]]

Bug 1372069 was reverted in Bug 1441295 and RFP mode allows geolocation if the user has accepted the permission prompt.

It looks like Bug 1579281 is for implemented a permission prompt, and I think RFP would allow the prompt to be shown. If there is anything exposed before the prompt - like does the user have hardware or not - we would want to mitigate that information leak in RFP mode.

Comment 2

[:kip (Kearwood Gilbert)]

Thanks for investigating, @tjr!

Prior to the permission prompt, the WebXR API limits information about the VR devices to the minimal needed to present an "Enter VR" button on the page. This is exposed with navigator.xr.supportsSession:

https://immersive-web.github.io/webxr/#dom-xr-supportssession

There is also an event, navigator.xr.ondevicechange, indicating that the available capabilities may have changed:

https://immersive-web.github.io/webxr/#dom-xr-ondevicechange

The only information returned is a boolean for each kind of session that can be created. Currently, this is limited to "inline" and "immersive-vr".

"inline" would always be enabled, as it does not require VR or AR specific hardware.
"immersive-vr" would be enabled any time there is VR hardware available.

In order to get more details (eg, the particular kind of hardware, its display resolution, and spatial tracking features), the page would need to call the navigator.xr.requestSession function, which would trigger this permission prompt.

Does this sound reasonable, in the case where privacy.resistfingerprinting is enabled?

If so, then we can keep this enabled when privacy.resistfingerprinting is active :-)

Comment 3

[Tom Ritter [:tjr]]

What happens when a website calls navigator.xr.requestSession and the user doesn't have hardware? Is the permission prompt still shown, or is it auto-declined?

Saying inline is always available is fine; all users will be in the same bucket. But because immersive-vr only will be true for users with hardware; they will stand out. When RFP is active, we'll want to report 'false' for this (and also not report ondevicechange events). Is it easy to do this without also disabling inline?

Matt (sysrqb) would be the final decider here; but I think a future improvement to accommodate RFP would be to enable - somehow - a user to pre-grant the permission to an origin and when that is done we would report true (when appropriate) for immersive-vr, fire ondevicechange events, and then any permission query would auto-grant (like usual if the user chose to save the permission).

Comment 4

[:kip (Kearwood Gilbert)]

(In reply to Tom Ritter [:tjr] from comment #3)

What happens when a website calls navigator.xr.requestSession and the user doesn't have hardware? Is the permission prompt still shown, or is it auto-declined?

Saying inline is always available is fine; all users will be in the same bucket. But because immersive-vr only will be true for users with hardware; they will stand out. When RFP is active, we'll want to report 'false' for this (and also not report ondevicechange events). Is it easy to do this without also disabling inline?

IIUC, the spec gives some room for the UA to do what it needs here. I believe we would not break content that is spec compliant if we had navigator.xr.supportsSession always return true, but fail the navigator.xr.requestSession call when we see that there is actually no hardware. An unfortunate side effect; however, is that pages that progressively support both VR and AR experiences may choose incorrectly and not offer the other option when the requestSession call fails. Another side effect is that users with resistfingerprinting enabled would see "enter VR" buttons on many sites even if they don't actually have VR hardware.

Other than understanding these consequences, it is not technically hard to implement this behavior.

Matt (sysrqb) would be the final decider here; but I think a future improvement to accommodate RFP would be to enable - somehow - a user to pre-grant the permission to an origin and when that is done we would report true (when appropriate) for immersive-vr, fire ondevicechange events, and then any permission query would auto-grant (like usual if the user chose to save the permission).

This would be excellent!

Comment 5

[:kip (Kearwood Gilbert)]

I've updated the description of the bug to match the solution in Comment 4.

Comment 7

[Thorin [:thorin]]

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #1)

It looks like Bug 1579281 is for implemented a permission prompt, and I think RFP would allow the prompt to be shown. If there is anything exposed before the prompt - like does the user have hardware or not - we would want to mitigate that information leak in RFP mode.

^^ emphasis mine

now bug 1579281 has landed - I just want to point out that there were concerns about FPing using timing attacks : see https://bugzilla.mozilla.org/show_bug.cgi?id=1603825#c2 and the subsequent comment

I think the simplest solution is for when RFP is on, to silently deny the prompt (if I understand it correctly, that should mitigate any timing attacks?) unless the site has been whitelisted. RFP is not front facing, but long term we would need to think how we indicate that RFP is blocking to the end user

Comment 8

[Tom Ritter [:tjr]]

(In reply to Simon Mainey from comment #7)

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #1)

It looks like Bug 1579281 is for implemented a permission prompt, and I think RFP would allow the prompt to be shown. If there is anything exposed before the prompt - like does the user have hardware or not - we would want to mitigate that information leak in RFP mode.

^^ emphasis mine

now bug 1579281 has landed - I just want to point out that there were concerns about FPing using timing attacks : see https://bugzilla.mozilla.org/show_bug.cgi?id=1603825#c2 and the subsequent comment

I think the simplest solution is for when RFP is on, to silently deny the prompt (if I understand it correctly, that should mitigate any timing attacks?) unless the site has been whitelisted. RFP is not front facing, but long term we would need to think how we indicate that RFP is blocking to the end user

Yes - if the site can determine if user hardware is present based on whether the prompt is immediately declined vs not-immediately-declined then RFP mode should definitely auto-decline the permission request initially.

Ideally I think we would auto-decline (from the websites perspective) but then still show the permission prompt, and allow the user accept/deny it. The website probably won't handle this gracefully, and the user would need to reload the page, but that is okay (from RFP's point of view.)

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 10

[Tom Ritter [:tjr]]

I'm not ever sure if we have XR in the browser anymore; but I'll let this bug get closed with the rest of the XR bugs so it doesn't get disconnected from that effort...