Closed Bug 1591329 Opened 5 years ago Closed 4 years ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla79
Webcompat Priority ?
Tracking Status
firefox79 --- fixed

People

(Reporter: marcosc, Assigned: marcosc)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(1 file)

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

Component: DOM: Core & HTML → DOM: Device Interfaces
Priority: -- → P2
Blocks: 1640085
Assignee: nobody → mcaceres
Summary: [GamePad] Require secure context for gamepad state and events → [GamePad] Require secure context for getGamePads() and events
Summary: [GamePad] Require secure context for getGamePads() and events → [GamePad] Require secure context for getGamePads()

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.

Flags: needinfo?(kearwood)
Flags: needinfo?(dmu)

(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.

Flags: needinfo?(kearwood)

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

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

Flags: needinfo?(dmu)

(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 :-)

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.

(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.

Pushed by mcaceres@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e05d57804566 Require secure context for getGamePads() and events r=kip
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
Keywords: site-compat
Summary: [GamePad] Require secure context for getGamePads() → [GamePad] Require secure context for getGamePads() in Nightly

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

Keywords: dev-doc-needed

(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.

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?

(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.

(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).

(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/

(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."

(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.

(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.

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.

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

Webcompat Priority: --- → ?

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.

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.

See Also: → 1704005

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

See Also: → 1870037
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: