I would like to respond because you're speaking authoritatively but this is mostly your opinion.
> I want to clarify to anyone reading this that this only effects high-competitive games, like LoL, Valorant, PUBG, R6S; and not all of them (e.g. Counter Strike).
It affected a game I really care about: Arc Raiders. That's not a "high-competitive" game. It's PvPvE, shooting at funny robots and scavenging rubber duckies. Cheating killed the game. [It's down to 6% of its peak.](https://steamcharts.com/app/1808500#All) Just because this hasn't affected the games you love doesn't mean it's not affecting many games. See Titanfall, H1Z1, and The Cycle: Frontier, among many more.
> It does not affect "multiplayer" in general, to the contrary, most multiplayer games are not affected (coop games, MMOs, RTS).
I was going to ask you to back that up, but I realise I made a broad claim and can also not back it up, so we're just giving each other our opinions, I suppose.
> Ofc, cheating is also present with KLAC, its just the next level of the cat and mouse game (Driver exploits, DMA access via PCIe, Network Packet analysis, ...)
Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.
> Nonsense. 1. Almost no anticheat is implemented on Linux in the first place. Most "working" anti-cheat solutions for Linux are just a #if Linux doNothing(); #else ... 2. KLAC requires SecureBoot/ChainOfTrust + closed source code running with highest privileges. This does not make sense for any PC, but I dont see why it would be harder to do on Linux than on Windows, Linux just has a smaller install base in general and a lower acceptance rate for KLAC, therefore its not worth it to implement.
Linux does not properly support KLAC because its architecture and development philosophy work against it. For example, Valve explicitly recommends user-space anti-cheat for Proton and says kernel-space anti-cheat is “not currently supported and is not recommended”.
The Linux kernel also deliberately does not provide a stable binary kernel-driver interface. Kernel maintainer Greg Kroah-Hartman has said that Linux has neither a stable in-kernel API nor a stable binary kernel interface, because maintainers want the freedom to change kernel internals rather than permanently support proprietary out-of-tree drivers.
Riot is on the record as explaining that Linux does not give Vanguard sufficient ability to attest boot state and kernel modules. They also claim that distribution differences make enforcement harder, and that cheats can potentially operate outside an emulated environment where the anti-cheat cannot see them. Riot is on the record saying that anti-cheat is “extremely hard on Linux by design”.
So you're technically correct, but I think you misunderstand a lot of the architecture which underpins this issue, and the ideological boundaries which many developers prefer to enforce around security, FOSS, and ownership.
| I would like to respond because you're speaking authoritatively but this is mostly your opinion.
Sorry, I felt inclined to respond to your broad claim "It's nearly impossible to play multiplayer games now without KLAC".
XKCD 'Wait, Honey, sb. is wrong on the internet', we both know it.
| Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.
I agree with the goal, but KLAC is not an acceptable way to get there. I would rather suggest to:
- dont trust the client
- really dont trust the client
- support / let customers host the servers (they are the ones who will put in the time required to deal with cheaters, and they will also be there once the devs/publisher have abandoned a game)
- Use statistics a lot more: mark outliers for review, and until review, aggressively move them to their own matchmaking bracket.
- Implement a "demo"-style replay format for matches/sessions (which therefore contains all inputs of all parties). Make all "ranked" or eq. matches publicly available (no names/chat, just the gameplay) and people will develop tools in their free time to detect cheaters.
Also: Have a simple trust score (Account age * Money spent), and act more aggressive on people with low trust score.
Let new people improve their trust score by reserving ~$100 on a credit card which will be billed if the account gets banned for cheating.
I do wonder if AI could be used to statistically identify likely cheaters, but as with all statistics, some innocent people will be caught, and many guilty people will not be caught. Existing server-side anti-cheats have been trying to use some variation of statistical analysis for at least a decade, with poor results. It's not hard to program movements based on statistical modeling of pro players and ensure the movements remain within a standard deviation of that. Aim bots are particularly difficult to statistically identify, assuming the bots have been competently programmed. The end-game is cheaters running around with pro-level skills.
To be clear, I welcome the attempt, but I think it just results in the same cat and mouse arms race we've seen for 20 years. Inference has been beaten time and time again. Until it is proven to work I will stick with the best options we have right now.
These stats should not auto-ban, but flag for human review.
ImO, the goal is to find the statistic cheaters will skew since they are cheating.
Lets say, one is wall-hacking in Counter-Strike.
In Counter-Strike, many maps have a central location/lane called "mid".
There is often a kind of mind-game of limited information going on:
- Does 0, 1, or both teams have an AWP(=one-shot kill sniper)
- Is the enemy sniper guarding mid?
- Which entrance to mid is the enemy sniper currently watching?
- Has the enemy sniper guarded mid in the beginning, but has now left?
Any wall-hacker will be a major outlier regarding not running into mid while the enemy sniper is watching.
If you can accurately dissect/classify/log player behavior, I expect the statistics to look similar to those of poker players who cheat and know the cards of the other players on the table:
https://media.pokertube.com/uploads/2025/12/5d96fe17d39043a0...
Doesn’t Arc use KLAC? Sounds like it did not accomplish its goal. And I’m not sure how you trace direct causation between cheating and decline in popularity. Plenty of games with rampant cheating (Tarkov) do just fine.
Only on Windows (and only after the game had already lost around 80% of its player base), which makes it effectively useless. Because they have a Linux build, there is no way to prevent cheating at a larger scale.
It's fair to argue I have no evidence of the cause of decline. I cite my frequent interactions with hundreds of players in the community, and streamers like Burnt Peanut. However this is qualitative, not quantitative. Me and my friends stopped playing because of the cheating, and so did every other one of my friends who picked it up. It wasn't that we wanted to stop playing the game. It was the cheating.
> I want to clarify to anyone reading this that this only effects high-competitive games, like LoL, Valorant, PUBG, R6S; and not all of them (e.g. Counter Strike).
It affected a game I really care about: Arc Raiders. That's not a "high-competitive" game. It's PvPvE, shooting at funny robots and scavenging rubber duckies. Cheating killed the game. [It's down to 6% of its peak.](https://steamcharts.com/app/1808500#All) Just because this hasn't affected the games you love doesn't mean it's not affecting many games. See Titanfall, H1Z1, and The Cycle: Frontier, among many more.
> It does not affect "multiplayer" in general, to the contrary, most multiplayer games are not affected (coop games, MMOs, RTS).
I was going to ask you to back that up, but I realise I made a broad claim and can also not back it up, so we're just giving each other our opinions, I suppose.
> Ofc, cheating is also present with KLAC, its just the next level of the cat and mouse game (Driver exploits, DMA access via PCIe, Network Packet analysis, ...)
Indeed. The goal is to reduce cheating to a manageable level. It is impossible to eliminate.
> Nonsense. 1. Almost no anticheat is implemented on Linux in the first place. Most "working" anti-cheat solutions for Linux are just a #if Linux doNothing(); #else ... 2. KLAC requires SecureBoot/ChainOfTrust + closed source code running with highest privileges. This does not make sense for any PC, but I dont see why it would be harder to do on Linux than on Windows, Linux just has a smaller install base in general and a lower acceptance rate for KLAC, therefore its not worth it to implement.
Linux does not properly support KLAC because its architecture and development philosophy work against it. For example, Valve explicitly recommends user-space anti-cheat for Proton and says kernel-space anti-cheat is “not currently supported and is not recommended”.
The Linux kernel also deliberately does not provide a stable binary kernel-driver interface. Kernel maintainer Greg Kroah-Hartman has said that Linux has neither a stable in-kernel API nor a stable binary kernel interface, because maintainers want the freedom to change kernel internals rather than permanently support proprietary out-of-tree drivers.
Riot is on the record as explaining that Linux does not give Vanguard sufficient ability to attest boot state and kernel modules. They also claim that distribution differences make enforcement harder, and that cheats can potentially operate outside an emulated environment where the anti-cheat cannot see them. Riot is on the record saying that anti-cheat is “extremely hard on Linux by design”.
So you're technically correct, but I think you misunderstand a lot of the architecture which underpins this issue, and the ideological boundaries which many developers prefer to enforce around security, FOSS, and ownership.