Hacker News new | past | comments | ask | show | jobs | submit login

As a developer it's really easy to do simple client side auth like this. Adding server side auth creates a great deal more work and potential usability issues.

As a business question, is it worth it to think about cheating in advance and try to prevent it?

Just going by the example of Letterpress, it seems the answer is a resounding NO.




There doesn't need to be any server-side auth, you could have the opponent's device to check the validity of the word when it's played. If it's not in their dictionary, it rejects the play.


Why not just reject every word your opponent plays?


You and your opponent could verify your dictionaries when you are matched up. Checksum mismatch = cancel match-up. Cheaters would be naturally weeded out.


I'd only need to hack my copy of the client to send a pre-determined checksum value- or recalculate it from a different dictionary than the one that's actually used.

If hacking the client is too much of a bother then I'd just have to put a filtering proxy in front of the app to accomplish the same thing.

The only solution to this is to check words on the server.


I'd point that unless I'm greatly mistaken there is no server involved, as it is all done through Game Center's turn-based game functionality.


AFAIK you are correct.


"The only solution to this is to check words on the server."

What problem are you trying to solve?

My understanding of the problem being discussed: How can you make sure you aren't being cheated when playing Letterpress?

To solve that problem, all I have to do is validate that all your moves are legal. (In the case of Letterpress, that all the words you play are in the dictionary.)

There's no need for a server to solve that problem.


> To solve that problem, all I have to do is validate that all your moves are legal.

Fair enough, that keeps me from cheating you by playing an illegal word. Now, what prevents you from cheating me by saying all of the words I play are invalid? (And are you really prepared to wait until my phone is in radio range before you learn if your play is accepted or not?)

That this would make for an incredibly boring game isn't relevant.


You already know whether your play is legal or not. If you're not cheating, then all your plays will be legal. You don't have to wait for anything.

As to your opponent rejecting legal moves, what's the problem? You made a legal move, and then they refused to continue the game. There's no issue here.


Well the problem arrises in how such a game with "passive" cheating (your opponent having removed words you might play from their dictionary to thwart you) would be counted. Detecting a mismatch is simple, determining if it was malicious, and thus the next action you take afterward is more complex:

