> From a servers perspective there is no difference between a client with a shitty connection and a client who is pretending they have a shitty connection to cheat. The reality is that servers trust clients for some cases (and verifies that those things are possible) because it provides a better experience for a large number of players.
Lag switching is only one kind of cheat that applies mainly to multiplayer FPS games, and as I said, it can be mitigated through statistical analysis. A simple method would be to kick players (but not ban) from a match if they have too many latency spikes. A better method would be to analyze how often a player's latency spikes coincide with their kills, and ban them if there is excessive correlation.
You are right that preventing any and all forms of cheating is impossible, especially where such methods would negatively impact the player experience. But a perfect solution isn't necessary. Issuing bans after the fact is still effective, as long as the cheaters don't make too much progress or otherwise cause too much impact within that time frame.
> Let's be honest, server side anticheat is no less susceptible to this than client side. If you're banning on heuristics there's going to be false bans at some point, and you are making assumptions about a perfect client environment with this approach.
But that tradeoff is entirely under your control. With server side heuristics, you are in a better position to understand how it works and document it so that others on your team understand it as well. You can tweak its parameters and specialize it with assumptions specific to your game mechanics, and minimize false positives to some probability interval. You can identify specific cheating patterns (e.g. perfectly tracking an enemy behind walls long since the enemy is last seen) and tailor your heuristic to detect such cases. You can feed it more sample data to increase its accuracy. You can set up processes to verify ambiguous cases with human moderators in the loop. None of this requires any assumptions about the client environment, it only requires analyzing the player inputs received by the server over the network. Client side heuristics, on the other hand, tend to be based on things that serve as rather poor proxies for cheating. Running the game in a virtual machine? Banned. Running the client in WINE on Linux? Banned. Driver signature enforcement disabled? Flagged. User running AutoHotKey or WinDbg or Ghidra? Flagged. New Windows update that breaks some internal NT kernel ABI that my anti-cheat rootkit was relying on? Uh oh. These detection methods are better than nothing, but heavy reliance on them has made it easy for cheaters to circumvent anti-cheats while still causing issues for legitimate players whose setup might deviate slightly from the norm.
> Except you can analyse the ban rates based on how "aggressive" your cheat is across all your players and adjust the effectiveness to keep it under that threshold. If we're going to make the claim that cheaters can always adapt to client side cheats, we can make the same claim for server side cheats.
While true, this sort of signal carries much less information than what you can gain from reverse engineering client side cheat detection. You can make it more difficult by issuing ban waves at fixed intervals, and slightly varying the thresholds by some small random amount each time. Larger ban wave intervals mean that it takes longer for cheaters to infer the behavior of your server side anti-cheat, at the cost of taking longer to ban cheaters. But again, that tradeoff is under your control.