[0x262d]

What is the downside of this if I trust the software provider (eg Riot Games or presumably Valve if this ever comes to Linux)? I have recently come around in support of Riot's anticheat because multiplayer competitive games are so damaged without it, even though I use Linux 95% of the time.

[frollogaston]

It's hard to trust. I have a spare Windows PC where I install whatever on it, and the EA Javelin anticheat has screwed things up before. Wouldn't be doing that on a computer I care about.

Could the kernel have something built in to help with this? Like it can tell a program that nothing else is looking at its memory. And then secure boot attests that the kernel isn't tampered with.

[seba_dos1]

> And then secure boot attests that the kernel isn't tampered with.

That's pretty much a dystopian scenario where you're unable to interact with any network services without using devices with software that's controlled and/or trusted by the service provider. Basically a grave threat to Free Software as a whole, the end of free reimplementations of things you rely on to connect with the society. We already have a glimpse of that on mobile phones controlled by Google and Apple, we don't need more.

There are kinds of games that actually rely on anticheats to be viable, but they're in the tiny minority and I don't think they're worth reorganizing the society over. Most just consider it a solution for problems caused by their incompetently designed netcode.

[frollogaston]

Linux and Windows both already support secure boot. Anyone is free to make a locked down version of Linux, and they have (game consoles, Android). Desktop Linux has way less market share than Windows. So what would you like SteamOS or the Linux kernel to do? I'm not fond of this stuff, but at least if people are using a partially locked down video game focused Linux, it's better than them going to Windows.

[seba_dos1]

My comment is about remote attestation, which is incredibly user-hostile technology; not secure boot. Secure boot enables remote attestation, but by itself is mostly harmless.

[frollogaston]

Android and game consoles do remote attestation too.

[seba_dos1]

Yes, I mentioned that (have you read my comment??). These are already nightmarish environments and we don't need to copy that nightmare onto other platforms.

[dijit]

Attestation-gated anti-cheat is invasive, and the direction it points is grim.

But "covers for incompetently designed netcode" doesn't hold at all.

Netcode and cheat-resistance are mostly orthogonal. Netcode is latency-hiding — prediction, reconciliation, interpolation. Cheating is the client being an endpoint you don't control. You can have flawless netcode and still get wallhacked, because a wallhack touches the renderer, not the wire. You have to ship that data for the client to draw the level.

Server-side validation kills the cheats that surface as state: speedhacks, teleports, impossible positions; but it's blind to the ones that don't touch state at all. A wallhack reads memory the client holds. A vision aimbot runs on a second machine reading the screen- nothing crosses the network for the server to reject.[0]

That's why the kernel and attestation stuff exists. Not lazy devs papering over a bug: a class of cheat that server authority structurally can't reach, because the cheat never lies to the server.

I understand the dystopia argument, and it's a decent one. "Just write better netcode" isn't.

I'd humbly request that you spend time trying to actually grapple with the problem, there are some exceptionally well paid and talented programmers who are working on this non-stop in the large publishing houses (EA, Ubisoft, Tencent, Activision) who would do anything to avoid paying royalties to shitty software that breaks the performance and reliability of their games: yet for some reason year over year they can't seem to manage it.

Worth understanding why that is, instead of assuming incompetence or malice; perhaps its a harder problem than you think.

[0]: https://arxiv.org/pdf/2512.21377

[seba_dos1]

> Cheating is the client being an endpoint you don't control.

No, cheating is enabled by the client being trusted despite of inherently not being trustable. The solution is to design the architecture of the game server in a way that makes it not rely on untrusted inputs and doesn't distribute knowledge the player isn't supposed to possess, rather than try to force the clients to be trustable by eliminating general purpose computing from the society. It's not always possible, but IME these cases where it's not are exceptions rather than rule.

Instead, more and more games just reuse some general purpose netcode for $engine to synchronize state between clients and eventually attempt to paper over the issues with that approach using anticheats. I've recently played a multiplayer game where I (accidentally, while messing around for benign reasons) noticed that I could control the global state of the entire map just by sending commands to the server that referred to various objects and they were accepted and broadcast regardless of whether my character had actually possessed them. That's the kind of code that, once the game gets popular enough to attract enough cheaters to cause actual pain, gets an anticheat slapped onto it the most eagerly, as nobody's going to rearchitect their game's entire netcode from scratch if they can just not do that.

Remember Fall Guys? A relatively big budget game with absolutely no reason to trust the client over anything other than the player's own key presses, where you could teleport over the map to instantly win the match? Solved with, of course, EAC.

[frollogaston]

I know about the cheating problem and would rather they just not solve it. There are more important things than video games.

[dijit]

Cool,

You're welcome to, but those games precipitously lose players, because it's frustrating.

https://www.reddit.com/r/GTA/comments/1af8t12/online_isnt_fu...

[frollogaston]

I know it's frustrating, I really don't care. They can play or do something else. GTA Online from those comments actually does look like a case of bad netcode btw, and it does have kernel anticheat already.

[justaregulanerd]

My thinking would be that because the anticheat is closed source, it makes it a trust exercise in the developer where you've allowed them root access to your machine.

I'd also think outside of the developer's motives, and into any potential vulnerabilities that could use the anticheat as a privilege escalation point or the anticheat itself being given a bad / malicious update.