Please don't restrict to a secure context

[cbmpvr]

Hi there, we've recently seen reports, by way of various browser consoles, that the Gamepad API will soon require a secure context. It wasn't exactly clear on how to provide feedback on this change, although the Gamepad W3C spec mentions that GitHub issues are the preferred avenue for discussion.

We understand that the reasoning for this change is to limit browser fingerprinting, and the general push/trend towards keeping things more secure/following best practices. Which we completely understand and agree with. However, there are applications where a secure context is not always possible. At least not without compromising security in some other way.

Our products are network appliances which have a web management interface. Specifically one of these products is responsible for processing and managing extremely large LED displays (like you see in stadiums, rock concerts, side of buildings, etc). Our application leverages the awesome Gamepad API to allow our technicians to quickly navigate and adjust display uniformity via a gamepad controller. This works amazingly well. So thank you for your work on getting this standardized!

Problem is that these devices live on temporary private networks with statically assigned IP addresses. Many of which have no internet connectivity at all. To further complicate things, all of the devices connected to these processors are either personally owned, provided by third party contractors, or rented from a general equipment warehouse. Meaning that not only do we lack access to the general internet certificate infrastructure, we're also not even able to deploy our own root certificates. Leaving us with the only option of using self signed certificates, and eventually teaching our industry to ignore certificate errors altogether.

Which then means that the requirement to use a secure context actually lessened general security as we teach users to just ignore the scary certificate errors. I for one would like to avoid living in that world, so humbly request for a reconsideration of the requirement for the Gamepad API to only be accessible via a secure context.

If the main concern is purely fingerprinting. It seems like the current requirement of having the user interact with the gamepad first before it is accessible via the page already largely helps prevents general catch-all/flyby fingerprinting? but we understand that's likely many other factors at play here.

As an aside; there seem to be many other users adversely affected by this change (some noted as mentions in #120). Although curiously we did not see an issue already logged for this? So here we are.

Thanks, Chris Byrne

Software Engineer Megapixel VR https://megapixelvr.com/

[marcoscaceres]

Thanks @cbmpvr for the feedback and detailing your use case and issue that arises with this change. Let's see if we can come of with something that can help...

[reillyeon]

I would be happy to see better solutions for deploying HTTPS on private networks.

[marcoscaceres]

Hmmm... so maybe this is wider discussion we need to have with the WebAppSec WG?

[reillyeon]

I know that solving that general problem is something that has been discussed and while many solutions have been presented none have made much progress. I would love to see it solved but I'm not sure a solution is forthcoming. What we should decide here is whether this should block the adoption of [SecureContext] for this API. From our experience with adding this restriction to other APIs, such as getUserMedia() I have a feeling that the answer will be "no" and we accept the consequences such as broader deployment of self-signed certificates.

That said, I think we should bring this up to the WebAppsSec WG to reiterate that this is a problem in need of a solution.

[cbmpvr]

Making a note here that this secure context requirement is now active in the latest release of Firefox 91

navigator.getGamepads()
Uncaught TypeError: navigator.getGamepads is not a function

(Error message included for search-ability)

It's not entirely clear on the release schedule for Chromium or WebKit

---

Was there any follow up discussion/decision on this (secure context on private local networks)? or should I reach out to the WebAppsSec WG mailing list for their thoughts?

[SaschaIoT]

Maybe it's a solution to ask for Gamepad API permission in case of insecure context? (like Notifications API)

[marcoscaceres]

No, unfortunately. We are trying to reduce the number of user facing permissions in the platform. As a whole, we are also trying to move the entire platform to secure contexts.

[Brikwerk]

Apologies if I'm poking a stale issue here, however, I wanted to add my 2 cents to this discussion.

I maintain a piece of controller emulation software that allows users to send webpage-based gamepad input to a Nintendo Switch. Users mainly host this webpage locally and connect to it on the same network. The recent move to restrict gamepad use to a secure context has left me in a bit of a bind. I'm being forced to consider two options with this change: 1) Coaching users through accepting a self-signed certificate or 2) Dropping gamepad input from the project altogether. Both options further complicate use of the software for users.

I realize that I'm a bit too late to affect any real change on this topic, however, I would at least like to state, for the record, that this move is negatively affecting the project that I maintain.

Additionally, if the overall goal for the future is to move the entire platform to a secure context, where does this leave small/casual projects on local networks? Is the recommended path going to be coaching users through self-signed certificate warnings?

[marcoscaceres]

Additionally, if the overall goal for the future is to move the entire platform to a secure context, where does this leave small/casual projects on local networks?

The Web App Sec working group need to figure this out, to be honest... particularly as part of: https://github.com/w3c/webappsec-secure-contexts

It's obviously a really hard problem, because obviously no one wants stuff on the internet poking around local networks.

Is the recommended path going to be coaching users through self-signed certificate warnings?

No. That would be really bad. Definitely we don't want to train users to navigate around those warnings.

[Brikwerk]

Thanks for your prompt reply, Marcos.

The Web App Sec working group need to figure this out, to be honest... particularly as part of: https://github.com/w3c/webappsec-secure-contexts

Great to see that there's a working specification for these types of issues. Thanks for linking this.

No. That would be really bad. Definitely we don't want to train users to navigate around those warnings.

Sorry, I might have jumped the gun a bit here. My aim was more to ask what the recourse is for local projects wanting to use secure context APIs. The only real path forward I’m seeing is passing certificate management onto the user for local situations? If so, this will be a challenging task for a some people. I realize, though, that use-cases like the project I maintain and the original thread starter are likely in the minority for how the Gampad API gets used, on average. Still, this move is a bit disappointing to see, from my perspective.

No matter, I’ll look forward to development in the specification you linked, going forward.

[reillyeon]

Just yesterday a company called Tailscale announced support for provisioning TLS certificates for services on their VPN product. The same approach they are taking could also be used to support creating certificates for devices on local networks. It seems like the ecosystem is moving in a direction which makes TLS accessible and reduces the impact of changes like this.

[jharris1993]

I realize that I am both late to the party and that my comments have virtually zero chance of having any effect since the current trend is to lock down everything so tightly that nobody can use it. (/rant)

My two cents:

First: I think there is a larger issue here.

I believe that the larger issue is that the people who write the spec's and such are thinking "GAME-pad" not "User Input Device"

And, since it's "just for (silly) games", it's not that big a deal if we lock it down because the people that create the games have deep pockets and can do whatever they want.

I disagree.  What if mice or keyboards were limited to secure contexts?

The first and most important thing is to break away from the idea that the device is a GAME device.  Mice, keyboards, touch-pads, and joystick controllers are all user input devices and instead of limiting their use we should do what we can to make them easier to use.

If I had my way, I'd change the name of the interface from "gamepad" to "joystick" or something less "game-ish" and to encourage people to "think outside the box" to find better ways to use these devices.

===================

W3C, and the various browser companies have done much to make joystick-type devices more accessible for programmers to use as generic input devices, and this is good.

This opens entire vistas of opportunity.  We can now use joystick type devices as accessibility aids, alternate controller options, for robotics, the list goes on.

The example given by the person who helps develop software for "Jumbotron" type displays is telling.  W3C has made a very useful advance and has enabled joystick type controllers to be used in ways they could never be used before, absent horrifically complex programming.

In my case I am working on a project to use a joystick as a robotic device controller.

Perhaps someone else wants to use a joystick as an accessibility aid.

Requiring a secure context actually reduces the way joystick type devices can be used because it is simply not possible to demand that every use of a joystick type device be behind a certificate wall.

Re: Fingerprinting. I agree that the only technical solution to the existing requirement is a self-signed certificate.  However, as many others have mentioned, encouraging self-signed certificate use all willy-nilly by people who don't know what this means, or the relative dangers of accepting every certificate error that comes by, is a Bad Thing.  Requiring a secure context makes the problem worse and works to reduce the security consciousness of the every day user who might be using a joystick device within a browser's context.

Requiring a secure context does little if anything to reduce fingerprinting because the people who are the most interested in fingerprinting, have deep pockets and for them a certificate is the least of their worries.  Once you're on one of their sites - or a cross-site affiliate of theirs - they already have you.

If fingerprinting in specific, (and privacy in general), are concerns, then concentrate on ways to reduce or eliminate HTML5 and ETag cookie re-spawning, and similar technologies, (see the attached paper discussing this topic), instead of locking everything down behind a certificate-wall that ultimately won't solve the underlying problems. Flash Cookies and Privacy II - Now With HTML5 and ETAG Respawning.pdf

What say ye?

[jharris1993]

Greetings!

How to have your cake and eat it too with respect to gamepad security

As I, and others mentioned above have said, placing the gamepad behind what is essentially a security paywall, (real certificates are not inexpensive), will have two very bad effects:

1. It will, (in essence), eliminate any in-browser use of the gamepad that's not based on a full-up static server on a real domain.
   • (i.e. local devices such as the Jumbotron-type display controller noted above, robotics, accessibility aids, etc.)
     2. If a self-signed certificate is used, it will have the effect of reducing the security of the context by encouraging people to ignore certificate warnings.

Note:  There is nothing that prevents a secure site from using a gamepad as a fingerprinting device, so the mere presence of a secure site does NOT guarantee the gamepad won't be used for fingerprinting.

Conclusion 1:  Placing stuff behind a secure context is NOT always the answer Conclusion 2:  Placing stuff behind a secure context should NOT be the first-choice, knee-jerk reaction to a potential security/privacy issue. Conclusion 3:  The W3C group should exhaust all other possibilities before placing a feature - especially a hardware feature - behind a security paywall.

===============================

Suggestion on how to solve the problems noted above:

• Make it a browser selectable hardware permission on a per-site basis the same way other hardware, like the camera or microphone, are allowed permission on a site-by-site basis.

Viz.: Create a setting:  Allow gamepad [always | never | ask] which defaults to "ask"; placed with the other hardware permission settings within the browser's preferences.

This is how Chrome handles hardware permissions:

As a consequence of this setting the user can proactively either allow or disallow gamepad visibility to sites that wish to use it.

Viz.:

1. Site "x" is a hardware device using the gamepad, a robot, an accessibility aid, or something similar that needs the gamepad but cannot have a secure context.

   • Site "x" attempts to use the gamepad - initially the gamepad request is queued in the same manner any other hardware permission is queued.
   • User gets a pop-up asking for permission to use the gamepad.
   • User grants permission.
   • Gamepad is made available to the site with option to remember that choice.
   • Note that the "must interact with the gamepad rule remains in force.

2. Site "y" has a "drive-by fingerprinter" installed that looks for a gamepad.

   • Everything occurs as noted above, except the user does NOT grant permission.
   • Site is not granted access to the gamepad, and - in fact - has no idea that a gamepad may even exist.

3. Note that this does NOT depend on the security context as secure sites may be fingerprinters and insecure sites may not be.

Therefore I respectfully suggest that the requirement for a secure context for gamepads be abandoned and as a replacement, require affirmative user permission to use it on a site-by-site basis with the option of remembering the choice for that site.

What say ye?

[nondebug]

@jharris1993 @Brikwerk @cbmpvr

Device APIs like WebUSB, WebHID, Web Serial, and Web Bluetooth have three levels of permissions. There's a default guard permission that configures the default Ask/Allow/Block behavior, guard permissions that override the Ask/Allow/Block behavior for specific origins, and device permissions that grant permission for a specific origin to access a specific device. I think it would be nice if Gamepad API integrated with other device APIs to make it easier to access advanced functionality provided through those APIs.

The current device permissions model carves up permissions by API. In high-level APIs this has the intended result of separating device permissions by capability. In low-level APIs, users may be confusingly prompted multiple times for the same device with no clear connection to the capabilities that would be exposed by granting each permission. This can happen if the device is implemented as multiple low-level interfaces, each of which is tracked by a separate permission.

Carving out some capabilities is important. If a gamepad has audio or video capture capabilities then they should be locked behind the appropriate high-level permissions. However, other capabilities like advanced haptics, speakers, LEDs, touchpads, and motion inputs could be bundled with low-level device APIs as a broad "Allow $ORIGIN to take control of $DEVICE" permission that no longer is specific to an API or capability.

That's where I'd like Gamepad API permissions to end up. It gives us a way to solve the issue for gamepad API access from locally hosted services but it's a huge amount of overhead just for that and won't be ready any time soon. Instead, I'm proposing Chrome commits to supporting chrome://flags/#restrict-gamepad-access as a never-expire flag until this issue is resolved since a flag specific to Gamepad API is better than pushing users to install self-signed certificates. Users of applications like Megapixel VR would be able to disable the flag to restore access in non-secure contexts.

Note that the current behavior of chrome://flags/#restrict-gamepad-access in Chrome 100 is not what we want. In secure contexts, getGamepads() should return an empty list (not throw an exception) to avoid breakage in apps that don't expect it to throw and don't need the API. Also it enforces the wrong permissions policy default allowlist which is too restrictive.

I've put together my current plan for migrating Gamepad API to secure context and feature policy integration here: Securing Gamepad API in Chrome

Gamepad API has many surprising use cases and I feel that restricting it permanently is unnecessarily limiting. We should find ways to make it maximally useful while retaining as much user privacy as technically possible. If we add a permission I feel it should be primarily used for unlocking advanced features on the device and bypassing privacy protections, not providing basic access to gamepad button and axis inputs. There's no reason gamepad inputs can't be sanitized and exposed in a form similar to mouse and keyboard inputs.

[jespersmith]

I would like to add my 2 cents to this discussion. We use the gamepad API to control physical, hardware robots that are on a local network, without internet access. Possibly using a mobile device.

With the gamepad API to be https only forces us to create a cloud backend for the robot, which can be used to control the robot from anywhere in the world. This requires the robot to be on a network with internet access, etc. From a security standpoint, this is a step back for us, as well as from an availability and robustness standpoint.

Unfortunately, there is no good solution to provide certificates to devices on a local network that is easy for users and does not require us to install certificates on user devices.

[ImBoop]

Is it safe to say that this issue is going to be ignored? A ton of people (amongst other issues such as WebCrypto being HTTPS only) feel like it shouldn't be gated behind an arbitrary HTTPS requirement when browsers (such as Firefox) already implement privacy minded features. You're basically telling users that they should bypass certificate errors because developers who don't want to use a public cloud (e.g. for an internal or over LAN product) ultimately have to use a self signed certificate due to the very strange requirements imposed by standards committees who feel the need to circumvent the will of the many.

[dinther]

I hit on exactly this issue right now. My robot project hosts a webserver. It connects to the wifi network if it knows the credentials and otherwise starts an access point.

Users interact with the robot via a browser that is simply pointed to the name of the robot being the host name. The robot serves the application to the user browser and via websocket interaction takes place. My web socket server is written in C and doesn't suffer all the security limitations.

However, I want the use to be able to forgo the clumsy virtual joysticks on the touch screen and use a gamepad. This should be so simple and it is so benign and yet. NAH.

Ok, back to sleep evenone.

[aguegu]

@dinther , I am having the same scenario. Navigator.getGamepads() does not work for me. Because Navigator.getGamepads is not a function. But navigator.getGamepads() works, on both Firefox and Chromium. If no gamepads shown up, you could try again after pressing some button on the gamepad.

I have setup self assigned certs with mkcerts. But Navigator.getGamepads() failed too. So I figured maybe there was something wrong with the statement itself. navigator.getGamepads() works with or without SSL.

[marcoscaceres]

Fwiw, “Navigator.getGamepads()” (i.e. static function) is not a thing.

[jharris1993]

Is anything happening with this, or are all these alternate use-cases simply going to be ignored?

[fredrikryden]

@jharris1993 unfortunately it seems that way

[RiedleroD]

I was here

seriously though, I'd at least like to have a statement from the W3C as to why we're seemingly getting ignored

[reillyeon]

I'd at least like to have a statement from the W3C as to why we're seemingly getting ignored

Please note that the W3C as an organization rarely unilaterally decides to make changes to APIs. Ultimately it is implementations who make changes and the W3C provides a forum for coordinating their work. The W3C Technical Architecture Group provides design guidance for when a secure context is required but recognizes that there is disagreement on how broadly this should be applied.

At the moment it appears that only Firefox has shipped this change. Safari and Chrome have shipped warnings about the future deprecation. I can't speak for Safari but @nondebug's comment above shows how Chrome is thinking about reducing the impact of this change.

[RiedleroD]

oh, thanks for your reply, @reillyeon . I misunderstood what the W3C actually does, so this clears things up.

[jharris1993]

@reillyeon's comment:

Please note that the W3C as an organization rarely unilaterally decides to make changes to APIs. Ultimately it is implementations who make changes and the W3C provides a forum for coordinating their work. The W3C Technical Architecture Group provides design guidance for when a secure context is required but recognizes that there is disagreement on how broadly this should be applied.

At the moment it appears that only Firefox has shipped this change. Safari and Chrome have shipped warnings about the future deprecation. I can't speak for Safari but @nondebug's comment above shows how Chrome is thinking about reducing the impact of this change.

@nondebug's original comment:

That's where I'd like Gamepad API permissions to end up. [A browser flag] gives us a way to solve the issue for gamepad API access from locally hosted services [. . . and] I'm proposing Chrome commits to supporting chrome://flags/#restrict-gamepad-access as a never-expire flag until this issue is resolved since a flag specific to Gamepad API is better than pushing users to install self-signed certificates. Users of applications like Megapixel VR would be able to disable the flag to restore access in non-secure contexts.

Note that the current behavior of chrome://flags/#restrict-gamepad-access in Chrome 100 is not what we want. In secure contexts, getGamepads() should return an empty list (not throw an exception)

I entirely agree.

A settable flag would do much to mitigate this issue, as it allows the behavior to be modified as needed and, for the case of a robot with a custom O/S, it can be managed by the maintainer.

Any chance of getting Firefox on board with this?

[Lavadude82]

Moving the GamepadAPI to a secure context is the wrong move. This would make it difficult to test some websites like LAN-hosted websites on real devices. For example, accessing my website from my phone which allows me to use a computer as the display and my phone as a controller would be impossible. Unless I have a self-signed certificate or buy one from the big guys who can charge you a pretty penny for them, I am screwed. Making users accept a prompt to allow the website to use the GamepadAPI is the best option. While it may be a bit inconvenient for them, it does decrease the number of times people will have to use self-signed now non-validated certificates. It would only be once for a site and would make the most sense.

Might need to get a browser that allows all APIs on HTTP to test my applications.

[juj]

Web developers who are in charge of this move, could you update

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getGamepads and https://caniuse.com/gamepad

accordingly to document which browser versions this migration to requiring HTTPS starts from? This would be extremely helpful to technologies like Unity and Emscripten to help them coordinate the fixes.

[joezappie]

Ill also mention I use gamepad for robotics controller, like many in this thread. We often work with government agency's where our platform is NEVER allowed to access the real internet. We host our own internal LAN and everything is completely isolated.

Luckily, we use an electron app as our controller, which localhost is considered a secure context, but we have projects planned where we don't want a user installed app and instead them just go to a website.

Can install a fake SSL certificate using something like mkcert but then the user has to accept the self signed certificate and browsers love to tell the user they are doing something scary by not being on HTTPS. It's just an added complication for projects where this added security is pointless and leads to more things to go wrong from the users perspective.

I think the requirement for HTTPS is pushed solely by large corporations that have it all figured out, but it really fucks up the development process and the ability for small creators to make things. Not everything being created for the web is large scale web apps with hundreds of developers working on it.

[saschanaz]

We in Mozilla plan to lift this restriction for the sake of web compatibility. We figured that having this restriction does not fulfill the original intention of preventing fingerprinting, as basically everything in 2024 is in HTTPS (🎉).

@marcoscaceres and @nondebug, I see both WebKit and Blink still have the warnings. Do you agree that we should lift this?

[jharris1993]

We in Mozilla plan to lift this restriction for the sake of web compatibility. We figured that having this restriction does not fulfill the original intention of preventing fingerprinting, as basically everything in 2024 is in HTTPS (🎉).

@marcoscaceres and @nondebug, I see both WebKit and Blink still have the warnings. Do you agree that we should lift this?

I agree 1000% as this restriction makes about as much sense as requiring a secure environment to use a keyboard or mouse.

It's the wrong move, based on an incorrect assumption, and should never have been implemented.

P.S. Is there any possibility of getting similar cooperation from other browsers like Chrome or Safari, et al?

[marcoscaceres]

I think we are ok with removing the warning on the WebKit side.