1. You could send back a rejection. This would handle the legitimate mismatch where differing versions of the app could have different dictionaries (there are notable missing words in the 1.0 so I wouldn't be surprised if words are added in newer versions). Receiving something like "could not verify word" is much nicer than the game just ending on you. However, this still allows your opponent to cheat in the manner described above by removing words you want to play from his dictionary. It would thus be frustrating to play against such a person. He knows the word is valid, but cannot play it against you and must play something else. He is forced to decide whether to forfeit or try a different word.

2. The solution you described: simply end the game, no win or loss since you can't know who was at fault. If this game EVER employs a ladder system, then this is the equivalent of pulling the cord in an internet game, you avoid a loss. Not to mention, again, this doesn't deal with the cases of legitimate differing dictionaries.

The problem with both these methods is that cheating still has an affect. Whether it be ending the game or volleying back to you, a cheated action changes the state of the game. It is instead preferable to prevent cheating. Prevention really does thus require words to simply get checked on a server. 1. There is a clear trusted source for the words, 2. You don't need to ship an App Store update to update your dictionary. 3. There is simply no such thing as word cheating anymore, short of hacking the server.


You've introduced two new problems, neither of which we were discussing previously:

1. How can you deal with multiple versions of the dictionary?

2. How would a third-party (like a rating system) handle cheaters?

I would say that the simplest solution for #1 is to not allow this. Players shouldn't try to play against each other if they don't agree on the dictionary. Whether you update dictionaries by shipping new versions of the app, by having clients download them from a server, or by keeping them on the server (as an oracle) isn't important.

For the second problem, I think you have a server by definition. You introduced some sort of rankings, which I assume are held on a server somewhere. So this is considerably off-topic.


1. It occurs to me that you may have misunderstood how the server system we are describing would work. Your use of the word "oracle" I believe implies that you think the client is asking the server if the word is fine, then if it is, the client is then sending that word to the other client -- which I agree, is no more secure. However, that is not how it would work. The way it works is you send the word to the server, if the server is happy with it, it sends it to the other player, that way there is a gatekeeper that it is impossible to circumvent.

Without a server, the solution of "ensuring" the same dictionary on both sides is no different than our original issue of checking individual words: how can you reliably check if both sides have the same dictionary? One side can always just lie, because it ultimately is communicating directly to the other party. The client can send fake dictionaries, fake checksums, fake app version numbers, fake anything to the other side. All you've done is move the individual word checks currently being done to one-time some-other-value checks. For this reason it has absolutely everything to do with a server. The server has to be the holder of the "truth" and thus bad words simply will be rejected with no issue. If you are always doing checks on the client, there is simply no way to ever be sure of anything. If you want to argue "OK fine but I don't think many people will cheat", then that is an acceptable but very different argument. But saying "I can thwart cheating just fine solely with client-side operations by doing ____" is really just a waste of your time because it just won't work, you might as well just do nothing.

2. Here I was implying the use of the built in Game Center rankings (which I'm not sure why letterpress doesn't currently use). For example you can go on there and see the top X players of Jetpack Joyride (and this requires no server).

EDIT: I wanted to add that "multiple versions of the dictionary" is not a new problem, it is in fact just a description of the original problem. The author in fact got away with all this by changing his dictionary. I simply pointed out that there existed legitimate cases where this could happen (and probably likely in the future) as well as illegitimate ones, and why this is probably a good thing to consider if you are trying to solve this issue.


1. Both players can just give their version numbers at the beginning of the match (or checksum if that's easier). Don't start a game with someone who doesn't have the same dictionary as you, because that's not fair. Your opponent has no incentive to lie here, but they can if they want. If they try to play a word not in the agreed-upon dictionary, you'll immediately notice and see that they're cheating. (No need for a server!)

2. When you say "This requires no server," you mean "Game Center provides the server." I don't know how this works, but it seems like it would allow cheating. If you want to actually know who beat whom in what game, you'll need them to submit their moves to a trusted third-party (and of course you'll need to validate that their moves were legal). I'm not disagreeing with that; it's just off-topic. (Okay, to be pedantic, I believe asymmetric keys and the right protocol would allow two players to play such that they could later disprove any false claims about the sequence of moves. But now I'm veering way off topic.)

EDIT: Just to sum up the only point I'm trying to make on this thread: Letterpress is currently a game of perfect information with only two interested parties, namely the two players. Ignoring external rules like "You shouldn't let someone else (i.e. a computer) help you," there's no way to cheat undetected in a game of perfect information. E.g. When two people sit down to play chess on a physical board, there's no need for a referee. Either player can tell if the other player "cheats."


At this point I just want to make it clear that I don't want to be argumentative, but rather just find out whether you don't understand me or I don't understand you :)

Just for clarification, when I talk about servers I am referring to "my own hand coded server that I run" -- like what you would need for this kind of game before Game Center existed. I refer to dealing with Game Center as "serverless" simply because your code can't run on Game Center, so for the purposes of this discussion its as if both clients are talking directly to eachother since Game Center serves simply as a dumb pipe.

1. That being said, a main point of my last post was that its very simple for either party to lie about this initial state (either intentionally or unintentionally as we'll see in a second). Its as simple as changing the dictionary AFTER the game starts (its slightly more complex if the dictionary is being checked EVERY move, but not much more complex). I want to also specifically note again that this could actually easily have happen accidentally:

Lets say I updated from the App Store mid game, and now you have all sorts of weird edge cases as we are once again in the situation where one person has more words in their dictionary than the other. If you simply did one check in the beginning, the game is now once again "unfair". If you are doing a check every turn, the situation is still not ideal. Does it just drop the game assuming the worst? Or do you instead "freeze" the game indefinitely until both parties have updated? Perhaps it continues using the "old dictionary" for that ONE game -- requiring potentially storing multiple "versioned" dictionaries until they're done being used? Then you have the weird effect that you could have sworn you just successfully used that word in another game you just started but its not working here, huh. None of these is particularly satisfactory or fun to code.

So yes, you can always detect a mismatch, but what's interesting is how you then proceed. In other words, determining WHY there is a mismatch. Again, if you are willing to simply terminate abruptly regardless as soon as the game detects a disagreement that's fine, but in my opinion that is not a good user experience (this is what I meant before about preventing cheating vs. detecting cheating). A world where everything goes through a server gatekeeper simply does not have this issue, as there is only ever one dictionary -- the app wouldn't even need to include a dictionary itself. There is simply never a scenario where one client successfully sends bad data to the other client (short of someone hacking your server of course).

2. I meant here only that letterpress could today start using Game Center's rankings without providing its own server (the same way Fruit Ninja does for example). Of course I think this is bad for the same reasons I think not going through your own server for each move is bad, I just wanted to point out that since letterpress seems determined to go "serverless", and rankings are a feature people have requested, these "cheating" issues could be compounded by having rankings, that is all.

To sum up my point: With client to client communication there can necessarily always be disagreement (which you seem to agree with). One side can always say "this is good" while the other says "no its not". Since at this point you are stuck, not knowing who caused the disagreement, the end result is not "user friendly" (and again arguably ALLOWING this to happen in the first place is not user friendly -- I think everyone would prefer a world where you simply can't send bad data). To provide a good user experience I think it is better to avoid this possibility completely. With client->server->client communication, the clients will never disagree. The "thinking" takes place ONCE on the server, so the message is known to be sane by the time it gets to the opposing client. Whenever there are just two parties talking to eachother you can never know who is telling the truth. Again, in a world where you "don't care" about the results that is fine: by that I mean if you are willing to terminate the game and establish "no result" the second there are any shenanigans started then I am in complete agreement with you that you need no server. This however doesn't mean no cheating, it just means BAIL on detection of cheating. However, if you want to establish who won (in other words say "congrats" or "sorry you lose"), whether it be as simple as just showing the correct dialog to both users or more importantly if you ever wish to record it publicly (such as in a ranking system) -- then it is necessary to have an actual resolution, which can only be reliably done if the actions are going through an external gatekeeper:

SERVER MODEL: client1 sends word to server -> server checks word -> server sends word to client2 (even if I send bad words maliciously they will never get past the server, at the end of the game the winner can be recorded) CLIENT MODEL: client1 sends word to client2 (since at any point in the middle I can send a bad word -- whether it be because I'm malicious or because my app got updated or WHATEVER -- the clients can be placed in a conflicting state)


At this point, I doubt either of us misunderstands the other. We're just talking about different requirements. If you think we disagree about something, please state the problem you're solving. I'm just solving for "How do I know my opponent isn't cheating?" I'm claiming there's no need for a server to solve that problem.

In terms of the dictionary changing mid-game, I think the most user-friendly experience is to not allow this. (Both players must use the dictionary they agreed upon at the beginning of the game.) Moving the dictionary to the server doesn't make any difference here; it's simply not fair for it to change during the game. (Maybe I wanted to play a word, but it wasn't available. Now that it's your turn, it is suddenly available.)

"Since at this point you are stuck, not knowing who caused the disagreement... Whenever there are just two parties talking to eachother you can never know who is telling the truth." Who's "you?" The two parties playing the game certainly know who's telling the truth.

If you're talking about a third party, that's the scenario I'm not particularly interested in discussing. We may or may not agree on the requirements if there's a third party who needs to know the outcome of the game. But I think we can agree there is no such third party in Letterpress. That's precisely why no server is required. I think you're arguing for a server because you're designing for a different set of requirements.


can you check the md5sum on the dictionary files ? approved values per version are included in the binary, if the check fails it prompts for an update?

what happens when a letterpress update updates the dictionary but you are playing against someone with an older version ?


Because that would freeze the game state and defeat the purpose of playing?


What if you have two different versions of the app with different dictionaries?


I'm curious whether there even is a server-side component to this, or whether it just passes the moves in the next turn notification in GameCenter. Not sure if the latter is possible but it certainly seems doable.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: