4 ms·

With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to w

by ksk 11y ago

With caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.

JoshTriplett 11y ago
Not at all. It's fine for the client to handle processing when the only thing they could hurt is the user of the client. If the client renders a web page incorrectly, only the user of the client gets hurt by that. But the server API must not allow a malicious client to do damage that affects other clients.
abraae 11y ago
Your example is about the client misreporting server state to the end user. The big deal is instead about a badly behaved client being able to make "illegal" changes to the server state.
cortesoft 11y ago
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 consequence to that trust being broken.
- ksk 11y ago
  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.
  - Pitarou 11y ago
    MITM isn't really relevant for the purposes of this discussion. We're talking about a different application with different threat models.
  - stefs 11y ago
    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. 2. never trust the client 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. 3. the difference is, with the trusted client model, the client could be hacked and respond with: client says: i've done my transaction, now account A has $52 and account B has $252. the server updates the database accordingly. congratulations, you - as the bank operator - have now lost $4 to the hacker and this is practically what happens with in the division (except that the other players have to pay for it instead of the bank/ubi soft). 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.
- brightball 11y ago
  Exactly. The nuance of every discussion is critical. When somebody says "Never trust the client" inevitably somebody will find a use case that sounds like trust even though it's not what they're saying here and use that as justification. The lack of nuance is how things like "never use stored procedures" gain traction when they shouldn't.
- wolfgke 11y ago
  > If the client messes up the rendering, the only person affected is the client. No, just google "wallhack".
  - Zergy 11y ago
    Arguably the client was trusted with information that was not needed.
    - eru 11y ago
      Alas, performance trade-offs might make this mandatory.

by ksk 11y ago

JoshTriplett 11y ago

Not at all. It's fine for the client to handle processing when the only thing they could hurt is the user of the client. If the client renders a web page incorrectly, only the user of the client gets hurt by that. But the server API must not allow a malicious client to do damage that affects other clients.

abraae 11y ago

Your example is about the client misreporting server state to the end user. The big deal is instead about a badly behaved client being able to make "illegal" changes to the server state.

cortesoft 11y ago

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 consequence to that trust being broken.

ksk 11y ago
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.
- Pitarou 11y ago
  MITM isn't really relevant for the purposes of this discussion. We're talking about a different application with different threat models.
- stefs 11y ago
  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. 2. never trust the client 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. 3. the difference is, with the trusted client model, the client could be hacked and respond with: client says: i've done my transaction, now account A has $52 and account B has $252. the server updates the database accordingly. congratulations, you - as the bank operator - have now lost $4 to the hacker and this is practically what happens with in the division (except that the other players have to pay for it instead of the bank/ubi soft). 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.
brightball 11y ago
Exactly. The nuance of every discussion is critical. When somebody says "Never trust the client" inevitably somebody will find a use case that sounds like trust even though it's not what they're saying here and use that as justification. The lack of nuance is how things like "never use stored procedures" gain traction when they shouldn't.
wolfgke 11y ago
> If the client messes up the rendering, the only person affected is the client. No, just google "wallhack".
- Zergy 11y ago
  Arguably the client was trusted with information that was not needed.
  - eru 11y ago
    Alas, performance trade-offs might make this mandatory.