I'm surprised that "never trust the client" isn't among the basic concepts that everyone should know, at least on HN. It's such a basic premise.
Never trust the client
81–90 of 155 posts
Re: Never trust the client
#82I'm surprised that "never trust the client" isn't among the basic concepts that everyone should know, at least on HN. It's such a basic premise.
If you ignore the context, "Never trust the client/patient/enduser/etc..." is probably equally true.
Re: Never trust the client
#83I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it,…
Because it's very expensive to run almost everything server side, it's not the incompetence of the devs it's just about costs.
Re: Never trust the client
#84Earlier quoted context omitted.
I think that is misinterpreting what the person you are replying to is saying. They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back" If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done. The idea of trust only comes into play if there is a…
Well, a bank website would want to use this to make sure nobody MITMs them, or that the client does not have malware, etc - which would affect the user.
nah, a better example involving a bank would be: you have two accounts. the client can do transactions.
the server sends to the client: account A has $100, account B has $200, make your transaction.
1. trusted client
client says: i've done my transaction, now account A has $50 and account B has $250.
the server updates the database accordingly.
client says: i want to do a transaction from account A to account B with 50$.
the server decreases account A by 50$ and increases account B by $50 and updates the database accordingly.
client says: i've done my transaction, now account A has $52 and account B has $252.
the server updates the database accordingly.
they try to do server checks to prevent this, but due to network timing problems they can't check the exact values, only calculate if this is maybe approximately right.
so a players maximum running speed is, say, 6m/s. they could do periodical checks (every second) if the player moved more than 6m since the last second. but what if the player falls down a building or is thrown by an explosion further than that? it'd register as cheating, even though it's completely legal to jump off a building. so they have to increase the checks for distance/s by 3 to allow those situation (i.e. 18m/s). a cheater with a modified client can now continually run three times as fast as any other player without getting flagged as a cheater.
why do they do this? because it's
a) easier to implement (the client has to do all the computations anyway - doing them a second time on the server and then sending back to the client isn't an easy problem - you have to interpolate) and
b) cheaper (less work = less man hours, less complicated work = cheaper programmers* and less server power needed)
* i'm completely sure the devs would have been 100% able to do it right, but it would have taken them longer, thus costing more.
so, how to fix it? there's only one way: rewrite the model. but this is expensive and the titles have already been sold, so why bother investing another couple hundred thousand bucks? even the disgruntled gamers will buy the next ubi soft title if it's shiny enough. i mean, few people will buy the game now that multiplayer is infected with cheaters but they already exploited enough of the market and long time players are probably less likely to buy the next title if they're still playing an old one. maybe.
Re: Never trust the client
#85I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it,…
Because it's very expensive to run almost everything server side, it's not the incompetence of the devs it's just about costs.
No it is not, as I said many games do it correctly. It is a very simple distance check, you can perform millions per second on cheap commodity hardware.
Re: Never trust the client
#86now that i think about it - doesn't GTA5 suffer from the exact same problem? cheaters spawing tanks above people practically must be a client game state problem.
Re: Never trust the client
#87I'm still constantly shocked at how many games do this. In the MMOG world it is really easy to do everything right, UO came out in 1997 and the devs outright told everyone working on similar games "never trust the client" and "the client is in the hands of the enemy". Yet games like FFXI and WOW that came out many years later have the client setting the position of the player and the server just blindly accepting it,…
UO had rubberbanding rampant - that is, you'd move on the client, then warp back to an old position after the server said you actually didnt move there. It was terrible. Most all MMOs with WSDA movement trust the client to set the player's position and it mostly works. Cheating through warping or speed is easily detectable through other means of post-verification and banning players that fail that verification. It ma…
>UO had rubberbanding rampant
Only if you had high latency and tried to move somewhere you couldn't actually move.
>If speed/warp hacks are a problem, it's not because the developers that use client-set-movement aren't able to fix it, it's because they don't care.
That's precisely what I said. Obviously they can fix it, since it was fixed before they started development. They did it wrong and don't care.
Re: Never trust the client
#88The Division is an interesting game from a QA perspective. While client-side architecture is one thing, blocking bugs are present in the game and have been a strong deterrent to community stability. Case in point, it was recently discovered by the community that gear with the "Protection from Elites" bonus actually increased damage taken from Elites: https://reddit.com/r/thedivision/comments/4g6lnk/tested_conf... And…
coincidentally i re-read the post about the riot games league of legends automated testing infrastructure yesterday. it's fascinating (and honestly, i'm even a bit envious!).
in case you haven't read it yet: https://engineering.riotgames.com/news/automated-testing-lea...
guess it's down to the value of competitive multiplayer. e-sports are the focus of games like LOL (or, i guess, CS), instead of throw-away gaming.
the division won't have international competitions in 3 years - and that's ok with ubi soft. because they'll have a couple of new games out by then and players will have bought those instead of still playing the division.
Re: Never trust the client
#89Obviously, this applies to all networked applications—not just games. It's embarrassing how often I see web apps which use something like Firebase with absolutely no validation or access control. Often the developers behind them don't even realize they have a problem. Their excuse is that "most users wouldn't have any reason to hack it, so why does it matter?" Developers need to realize their clients are inherently i…
Can you recommend a go-to book for this kind of stuff?
Re: Never trust the client
#90Earlier quoted context omitted.
Using the Bejeweled example of a single-player game, and assuming it's properly deterministic, could a malicious actor not just falsify the steps taken as well as the score? It would be more difficult, but not that much more difficult considering the challenge is the time limit and lack of undo. Both would be removed if you were simulating steps.
If you don't care about overkill, you could employ machine learning and anormaly detection: send the input sequences, timing and other difficult to fake data (e.g. gyroscope state) to the server and learn the "typical" distribution of those values. A perfect game played by a robot will likely be an outlier in a lot of the values. (Note that some legit games will also look suspicious, so you'd want to use this to find…
If I was a game developer and a person developed a bot to play my game perfectly, I'd let them have the high score.