[Youden]

As someone who mainly deals with web services, this all seems really weird to me. I was told from very early on "never trust the client". There was a lot of emphasis on server-side validation; client-side validation was only ever for UX, e.g. highlighting the field in red instead of making the user submit the form first.

Reading through this, it seems the game development world is doing the exact opposite and pushing all the "security" measures to the client. Is that incorrect? If it's correct, does anybody have any idea why?

[banachtarski]

You’re a bit out of your depth. Of course “trust the server” is preferred but many forms of cheats are purely client side. For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound. Maybe the client hijacks the UI to hide terrain and walls.

I’m not saying what valorant has done here is right, there are other things you can do. But you’re oversimplifying the problem.

[Youden]

I understand that but it feels like there's a lot of focus on client-side anti-cheat while cheats that should be trivially detected server-side still exist (like flying through the air in a game where that shouldn't be possible).

Plus, there seems to be a lot of focus on client-side anti-cheat when a lot of it could be addressed server-side:

> For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound.

This sounds like a similar problem to "like" fraud and things like that. Couldn't it be addressed by measuring the number of incidents? If someone is able to headshot or dodge at an abnormal/superhuman level, that can be detected server-side and the user banned (or flagged for human review).

> Maybe the client hijacks the UI to hide terrain and walls.

Someone mentioned a solution for this elsewhere in the thread: don't send positions of important resources to the client if it doesn't need them. Keep the client about as blind as the player.

And again, you should be able to detect this server-side. If somebody has an abnormally high kill-rate for enemies coming around a corner, flag them for review.

[banachtarski]

Humans can and do in fact do all the things you suggest. False positives are generally to be avoided, and mitigations for reverse engineering are still required (anti debuggers, anti dll injection measures).

All the stuff mentioned like not sending positions of people who aren’t visible are typically already done, but sometimes the position is needed for reasons you don’t understand. Like some gameplay ability to suddenly see through walls, etc.

This thread just has a lot of backseat programming.

I think I would find your post a little less irksome if you approached it from a neutral questioning tone as opposed to “what about these obvious things every junior engineer learns” :/

[Youden]

I'm not trying to condescend or be a backseat programmer, I apologize if my tone suggested otherwise. I know that I have no idea what I'm talking about and I know that there are plenty of competent game developers in the industry.

The problem is that I don't know what I don't know, so I can't directly ask it. The best thing I can do is to present the flawed results of my current understanding so that somebody more knowledgeable (such as yourself) can tear them apart and show me what it is that I'm missing.

> False positives are generally to be avoided

This sounds like the biggest difference to me. Generally in my limited experience in handling abuse on web platforms, the value of a single user is so low that a false positive doesn't really matter too much.

I suppose when it comes to games, each user represents a ~$60 investment and potentially a lot of time and emotional investment, so a false positive can't be so easily tolerated and there's an incentive to go to extreme ends (like intense client-side validation) that wouldn't make sense for say Twitter likes.