Closed Bug 1381628 Opened 7 years ago Closed 4 years ago

Provide UI to enable users to control which sites have access to their VR device configuration and sensors

Categories

(Core :: WebVR, enhancement, P2)

Product:
Core
Component:
WebVR
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox57 --- affected

People

(Reporter: kip, Assigned: jkt)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fingerprinting][fp-triaged])

Attachments

(2 files, 1 obsolete file)

Bug 1381628 - WIP patch for web vr permission prompts.
59 bytes, text/x-review-board-request
johannh
: feedback+
Details
webvr-16.svg
784 bytes, image/svg+xml
Details 
The WebVR API supports two states.

The first is a non-presenting state where the VR hardware can be enumerated, the configuration of the VR environment accessed, and the positional data from sensors be accessed.  This is often used for development purposes, "magic window" sites, tools, and to enable web sites to detect when to present UI for starting VR versions of their experiences.

The second is the presenting state.  A user gesture is required before a non-presenting state can be promoted to a presenting state.  Alternately, a non-presenting state can be started immediately, during vr-to-vr link traversal through the vrdisplayactivate event.  Only after the user gesture requirement has been met at the entry point to the WebVR navigation session, can any site present content within the VR headset.

WebVR content inherently requires access to the VR configuration and sensor data, such as:

- IPD (Interpupillary distance / distance between a users eyes)
- The position and orientation of the user's head within 3d space
- The position and orientation of the user's controllers within 3d space.
- Dimensions of the configured play area on the floor.

Unfortunately, this information can also be utilized by sites for fingerprinting.

Proposed solution:
------------------

I propose that we leverage a similar approach as that used by Media Capture api's.  The WebVR API includes a single entry point, Navigator.getVRDisplays(), which returns a promise.  When that call is made, we can display a doorhanger prompt giving the user some options before allowing the promise to resolve:

https://somevrsite.com/ would like to access your VR hardware, this includes information that may be able to uniquely identify you.  (Link for more information)
- [Button] Allow this site to access my VR hardware
- ]Button] Allow any site to access my VR hardware
- [Checkbox] Remember this.

This prompt should only be displayed in the event that the promise would have been successful, to avoid annoying users that do not have any VR hardware.

Ideally, the user should also be able to access and edit the list of websites that they have approved.
Blocks: 1352418
Some notes from Johann:

"I absolutely agree that you should use the permission manager and the associated prompts for this. That's what they were built for. It makes things consistent for our users and should hopefully save you some implementation time. I'll assume you want to use nsIContentPermissionRequest, like e.g. Geolocation and Desktop-Notifications and not the hacks that the WebRTC team is using (WebRTC has special requirements for permission prompts, such as knowing which device the user selected).

You can find a relatively good example solution for only the frontend parts in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1309123
You can see that the biggest part of that patch is adding strings, markup, icons and boilerplate code.

The WebVR platform code will need to implement nsIContentPermissionPrompt (https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsIContentPermissionPrompt.idl), which I think is also mostly boilerplate. You can find examples for that in the different platform implementors (https://searchfox.org/mozilla-central/search?q=nsicontentpermissionrequest&case=false&regexp=false&path=), e.g. nsGeolocation.cpp."
Assignee: nobody → jkt
I think I know what to do based on Johann's feedback.

Would there be any interest in exposing this just to TLS connections? All new web APIs are usually exposed through Secure contexts and it would be a simple patch that we could likely uplift.
Flags: needinfo?(kgilbert)
A couple of remarks on the proposed solution:

(In reply to :kip (Kearwood Gilbert) from comment #0)
> Proposed solution:
> ------------------
> 
> I propose that we leverage a similar approach as that used by Media Capture
> api's.  The WebVR API includes a single entry point,
> Navigator.getVRDisplays(), which returns a promise.  When that call is made,
> we can display a doorhanger prompt giving the user some options before
> allowing the promise to resolve:
> 
> https://somevrsite.com/ would like to access your VR hardware, this includes
> information that may be able to uniquely identify you.  (Link for more
> information)
> - [Button] Allow this site to access my VR hardware
> - ]Button] Allow any site to access my VR hardware
> - [Checkbox] Remember this.

To be consistent with the other permission doorhangers, the buttons should be:
- [Button] Allow
- ]Button] Don't Allow
- [Checkbox] Remember this decision.

This pattern has been through UX research and will be easy for users to understand, since it mirrors all our existing prompts. The decision the user can make in these prompts is always local to the origin they're visiting. Note that there's one clear confirm and one clear deny action, they are visually distinct. This duality is the only thing that's supported by our doorhangers right now (on purpose) and I would strongly recommend following the pattern.

Also note that globally setting a permission for all origins is being implemented in bug 1379560. So that won't be possible until the bug is resolved.

> This prompt should only be displayed in the event that the promise would
> have been successful, to avoid annoying users that do not have any VR
> hardware.

Yes, absolutely! :)

> Ideally, the user should also be able to access and edit the list of
> websites that they have approved.

We're working on a "white label" solution for this in bug 1275599 and should finish around the 57 timeline. Then you can just add a few lines of preferences code to make it happen.

Let me know if you need more information.
It looks to me like we should disable VREvents for a window object if the user has disabled the permission also just to reduce overhead.
Also do we have the relevant icons for the permission prompts? Who would we speak to about that if we don't?
(In reply to Jonathan Kingston [:jkt] from comment #5)
> Also do we have the relevant icons for the permission prompts? Who would we
> speak to about that if we don't?

Bryan, can you help us get some amazing WebVR permission icons?
Flags: needinfo?(bbell)
Attached a WIP patch of the JS side, I need to hook it up to the Navigator.cpp next.
:johannh, if you have some time to just check this is the right direction that would be super helpful.

I added in the mozscreenshots code too which currently won't work. I'm not sure how we can make this fake devices like the webrtc do.

I also need to add the icons when I get them back also. :bbell let me know if you need info on what icons we have. There will be a URL bar one and also a door hanger icon.
(In reply to Jonathan Kingston [:jkt] from comment #2)
> Would there be any interest in exposing this just to TLS connections? All
> new web APIs are usually exposed through Secure contexts and it would be a
> simple patch that we could likely uplift.

Yes, Kip and I talked about it too. It's tracked in bug 1381645.
Flags: needinfo?(kgilbert)
(In reply to Johann Hofmann [:johannh] from comment #3)
> A couple of remarks on the proposed solution:
> 
> (In reply to :kip (Kearwood Gilbert) from comment #0)
> > Proposed solution:
> > ------------------
> > 
> > I propose that we leverage a similar approach as that used by Media Capture
> > api's.  The WebVR API includes a single entry point,
> > Navigator.getVRDisplays(), which returns a promise.  When that call is made,
> > we can display a doorhanger prompt giving the user some options before
> > allowing the promise to resolve:
> > 
> > https://somevrsite.com/ would like to access your VR hardware, this includes
> > information that may be able to uniquely identify you.  (Link for more
> > information)
> > - [Button] Allow this site to access my VR hardware
> > - ]Button] Allow any site to access my VR hardware
> > - [Checkbox] Remember this.
> 
> To be consistent with the other permission doorhangers, the buttons should
> be:
> - [Button] Allow
> - ]Button] Don't Allow
> - [Checkbox] Remember this decision.
> 
> This pattern has been through UX research and will be easy for users to
> understand, since it mirrors all our existing prompts. The decision the user
> can make in these prompts is always local to the origin they're visiting.
> Note that there's one clear confirm and one clear deny action, they are
> visually distinct. This duality is the only thing that's supported by our
> doorhangers right now (on purpose) and I would strongly recommend following
> the pattern.
> 
> Also note that globally setting a permission for all origins is being
> implemented in bug 1379560. So that won't be possible until the bug is
> resolved.
> 

Thanks for all the help getting this going!

The reason we wanted an "allow for all sites" is that users can follow links in VR from one site to another, and this may be across origins.  The challenge is that with the headset on, the user won 't see the doorhanger prompt.

