hyperplay-desktop-client
hyperplay-desktop-client copied to clipboard
HyperPlay-Gaming
Only have the local server running when I'm in-game
As a HyperPlay server, I'd like to only have transaction requests to the proxy server to be able to be submitted by a PID that was launched from within HyperPlay, so that other applications on my device cannot spam me with transactions that I didn't mean to approve.
description
this is a security related card. it originally was conceived of as a performance issue with leaving the server running, but on further discussion, we've refined this card to focus on the security issue of third party applications sending transaction requests in a way that confuses the player and causes them to approve txs from other applications on their device.
the release has been moved out of the developer alpha to the public beta release.
@jacobc-eth Can you give a little more clarity on what the value for users is? Is this important for security or performance reasons?
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.
This will be a necessary problem to solve before this goes public. Not neceessary for MVP.
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.
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.