Steam games will need to disclose kernel-level anti-cheat on store pages

Original Article ↗ Hacker News Discussion ↗

Steam will soon require games to clearly disclose any kernel-level anti-cheat on their store pages, sharpening a long-running conflict between competitive integrity and user control over their own systems. Commenters argue that such anti-cheat behaves like a rootkit, expands the attack surface (as seen in incidents like Genshin Impact’s driver abuse and the CrowdStrike outage), and effectively excludes Linux and Steam Deck users, leading some to isolate gaming on separate machines or avoid affected titles entirely. Others counter that, for large competitive multiplayer games with ranking and monetization, server-side checks and softer measures have proven insufficient, making invasive client-side anti-cheat a “necessary evil” in what many see as an unwinnable arms race with cheaters.

Reactions to Steam’s New Disclosure Rule

  • Widely welcomed as overdue transparency; many players refuse to install kernel-level anti‑cheat and want to know up front.
  • Some think the warning will barely affect sales because most gamers prioritize a “cheat‑free” experience over security concerns.
  • Others expect it to stigmatize games using such systems, much like “always‑online DRM” labels.

Kernel-Level Anti‑Cheat = Rootkit Debate

  • Many call these drivers “rootkits” or “first‑party malware”: closed, ring‑0 code with full system access, historically abused (e.g., Genshin, ESEA Bitcoin mining, GTA V update).
  • A minority argue “rootkit” is technically wrong or alarmist: these are installed with user consent and typically expose narrow APIs.
  • Several point out that Microsoft’s signing/audits are weak; CrowdStrike and other bad drivers passed.

Effectiveness and the Cheating Arms Race

  • Pro‑KLA side: for fast competitive FPS, server‑only and user‑mode anti‑cheat are insufficient; kernel access is needed to detect kernel‑level cheats and most obvious aimbots/ESP.
  • Critics: cheating remains rampant (CS, Valorant), while legitimate users bear the risk; KLA mainly stops low‑effort cheats and drives serious cheaters to:
    • External hardware (PCIe/DMA cards, HDMI overlays, USB input emulators).
    • AI/computer‑vision aimbots running off‑machine.
  • Several note that subtle cheats tuned to “look human” are extremely hard to detect statistically.

Server‑Side, Community, and Alternative Approaches

  • Advocates for server‑side focus: authoritative servers, relevance filtering (not sending unseen state), statistical/ML detection, plus social tools (reports, trust scores, community banning).
  • Others counter that:
    • Latency and prediction make some client trust unavoidable.
    • Elite players are natural statistical outliers, making automated bans risky.
  • Nostalgia for community‑run dedicated servers with admins and votekicks, but recognition that:
    • This doesn’t scale to modern F2P, global matchmaking.
    • It offloads unpaid moderation labor and can be abusive/unreliable.

Security, Privacy, and Platform Choices

  • Strong concern that game rootkits increase attack surface for worms and targeted attacks (SolarWinds‑style), especially on developer machines with credentials and password vaults.
  • Many mitigate by:
    • Using a separate gaming PC or Steam Deck, often air‑gapped from “real life” work/accounts.
    • Avoiding KLA titles entirely (notably on Linux/Proton) and accepting fewer playable games.
  • Consoles are seen as the “locked‑down” alternative: less visible cheating, but the “rootkit” is effectively the platform itself.

Linux, Proton, and Ecosystem Impact

  • Kernel‑level anti‑cheat for Windows often means the game is effectively unreachable on Linux/Steam Deck; Proton can’t emulate Windows kernel drivers.
  • Some Linux users argue EAC’s user‑mode support proves KLA isn’t strictly necessary; others note Linux EAC is weaker and heavily targeted by cheats when enabled.
  • Valve’s interests (Steam Deck, Linux) likely motivate pushing disclosure and possibly kernel‑provided anti‑cheat APIs instead of third‑party drivers, though feasibility is debated.

Business Models, Incentives, and DRM

  • Many connect aggressive anti‑cheat to:
    • High‑stakes esports and ranked ladders.
    • Microtransactions and in‑game currencies whose value depends on perceived fairness.
  • Comparison to DRM:
    • DRM helps launch‑window revenue; anti‑cheat actively improves paying players’ experience.
    • A cited pro‑Denuvo study (funded by its vendor) is viewed skeptically; performance impact remains contested.
  • Some argue the industry chose centralized matchmaking and “games as a service” for monetization control, which then necessitated invasive anti‑cheat; community servers plus box‑price games would need less of this.

Radical and Experimental Ideas

  • One project proposes an extreme model:
    • Boot a custom Linux ISO (“reboot‑to‑play”) so the game controls the entire OS.
    • Strict hardware configs and “handcam” recordings for ranked play to prove human input.
  • Many see this as unplayably intrusive; others treat it as a thought experiment showing how far you’d have to go to make cheating truly hard.

Value Judgments and Unresolved Tensions

  • One camp: kernel‑level anti‑cheat is a “necessary evil” for certain genres; avoid those games if you dislike it.
  • The other: user autonomy and device security trump any game’s business model; if a genre can’t exist without rootkits, it should change or die.
  • Broad agreement that:
    • There is no perfect technical solution.
    • This is ultimately a human and economic problem as much as a technical one.