I propose that we continue with the pattern found best by UX research (Allow / Don't Allow / Remember), but then make the same options available from within the headset itself.

We are just starting to scope the work needed to display such choices in the headset.  Perhaps we could integrate it with the doorhanger UI universally so that other prompts can be responded without taking the headset off as well.

I'll file a separate bug that references this one to keep track of this work.
(In reply to Johann Hofmann [:johannh] from comment #6)
> (In reply to Jonathan Kingston [:jkt] from comment #5)
> > Also do we have the relevant icons for the permission prompts? Who would we
> > speak to about that if we don't?
> 
> Bryan, can you help us get some amazing WebVR permission icons?

This will be the first VR related icon displayed by the Firefox UI, I look forward to seeing what you come up with!

May I recommend visiting the #vr slack channel and talking with the folks there during the design?  There is some established visual language that has organically grown and become standard in the WebVR content that could be useful to reference.
See Also: → 1383840
I have added Bug 1383840 to cover the implementation of the VR interface for the doorhanger prompts.

Also, see Bug 1383838 ([meta] Implement in-HMD interstitial UI for Firefox) for details on how such prompts may interact with the variety of VR hardware and use cases.
Kip, that's a good starting point. Since there's no browser chrome in VR we will have to be able to show trusted UI elements within headset sooner that later to inform about errors, page URLs, permission prompts...

We can start following the behavior of Firefox today but in parallel think about the specific needs of VR. A specific case is link traversal that Kip mentioned. It would a bad experience if for each new visited domain we have to show a permissions prompt to the user. Natural body motion is the input mechanism in VR and constant permission prompts will feel like if each new website you visit requested access to your mouse and keyboard.
Attached image vr-example 1 (obsolete) — 
What do you think of this?
Flags: needinfo?(bbell)
Comment on attachment 8889680 [details]
vr-example 1

Thanks for taking this on!

This icon would be good for indicating that a tab is using your orientation and position data, but we might want to show an additional state when a tab is rendering to the WebVR headset.

If you search for "WebVR button", you'll see a consistent shape that content has adopted:

https://webvr.info/images/Google%20Cardboard.png

This icon has origins of representing Google Cardboard holders and has now become somewhat skeuomorphic.

This icon could be used for that second state perhaps, but I would love to see more ideas, especially if not so skeuomorphic.

TL;DR:

- First level of VR activity is tracking position in space.  Something indicating movement or orientation is good for this.
- Second level of VR activity is taking over the user's vision.  Something indicating glasses, goggles, eyes, or such perhaps?
(In reply to :kip (Kearwood Gilbert) from comment #10)
> > This pattern has been through UX research and will be easy for users to
> > understand, since it mirrors all our existing prompts. The decision the user
> > can make in these prompts is always local to the origin they're visiting.
> > Note that there's one clear confirm and one clear deny action, they are
> > visually distinct. This duality is the only thing that's supported by our
> > doorhangers right now (on purpose) and I would strongly recommend following
> > the pattern.
> > 
> > Also note that globally setting a permission for all origins is being
> > implemented in bug 1379560. So that won't be possible until the bug is
> > resolved.
> > 
> 
> Thanks for all the help getting this going!
> 
> The reason we wanted an "allow for all sites" is that users can follow links
> in VR from one site to another, and this may be across origins.  The
> challenge is that with the headset on, the user won 't see the doorhanger
> prompt.

That's an interesting point. It certainly sounds annoying to get prompted about this every time you switch sites. On the other hand I feel like making it easy to turn off the prompts forever defeats the protection we're trying to give. As I mentioned it's also a bit inconsistent, but we should primarily worry about the best outcome for your use case.

> I propose that we continue with the pattern found best by UX research (Allow
> / Don't Allow / Remember), but then make the same options available from
> within the headset itself.

Do you feel like it's crucial to warn the user when switching origins inside VR mode? Couldn't the platform code automatically grant the site a session permission for VR access if it was accessed in VR mode (or just not request a permission when already in VR mode, for that matter)? Is that technically viable?

> We are just starting to scope the work needed to display such choices in the
> headset.  Perhaps we could integrate it with the doorhanger UI universally
> so that other prompts can be responded without taking the headset off as
> well.
> 
> I'll file a separate bug that references this one to keep track of this work.

It's certainly a good idea to have a bug for permission prompts inside VR mode, since the site could try to get access to other things e.g. geolocation.
> - First level of VR activity is tracking position in space.  Something indicating movement or orientation is good for this.
> - Second level of VR activity is taking over the user's vision.  Something indicating glasses, goggles, eyes, or such perhaps?

What Kip said, I think however this icon is likely going to represent asking for both of these activities combined. So perhaps goggles and the roation?

However I can see we might also want these two icons to be separated sometimes too.
Flags: needinfo?(bbell)
Hey I just attached a patch for the C++ side of things also.

Do you have any advice on how to make the promise resolve before showing the prompt if the user won't get a response?

Any ideas on what the return of the promise should be if the user cancels?

Any other initial review comments would be great too.

Thanks
Flags: needinfo?(kgilbert)
Flags: needinfo?(jhofmann)
(In reply to Jonathan Kingston [:jkt] from comment #19)
> Hey I just attached a patch for the C++ side of things also.
> 
> Do you have any advice on how to make the promise resolve before showing the
> prompt if the user won't get a response?
> 
> Any ideas on what the return of the promise should be if the user cancels?
> 
> Any other initial review comments would be great too.
> 
> Thanks

You should avoid displaying the prompt until the callback "Navigator::NotifyVRDisplaysUpdated()" is hit.

In NotifyVRdisplaysUpdated(), you will see this if statement:

>  if (win->UpdateVRDisplays(vrDisplays)) {

After this line, in this branch, you should check if the number of items in vrDisplays is greater than 0 and only display the prompt if so.  If it is 0, there is no VR hardware and you should allow the remaining part of the branch to execute without a prompt:

>    for (auto p : mVRGetDisplaysPromises) {
>      p->MaybeResolve(vrDisplays);
>    }

If vrDisplays was non-zero and the user didnt' choose to save their preference, you should then show the prompt and exit this function rather than resolving the promises in mVRGetDisplaysPromises.

If the user cancels the prompt or chooses not to let the page access their VR hardware, you should resolve the promise with an empty list of displays, like this:

>  nsTArray<RefPtr<VRDisplay>> vrDisplays;
>  for (auto p : mVRGetDisplaysPromises) {
>    p->MaybeResolve(vrDisplays);
>  }

if the user accepts the prompt and chooses to let the page access their VR hardware, you should resolve the promises with the vrdisplays originally returned by win->UpdateaVRDisplays, which you can simply call again.  I'd suggest adding a flag to Navigator::NotifyVRDisplaysUpdated() that can be used to bypass the permissions prompt so you can simply call it again with the flag set after the user accepts access to their VR hardware.

One more thing...

The second way content gets access to the VR hardware is though the VRDisplayActivate event, which will occur during vr-site to vr-site link traversal.  This will only occur if the user has already accepted the permission prompt to enter VR for the first time; however, it's possible for the user to follow links across origins.

May I suggest that we do not block the cross-origin link traversal until we can either have an "allow for all origins" option in the prompt or have the UI available to accept the link to a new origin within the VR headset?

Finally...

We should have a preference to disable the permission prompts and have them automatically accepted.  This can be disabled by default.  This would be used by our automated mochitests, reftests, and emunittests that need to run unattended.  This may also solve issues for users in unusual circumstances such as kiosks, demo booths, and VR arcades that don't provide physical access to the keyboard, mouse, or monitor.

I hope this helps!  Thanks again for tackling this one.  I'll be starting on in-headset prompts and UI within the FF57-FF58 timeline.

- Kip
Flags: needinfo?(kgilbert)
(In reply to :kip (Kearwood Gilbert) from comment #20)
> The second way content gets access to the VR hardware is though the
> VRDisplayActivate event, which will occur during vr-site to vr-site link
> traversal.  This will only occur if the user has already accepted the
> permission prompt to enter VR for the first time; however, it's possible for
> the user to follow links across origins.
> 
> May I suggest that we do not block the cross-origin link traversal until we
> can either have an "allow for all origins" option in the prompt or have the
> UI available to accept the link to a new origin within the VR headset?

Again, are you sure we want to even show a cross-origin permission request if we have the technical means to ensure that the user is already in VR mode? :)

> Finally...
> 
> We should have a preference to disable the permission prompts and have them
> automatically accepted.  This can be disabled by default.  This would be
> used by our automated mochitests, reftests, and emunittests that need to run
> unattended.  This may also solve issues for users in unusual circumstances
> such as kiosks, demo booths, and VR arcades that don't provide physical
> access to the keyboard, mouse, or monitor.
> 

As I mentioned, if you can afford to wait on bug 1379560 it will provide you with a permissions.webvr.default pref that will enable you to set a global default. I hope to find the time to finish it soon. Otherwise you can of course implement your own pref.
Flags: needinfo?(jhofmann)
Comment on attachment 8889433 [details]
Bug 1381628 - WIP patch for web vr permission prompts.

The frontend parts look good to me. I don't see anything I'd point out in review off-hand, but I didn't spend a lot of time on it and didn't try it locally.

You should probably split this off into at least two commits as some point.
Attachment #8889433 - Flags: feedback+
(In reply to :kip (Kearwood Gilbert) from comment #0)
> Unfortunately, this information can also be utilized by sites for
> fingerprinting.
> 
> [...]
> 
> This prompt should only be displayed in the event that the promise would
> have been successful, to avoid annoying users that do not have any VR
> hardware.

If we resolve the promise right away then the site learns that the user has no VR hardware (or has permanently blocked the site), and by contrast can therefore fingerprint VR-having folks even if they decline the prompt just because it will resolve so much slower.

We should resolve a negative response through a timer with a random time that's in the range of usual user reaction times (total uneducated guess: would 1-5 seconds be about right?).
Interesting, we aren't doing that elsewhere are we? Perhaps we should file a follow up to do that for this and all the others that we fail early for based on lack of the hardware to resolve.
Flags: needinfo?(dveditz)
Attached image webvr-16.svg — 
How's this icon?
Attachment #8889680 - Attachment is obsolete: true
Flags: needinfo?(dveditz)
Flags: needinfo?(bbell)
Severity: normal → enhancement
status-firefox57: --- → affected
Priority: -- → P2
Just as a quick update here, there isn't a plan to make this into 57 as we need more discussions with the VR team regarding making this more usable.

Some initial thoughts:
- Make page transitions easier for developers
- Look into further what the long term plan for cross origin permission prompts
- Decide on how we will show permissions within VR (or if we need that at all etc)
Whiteboard: [fingerprinting]
(In reply to Daniel Veditz [:dveditz] from comment #23)
> (In reply to :kip (Kearwood Gilbert) from comment #0)
> > Unfortunately, this information can also be utilized by sites for
> > fingerprinting.
> > 
> > [...]
> > 
> > This prompt should only be displayed in the event that the promise would
> > have been successful, to avoid annoying users that do not have any VR
> > hardware.
> 
> If we resolve the promise right away then the site learns that the user has
> no VR hardware (or has permanently blocked the site), and by contrast can
> therefore fingerprint VR-having folks even if they decline the prompt just
> because it will resolve so much slower.
> 
> We should resolve a negative response through a timer with a random time
> that's in the range of usual user reaction times (total uneducated guess:
> would 1-5 seconds be about right?).

Couldn't this be detected by prompting multiple times and analyzing the responses? I assume you'd have to do it in unique iframes because otherwise the 'Decline' would be automatic (I believe we don't prompt again after the user declines no matter how many time the page asks.)

I'm not sure there's a better option though.
(In reply to Tom Ritter [:tjr] from comment #27)
> (In reply to Daniel Veditz [:dveditz] from comment #23)
> > (In reply to :kip (Kearwood Gilbert) from comment #0)
> > > Unfortunately, this information can also be utilized by sites for
> > > fingerprinting.
> > > 
> > > [...]
> > > 
> > > This prompt should only be displayed in the event that the promise would
> > > have been successful, to avoid annoying users that do not have any VR
> > > hardware.
> > 
> > If we resolve the promise right away then the site learns that the user has
> > no VR hardware (or has permanently blocked the site), and by contrast can
> > therefore fingerprint VR-having folks even if they decline the prompt just
> > because it will resolve so much slower.
> > 
> > We should resolve a negative response through a timer with a random time
> > that's in the range of usual user reaction times (total uneducated guess:
> > would 1-5 seconds be about right?).
> 
> Couldn't this be detected by prompting multiple times and analyzing the
> responses? I assume you'd have to do it in unique iframes because otherwise
> the 'Decline' would be automatic (I believe we don't prompt again after the
> user declines no matter how many time the page asks.)

You can't even do it in unique iframes, the temporary block after a user denied affects the entire tab. So if I'm not mistaken there shouldn't be a programmatic way to differentiate between

"The user manually denied the first prompt and now we're getting random time values"

and

"The first prompt was denied automatically with a random time value and now we're getting random time values"
(In reply to Johann Hofmann [:johannh] from comment #28)
> (In reply to Tom Ritter [:tjr] from comment #27)
> > (In reply to Daniel Veditz [:dveditz] from comment #23)
> > > (In reply to :kip (Kearwood Gilbert) from comment #0)
> > > > Unfortunately, this information can also be utilized by sites for
> > > > fingerprinting.
> > > > 
> > > > [...]
> > > > 
> > > > This prompt should only be displayed in the event that the promise would
> > > > have been successful, to avoid annoying users that do not have any VR
> > > > hardware.
> > > 
> > > If we resolve the promise right away then the site learns that the user has
> > > no VR hardware (or has permanently blocked the site), and by contrast can
> > > therefore fingerprint VR-having folks even if they decline the prompt just
> > > because it will resolve so much slower.
> > > 
> > > We should resolve a negative response through a timer with a random time
> > > that's in the range of usual user reaction times (total uneducated guess:
> > > would 1-5 seconds be about right?).
> > 
> > Couldn't this be detected by prompting multiple times and analyzing the
> > responses? I assume you'd have to do it in unique iframes because otherwise
> > the 'Decline' would be automatic (I believe we don't prompt again after the
> > user declines no matter how many time the page asks.)
> 
> You can't even do it in unique iframes, the temporary block after a user
> denied affects the entire tab. So if I'm not mistaken there shouldn't be a
> programmatic way to differentiate between
> 
> "The user manually denied the first prompt and now we're getting random time
> values"
> 
> and
> 
> "The first prompt was denied automatically with a random time value and now
> we're getting random time values"

I would be concerned about having arbitrary delays added to resolving promises, as this would cause a perceived performance issue on startup with sites that implement "responsive" VR support.  "responsive" support in this case refers to sites that can support navigating content using either mouse+keyboard+monitor or a VR headset.  Currently, 90% of VR content on the web is in this category.

IMHO, I would be more concerned about revealing the specific set of VR hardware users have and giving them a choice to share potentially tracking-sensitive information from the VR hardware system.  It may be very difficult to allow sites to be "responsive" if we can't reveal immediately to sites that there is "VR hardware" or "no VR hardware".

In the case of mobile phones, do we take any action to prevent sites from knowing if you are on a phone vs a desktop computer?  I would expect that media queries that select appropriate mobile layouts to be much more uniquely identifying than "VR hardware" vs "no VR hardware".
Just to be clear, fingerprinting via permission prompts is not a problem exclusive to WebVR and we shouldn't block work on this.

kip, responsive mode doesn't sound particularly responsive to me in any case when the user first has to answer a permission prompt for the website to access that information. I agree that without extensive fingerprinting protection, the fact that the user has VR hardware available should be exposed without permission.

I think both measures (fingerprinting protection for permission prompts and not exposing VR hardware information) should be reserved for privacy.resistFingerprinting.
> the fact that the user has VR hardware available should be exposed without permission

I personally think we should limit this to a boolean however this isn't really in scope of this bug.

I expect privacy.resistFingerprinting should just auto deny in all cases.

> fingerprinting via permission prompts is not a problem exclusive to WebVR and we shouldn't block work on this.

We were blocking on the risk of ruining VR experiences, I think we should push to unblock for the time being until the follow up security improvements that we are working through have been completed.

:kip, is there any objections to putting this permission prompt in until we have the improved in headset model? Cross origin linking is super low at the moment and perhaps we could provide a "demo mode" pref for developers.
Flags: needinfo?(kgilbert)
In general: If a feature is behind a permission prompt, our policy for privacy.resistFingerprinting (p.rP) is to show the permission prompt - not disable the feature. In the future we intend to extend permissions prompts to explicitly state the risk of fingerprinting (when p.RP is turned on.)

Having a little bit of trouble following from Comment #29. I'm not sure my thoughts weigh anything here, but I don't think details of VR hardware or sensor data should be exposed without a permission prompt. If you decided a boolean 'yes/no the user has VR hardware' was exposed without a permission prompt I'd think that was not ideal, but could understand the tradeoff.

When p.rP is on, we would want to normalize the boolean about whether the user has VR hardware. But instead of lying and always saying false, it would be awesome if the boolean yes/no query was exposed via a promise API. It could resolve immediately when p.rP was off, but when p.rP was on we could throw a permission prompt. That pattern allows really great futureproofing for us. (Our Canvas permission prompt would be made *much* more friendly if the API call it blocked was a promise-based API, but it is not, so we have some ugly implementation details that lead to bad experience.)

As far as the 'random delay resolving promises to avoid revealing if the user permanently-declined' feature - I agree that is entirely separate from this. I'd suggest that get moved into a separate bug (please tag it with [fingerprinting] if so!)
> If you decided a boolean 'yes/no the user has VR hardware' was exposed without a permission prompt I'd think that was not ideal, but could understand the tradeoff.

Last time I checked the current plan is still to implement getVRDisplays with a promise that can be rejected and delayed as long as the user likes. The current info revealed by this is more than a boolean in data too. My understanding version 2 of the spec might have an ability to query for a device however this also will be behind a promise too[1]. I think Edge is choosing to place their permission prompt in a different place and let websites fingerprint however I suggested that we aim for the highest privacy and block on querying even.

I think what :kip might actually be talking about in Comment #29 refers to a "high performance mode"[1] Feature Policy where the web page serves a header claiming to need high perf and also VR support. This is to prevent the browser from slowing down the site in future for perf reasons and also to allow link traversal cross origin.

Cross origin link traversal however as I mentioned in Comment #31, is in standards and UX flux right now so I think we should ignore this and readdress the issue when we have it. It might be that we have a different implementation in the two traversal scenarios:
- 2D browser -> headset
- headset -> headset

I also suspect that Tor browser wouldn't implement cross link traversal in the same manner so won't be an issue (we should discuss this at some point though).

> As far as the 'random delay resolving promises to avoid revealing if the user permanently-declined' feature - I agree that is entirely separate from this. I'd suggest that get moved into a separate bug (please tag it with [fingerprinting] if so!)

Agreed is there an issue for this? I don't plan on implementing the reject here.

[1] https://github.com/w3c/webvr/issues/184
[2] https://www.w3.org/2017/11/09-webvr-minutes.html#x04
(In reply to Jonathan Kingston [:jkt] from comment #33)
> > As far as the 'random delay resolving promises to avoid revealing if the user permanently-declined' feature - I agree that is entirely separate from this. I'd suggest that get moved into a separate bug (please tag it with [fingerprinting] if so!)
> 
> Agreed is there an issue for this? I don't plan on implementing the reject
> here.

I opened Bug 1420809
(In reply to Jonathan Kingston [:jkt] from comment #2)
> I think I know what to do based on Johann's feedback.
> 
> Would there be any interest in exposing this just to TLS connections? All
> new web APIs are usually exposed through Secure contexts and it would be a
> simple patch that we could likely uplift.

Indeed, this will be exposed to just TLS connnections.  This will be landing very shortly in Bug 1381645.
Flags: needinfo?(kgilbert)
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
Whiteboard: [fingerprinting][fp-triaged] → [fingerprinting]
No longer blocks: uplift_tor_fingerprinting
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]

This has been fixed. There is now UI in about:preferences#privacy to allow users to manage whitelists and blacklists of sites that have access to VR hardware.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: