Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be more strict about valid messages so that server and clients can identify a failed shuffle and minimize exposure to malicious clients #3

Open
emergent-reasons opened this issue Apr 6, 2019 · 0 comments

Comments

@emergent-reasons
Copy link
Collaborator

emergent-reasons commented Apr 6, 2019

Tangent mention cashshuffle server issue 72

Specific examples:

  1. Server receives invalid blame: what should happen?
    • Currently the go server does not act on the invalid blame but it broadcasts it anyway.
    • I recommend that this is specified as the correct behavior. In fact I do not see a reason that the server even needs to be observing the blame reason. Let the clients determine blame. The only time the server should be involved is when it would be impossible for the clients to detect (such as a passive player holding a spot in a pool).
  2. Client receives invalid blame reason: what should happen?
    • @cculianu can you comment on this?
    • I recommend that the client basically be required to send a counter-blame with a valid reason and then immediately disconnect.
  3. Server receives some shuffle-specific message (or malformed registration) before registering: What should happen?
    • Currently server disconnects a player that sends anything but registration first.
    • I recommend we send a message to the player (or all players) and make this behavior part of the spec. It is narrow and clear behavior that helps innocent (but misbehaving clients) to improve and blocks a class of malicious behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant