Re: [w3c/gamepad] Should fire events instead of using passive model (#4)

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.:
There is a setting:  `Allow gamepad [always | never | ask]` which defaults to "ask"; placed with the other hardware permission settings within the browser's preferences.

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?


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

Message ID: <w3c/gamepad/issues/4/1012188769@github.com>