Only have the local server running when I'm in-game about hyperplay-desktop-client HOT 5 OPEN

@jacobc-eth Can you give a little more clarity on what the value for users is? Is this important for security or performance reasons?

from hyperplay-desktop-client.

Is this for security? Because I think there could be better security strategies. For instance, maybe each game has an api key and any local calls that don't have a valid api key are rejected. This also adds complexity as the user should be able to close out of hyperplay (or it crashes) and restart it while their game is running without having to relaunch their game. Not sure if we can or want to get a list of all processes running in the OS and check if any of them are hyperplay games before starting the server in this instance.

I think rejecting all calls to the server that don't come from localhost should be good enough security for this stage. Open to discussing this further too.

from hyperplay-desktop-client.

This will be a necessary problem to solve before this goes public. Not neceessary for MVP.

from hyperplay-desktop-client.

We thought about doing that because of security at first and also not spending machine resources, even though it is not too much.
the idea would be to run the proxy server only if a Web3 game is running and the wallet is connected.
I am not sure if there is a high-security risk or not but I imagine that, even if we deny all connections that are not from localhost, in case the machine has malware that can run a localhost server similar to how HP will do (we will be OSS after all), it could intercept the connection. I might be overthinking this but having it off or having API keys to be exchanged by HP and the games would be ideal imo.

from hyperplay-desktop-client.

These are good points, @flavioislima. imho, we don't need this story for the developer alpha, but we should have it before launching the end-user beta. I believe to whatever extent possible, we should confine the local server to only the PID that is associated with the game that was launched. This can help with other applications on the device submitting spammy transaction requests that the user might think were being requested by the game they are playing, but were actually associated with a different application running on the device.

Ultimately, if the user has a RAT/malware, this is beyond our security model (same policy as metamask). A RAT could replace the HyperPlay software with a malicious fork of our client, and there is nothing we can do to stop this. However, we should still doing everything we can to curb spammy transactions and to defend against this in reasonable ways we can make these attacks harder to execute.

I'm updating the text of the original card to make things clearer.

from hyperplay-desktop-client.