Require secure context for gamepad state and events

[nondebug]

Closes #113

The following tasks have been completed:

• Modified Web platform tests - will be updated automatically after merge.

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=215020)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko

---

Preview | Diff

[marcoscaceres]

Checked the cross references locally also... they are all good 👍

[marcoscaceres]

Shifted order of things... let me know what you think!

[marcoscaceres]

Gecko tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1591329

[marcoscaceres]

About the "secure context" not being linked on TR, filed a bug:
w3c/webappsec-secure-contexts#68

[marcoscaceres]

Quick updated: landed the console message + returning the empty array + one fire events in secure context in Firefox Nightly. I still need to do the events, but they were breaking a bunch of WebXR things in Gecko, so will need to come back to those.

[beidson]

Adding the logging in WebKit here:
https://bugs.webkit.org/show_bug.cgi?id=214995

Restricting to SecureContext here:
https://bugs.webkit.org/show_bug.cgi?id=215020

[andrewfstratton]

Please can you still allow API to work for local development (and learning)?!

[marcoscaceres]

Hi @andrewfstratton. In most (all?) browsers, localhost is considered a secure context for development purposes:

https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts#when_is_a_context_considered_secure

[Miniontoby]

[moved to the original issue]

[BlobTheKat]

What is the rationale behind this decision?

[marcoscaceres]

Tracking scripts poking at gamepads, plus also preventing random third-parties / proxies injecting scripts over HTTP that try to poke/read at gamepads.

[Miniontoby]

Personally it would be nice if the whole localnet could be whitelisted for these secure context limitations, so not only localhost.

With localnet I mean your intranet, like every device connected to your router. Like every 192.168.***.*** ip or *.fritz.box or whatever local dns domain you have.

Since within localnet you cannot have ssl certs that are trusted. And not everyone can trust self signed certs, like at my home, meaning that they will never be able to play using gamepads on locally made web games.

And yes, I know this might not be the best place to ask this, but because right now it is for me mostly about the gamepads, I just asked it here, but it would be nice if every feature would be possible within localnet (e.g. GPS, Camera, Microphone)

[zhangyx1998]

This will make things MUCH HARDER for local network application development.

In my case, I want to serve a webpage from a robot which accepts gamepad controls. The point is everyone in the local network should be able to connect to the robot from their own device with zero configuration (i.e. self-signed certs are not feasible). Forcing secure context will destroy these kind of applications.

Instead of forcing a secure context, can the engine just go ahead and prompt for user permission?

[BlobTheKat]

Instead of forcing a secure context, can the engine just go ahead and prompt for user permission?

I disagree, requiring user permission is a nuisance to the user.

What would make more sense is a general interface for receiving controller input that doesn't expose device-specific details (similar to how keyboard input is exposed exclusively through KeyboardEvents)

If this is implemented, individual controller/gamepad details could still be accessible behind a permission, similar to getScreenDetails()

This seems like the most consistent and privacy-preserving approach, not sure how the rationale behind this PR came to be.

[zhangyx1998]

Thank you @BlobTheKat for replying. I've opened an issue and adopted your opinions.

Please feel free to correct me if I did not understand you correctly.

[frank26080115]

I am running a webserver from a ESP8266, under the ExpressLRS project, so the MCU itself is incapable of encryption and I don't have ways of adding libraries to the project. I am trying to add gamepad functionality to ExpressLRS through it's Wi-Fi soft-AP web server that is delivering a HTML page with Javascript utilizing the gamepad API. It is my hope to use this as a platform to develop low cost remotely controlled educational toy robots.

I saw a console warning that lead me to this pull request. It said there are instructions to resolve the error here. How can I resolve it?

Thanks

[partyblob]

I am running a webserver from a ESP8266, under the ExpressLRS project, so the MCU itself is incapable of encryption and I don't have ways of adding libraries to the project. I am trying to add gamepad functionality to ExpressLRS through it's Wi-Fi soft-AP web server that is delivering a HTML page with Javascript utilizing the gamepad API. It is my hope to use this as a platform to develop low cost remotely controlled educational toy robots.

I saw a console warning that lead me to this pull request. It said there are instructions to resolve the error here. How can I resolve it?

Thanks

The decision has been reverted, the requirement has been dropped and the warning should go away in future versions of chrome (See #194 and #203)