Re: [w3c/gamepad] Please don't restrict to a secure context (#145)

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](https://github.com/w3c/gamepad/files/7833071/Flash.Cookies.and.Privacy.II.-.Now.With.HTML5.and.ETAG.Respawning.pdf)

What say ye?


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/145#issuecomment-1007953832
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/145/1007953832@github.com>

Received on Saturday, 8 January 2022 10:51:10 UTC