1591329 - [GamePad] Require secure context for getGamePads() in Nightly

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, enhancement, P2)

Description

[Marcos Caceres [:marcosc]]

GamePad event interfaces should only be exposed in secure contexts. Further, in insecure contexts, .getGamepads() should return an empty array.

Comment 1

[Marcos Caceres [:marcosc]]

Attachment: Require secure context for getGamePads() and events

Comment 2

[Marcos Caceres [:marcosc]]

Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d6aacc76a640209da380a0117e136cee3b7a5605

Comment 3

[Marcos Caceres [:marcosc]]

Kip, Daosheng, I'd like for us to move all the gamepad related IDL to secure context. However, there is a bunch of stuff in WebXR that might be affected, so want to make sure we are coordinated so to prevent breakage.

My plan would be to start showing a developer warning that we are moving the Gamepad API to secure context. In Firefox 80, remove the warning and make getGamepads() return an empty array if it's not in a secure context.

Would either of you be willing to review the attached patch? Also, once I add [SecureContext] to the GamepadEvent's IDL, WebXR interfaces /classes that inherit from it will need to be updated. I could use some help with that, as I don't know what all the dependencies are.

Comment 4

[:kip (Kearwood Gilbert)]

(In reply to Marcos Caceres [:marcosc] from comment #3)

Kip, Daosheng, I'd like for us to move all the gamepad related IDL to secure context. However, there is a bunch of stuff in WebXR that might be affected, so want to make sure we are coordinated so to prevent breakage.

My plan would be to start showing a developer warning that we are moving the Gamepad API to secure context. In Firefox 80, remove the warning and make getGamepads() return an empty array if it's not in a secure context.

Would either of you be willing to review the attached patch? Also, once I add [SecureContext] to the GamepadEvent's IDL, WebXR interfaces /classes that inherit from it will need to be updated. I could use some help with that, as I don't know what all the dependencies are.

Luckily, both WebVR and WebXR also have the [SecureContext] added to their IDL.

IIUC, this should not affect any WebVR or WebXR sites.

Comment 5

[:kip (Kearwood Gilbert)]

The WebXR spec requires the [SecureContext].
WebVR does not require [SecureContext] at the spec level, but we apply it anyways for additional protection.

Comment 6

[Daosheng Mu[:daoshengmu]]

The only concern is WebVR is not forced to require [SecureContext]. If we could make WebVR to be [SecureContext] either. There is no problem.

Comment 7

[:kip (Kearwood Gilbert)]

(In reply to Daosheng Mu[:daoshengmu] from comment #6)

The only concern is WebVR is not forced to require [SecureContext]. If we could make WebVR to be [SecureContext] either. There is no problem.

Recently, WebVR has also been forced to require [SecureContext] also :-)

Comment 8

[:kip (Kearwood Gilbert)]

I have filed an issue on the WebVR spec to require [SecureContext] but it is seeing little activity due to Chromium pulling the source code out in favor of only supporting WebXR.

Perhaps this could affect the Oculus browser, which IIRC is still supporting both WebVR and WebXR. All Gecko-based implementations require [SecureContext] for both WebVR and WebXR.

Comment 9

[Marcos Caceres [:marcosc]]

(In reply to :kip (Kearwood Gilbert) from comment #8)

I have filed an issue on the WebVR spec to require [SecureContext] but it is seeing little activity due to Chromium pulling the source code out in favor of only supporting WebXR.

Do we also plan to drop WebVR?

Perhaps this could affect the Oculus browser, which IIRC is still supporting both WebVR and WebXR. All Gecko-based implementations require [SecureContext] for both WebVR and WebXR.

Ok cool. As long as we already require SecureContext, then this should be fine.

I'm drafting a blog post explaining what our plans are which I'm hoping we can publish on Mozilla Hacks... If WebXR relies a bit on getGamepads(), it might good for us to mention that WebXR won't be affected (given it's already secure context + requires feature policy). I'll send you both a link to the doc.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e05d57804566
Require secure context for getGamePads() and events r=kip

Comment 11

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/e05d57804566

Comment 12

[Kohei Yoshino]

WebVR already requires secure context since Firefox 73. (Bug 1381645, compatibility note)

Comment 13

[Marcos Caceres [:marcosc]]

(In reply to Kohei Yoshino [:kohei] from comment #12)

WebVR already requires secure context since Firefox 73. (Bug 1381645, compatibility note)

ok, awesome to see. The one small thing that we need to update if the various GamePad Events, which are still exposed in insecure context (and on which some WebXR events also extend)... they are not very usable on their own from user-land code, obviously. But to match the Gamepad spec, we should also add SecureContext to them.

Comment 14

[Fabio Alessandrelli]

Any reason for this change? I saw the blog post, I see the issue, but I can't see the reason behind it.
Is the plan to disable JavaScript completely in non-secure context?

Comment 15

[Marcos Caceres [:marcosc]]

(In reply to Fabio Alessandrelli from comment #14)

Any reason for this change? I saw the blog post, I see the issue, but I can't see the reason behind it.

We'd like to motivate more sites to move to HTTPS. This is part of that strategy.

Is the plan to disable JavaScript completely in non-secure context?

No. Absolutely not. But for things that require user permission (what we generally refer to as "powerful features"), we'd like to expose those only in secure contexts.

Comment 16

[Fabio Alessandrelli]

(In reply to Marcos Caceres [:marcosc] from comment #15)

We'd like to motivate more sites to move to HTTPS. This is part of that strategy.

Oh, so this is not about an intrinsic security/privacy issue in the Gamepad API, it's just a way to force HTTPS down the user's throat, even on local networks (localhost is considered secure, local network is not for obvious reasons).

Comment 17

[Marcos Caceres [:marcosc]]

(In reply to Fabio Alessandrelli from comment #16)

(In reply to Marcos Caceres [:marcosc] from comment #15)

We'd like to motivate more sites to move to HTTPS. This is part of that strategy.

Oh, so this is not about an intrinsic security/privacy issue in the Gamepad API, it's just a way to force HTTPS down the user's throat, even on local networks (localhost is considered secure, local network is not for obvious reasons).

No. And I'd ask you to address members of the community with civility and remind you of our code of conduct (be respectful, in particular):
https://www.mozilla.org/en-US/about/governance/policies/participation/

Comment 18

[Fabio Alessandrelli]

(In reply to Marcos Caceres [:marcosc] from comment #17)

And I'd ask you to address members of the community with civility and remind you of our code of conduct (be respectful, in particular):

I'm deeply sorry you felt I was being disrespectful of you. It wasn't my intention, but I can see now how it might have looked that way, so please accept my apology.

My harsh criticism was against a decision that seem to have been taken behind closed doors, with no real discussion on the merits of it (only the implementation details) and without any real benefit for the end user.

No.

I'm not sure what "no" means here.
Does it mean "No, there was no intrinsic security/privacy issue"
Or "No, there were intrinsic security/privacy issue, we are not trying to force users to use HTTPS even on local networks, even when there's no need."

Comment 19

[Marcos Caceres [:marcosc]]

(In reply to Fabio Alessandrelli from comment #18)

(In reply to Marcos Caceres [:marcosc] from comment #17)

And I'd ask you to address members of the community with civility and remind you of our code of conduct (be respectful, in particular):

I'm deeply sorry you felt I was being disrespectful of you. It wasn't my intention, but I can see now how it might have looked that way, so please accept my apology.

Apology accepted. Thank you.

My harsh criticism was against a decision that seem to have been taken behind closed doors, with no real discussion on the merits of it (only the implementation details) and without any real benefit for the end user.

No.

I'm not sure what "no" means here.
Does it mean "No, there was no intrinsic security/privacy issue"
Or "No, there were intrinsic security/privacy issue, we are not trying to force users to use HTTPS even on local networks, even when there's no need."

We found an unusually large number of websites were poking at the Gamepad API in third-party contexts (i.e., not directly from gaming websites), which is a strong indicator that tracking scripts are trying to exploit the API. In order to prevent that, moving the API to secure context and adding permissions policy was a prudent solution (in addition to the mitigation we already have in place of only returning a gamepad object when the user interacts with the gamepad).

Hopefully that helps explain a bit more the rationale for making this change. I am sympathetic that moving to HTTPS can be a burden - I've had to migrate my own blog, and yes it was painful... but it's becoming increasingly less painful and cheap(er) to make that migration, and it helps secure the web at large - something we at Mozilla strongly believe is a good thing.

Comment 20

[Fabio Alessandrelli]

(In reply to Marcos Caceres [:marcosc] from comment #19)

We found an unusually large number of websites were poking at the Gamepad API in third-party contexts (i.e., not directly from gaming websites), which is a strong indicator that tracking scripts are trying to exploit the API. In order to prevent that, moving the API to secure context and adding permissions policy was a prudent solution (in addition to the mitigation we already have in place of only returning a gamepad object when the user interacts with the gamepad).

Hopefully that helps explain a bit more the rationale for making this change. I am sympathetic that moving to HTTPS can be a burden - I've had to migrate my own blog, and yes it was painful... but it's becoming increasingly less painful and cheap(er) to make that migration, and it helps secure the web at large - something we at Mozilla strongly believe is a good thing.

Thank you for your explanation.
This makes sense, and is in line with what I initially thought. i.e. that the number and names of connected gamepads could be used as entropy to track users.
I'm not sure how much of an impact this change will have, since in my experience most tracking scripts come from secure contexts nowadays, but if your analytics data suggest that it will mitigate the issue, I trust you, and that's good news.
Thanks again for the explanation.

Comment 21

[WGH]

Requiring explicit permission makes perfect sense. but I personally still don't understand the merits of restricting to HTTPS only. On the other hand, I can immediately think of a negative example: It'll hinder rich intranet applications a lot. Think of non-cloud IoT, which doesn't have a proper hostname and a way obtain a certificate.

Comment 22

[Karl Dubost💡 :karlcow]

Apart of the user agent sniffing, the site in this webcompat issue is working in release and not in nightly because of the secure context restriction, so that could be a warning on the future webcompat issues.
https://github.com/webcompat/web-bugs/issues/76944#issuecomment-864814075

Comment 23

[Matt T]

I'm developing a game locally and was testing it across my local network (ie. accessing an IP) and now see I can't do that in Firefox. I kind of expected that at least I could disable this feature via a flag, but it seems that's not possible? I'm not sure how to secure a local network.

Comment 24

[Damian Yerrick]

Use https://github.com/FiloSottile/mkcert to make a self-signed certificate for your internal IP address. Then add it to the list of trusted root certificates in Firefox installations on devices on your local network.

Comment 25

[Kestrel]

The secure requirement has been removed for webcompat reasons by Bug 1870037.