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

> 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](https://www.w3.org/TR/design-principles/#secure-context) 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 [. . .] 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.



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

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