← Back to context

Comment by hananova

4 hours ago

All Valve has to do is say “Your software cannot deliberately exclude linux support including kernel anti-cheat to be listed on Steam.” And that would be that, the few devs big enough to make it on their own would leave, and everyone else would adapt.

Worth noting: Valve’s own first party tournaments for their own game require kernel level anti-cheat (from a third party vendor). Valve themselves have given up on allowing players in their own title play competitively in a Valve sponsored event with a kernel level anti-cheat. I can’t imagine they’d ever be this brash.

There is no adapting without a proper solution for securing game integrity.

The games would just leave Steam. The big publishers want their own platforms and launchers anyway.

  • The big publishers already have their own launcher and platforms and are increasingly moving back onto Steam because they see higher PC player counts and sales when their games are there

  • That's not the trend that we're observing. As much as publishers and developers want to control their sales channels, the current trend is for them to move towards Steam, not away from it.

    The more likely outcome is that developers would segment matchmaking into people with kernel-level anti-cheat, and people without it. This seems fair to me.

    • Several big publishers did move away from Steam until Valve conceded some of their revenue, reducing their cut from 30% to 25/20% at certain revenue thresholds. That convinced the publishers to return to Steam, but it showed that Valve isn't immune to being flexed on by the bigger players.

Yeah, I would hope not. Trying to impose your will on suppliers and b2b customers like this is how you get hit with an antitrust lawsuit.

Is there an feasible alternative to "kernel anti-cheat" available on Linux?

  • There isn't.

    When it comes to anti-cheat on Linux, it's basically an elephant in the room that nobody wants to address.

    Anti-cheat on Linux would need root access to have any effectiveness. Alternatively, you'd need to be running a custom kernel with anti-cheat built into it.

    This is the part of the conversation where someone says anti-cheat needs to be server-side, but that's an incredibly naive and poorly thought out idea. You can't prevent aim-bots server-side. You can't even detect aim-bots server-side. At best, you could come up with heuristics to determine if someone's possibly cheating, but you'd probably have a very hard time distinguishing between a cheater and a highly skilled player.

    Something I think the anti-anti-cheat people fail to recognize is that cheaters don't care about their cheats requiring root/admin, which makes it trivial to evade anti-cheat that only runs with user-level permissions.

    When it comes to cheating in games, there are two options:

    1. Anti-cheat runs as admin/root/rootkit/SYSTEM/etc.

    2. The games you play have tons of cheaters.

    You can't have it both ways: No cheaters and anti-cheat runs with user-level permissions.

    • Rootkit anti-cheats can still often be bypassed using DMA and external hardware cheats, which are becoming much cheaper and increasingly common. There's still cheaters in Valorant and in Cs2 on faceit, both of which have extremely intrusive ACs that only run on Windows.

      At the level of privilege you're granting to play a video game, you'd need to have a dedicated gaming PC that is isolated from the rest of your home network, lest that another crowdstrike level issue takes place from a bad update to the ring 0 code these systems are running

    • Even kernel anti-cheat can be defeated, this is a similar fight to what captchas have.

      I can just have my screen recorded and have a fake input signal as my mouse/keyboard.. or just simply hire a pro player to play in my name, and it's absolutely impossible to detect any of these.

      The point is to just make it more expensive to cheat, culling out the majority of people who would do so.

    • I don't fully agree with the 1 and 2 dichotomy. For example, before matchmaking-based games became so popular a lot of our competitive games were on dedicated servers.

      On dedicated servers we had a self-policing community with a smaller pool of more regular players and cheaters were less of an issue. Sure, some innocents got banned and less blatant cheaters slipped through but the main issue of cheaters is when they destroy fun for everyone else.

      So, for example, with the modern matchmaking systems they could do person verification instead of machine verification. Such as how some South Korean games require a resident registration number to play.

      Then when people get banned (or probably better, shadowbanned/low priority queued) by player reports or weaker anti-cheat they can't easily ban evade. But of course then there is the issue of incentivizing identity theft.

      And I don't think giving a gaming company my PII is any better than giving them root on my machine. But that seems more like an implementation issue.

      3 replies →

    • There's a third path:

      3. No humans in your multiplayer

      As someone who grew up amazed at Reaper bot for Quake, I'm surprised we don't see a rennaisance of making 'multiplayer' fun by more expressive, fallible, unpredictable bots. We're in an AI bubble and I don't hear of anyone chasing the holy grail of believable 'AI' opponents.

      This also has the secondary benefit of having your multiplayer game remain enjoyable even when people's short attention spans move on to the next hot live service. Heck this could kill live service games.

      Then again, what people get out of multiplayer is, on some unspoken and sad level, making some other person hurt.

    • But isn't all client-side anti-cheat bypassable by doing image recognition on the rendered image? (either remote desktop or a hardware-based display cable proxy)

      3 replies →

  • Today, no. Very simplified but the broad goal of those tools is to prevent manipulation and monitoring of the in-process state of the game. Consoles and PCs require this to varying degrees by requiring a signed boot chain at minimum. Consoles require a fully signed chain for every program, so you can't deploy a hacking tool anyway; no anti-cheat is needed. PCs can run unsigned and signed programs -- so instead they require the kernel at minimum to be signed & trusted, and then you put the anti-cheat system inside it so it cannot be interfered with. If you do not do this then there is basically no way to actually trust any claim the computer makes about its state. For PCs, the problem is you have to basically trust the anti-cheat isn't a piece of shit and thus have to trust both Microsoft and also random corporations. Also PCs are generally insecure anyway at the hardware level due to a number of factors, so it only does so much.

    You could make a Linux distro with a signed boot chain and a kernel anti-cheat, then you'd mostly need to get developers on board with trusting that solution. Nobody is doing that today, even Valve.

    Funny enough, macOS of all things is maybe "best" theoretical platform for all this because it does not require you to trust anyone beyond Apple. All major macOS programs are signed by their developers, so macOS as an OS knows exactly where each program came from. macOS can also attest that it is running in secure mode, and it can run a process at user-mode level such that it can't be interfered with by another process. So you could enforce a policy like this: if Battlefield6.app is launched, it cannot be examined by any other process, but likewise it may run in a full sandbox. Next, Battlefield6.app needs to login online, so it can ask macOS to provide an attestation saying it is running on genuine Apple hardware in secure mode, and then it could submit that attestation to EA which can validate it as genuine. Then the program launch is trusted. This setup requires you to only trust Apple security and that macOS is functioning correctly, not EA or whatever nor does it require actual anti-cheat mechanisms.