> The issue of anti-cheat on Linux

Is the memory of this kernel module protected from access from another kernel module ?

That's why anticheats demand they are loaded first, and then intercept the loading of later drivers.

Which obviously causes all kinds of issues, and violates both freedoms 0 and 1 https://www.gnu.org/philosophy/free-sw.en.html

And they don't just remove those freedoms regarding the game, but for the entire system.

▲

cyberax 5 days ago | parent [-]

> Which obviously causes all kinds of issues, and violates both freedoms 0 and 1 https://www.gnu.org/philosophy/free-sw.en.html

They do not, as long as you can disable the anti-cheat and reboot.

▲

kuschku 5 days ago | parent [-]

The core freedoms are about allowing anyone to run, inspect, understand and modify software.

Even if the game itself doesn't grant me that freedom, my OS and drivers should not prevent me from attaching a debugger to the game without it noticing.

My computer, and the software on it, should obey me, and me alone. Never should they obey a developer's desire to restrict what I can and cannot do.

That is the ideological basis of the free software movement, and as you may have noticed, incompatible with client side anticheat.

▲

pabs3 4 days ago | parent [-]

The proprietary software you run on top of your Free Software OS doesn't have to respect your freedom to modify though, it can break itself when you aren't using known versions, or when you attach debuggers, or when you are running an OS that allows undetectable debuggers.

▲

kuschku 4 days ago | parent [-]

The userland software, sure. But all kernel modules and drivers need to obey my freedoms for me to be able to ever trust the system again.

I'd end up in court if I gave a random game developer root permissions on the same system that I use for client projects. But installing a kernel module is fine?

If the valorant module wanted, it could intercept anything from that point on. It could intercept me trying to uninstall it, and pretend it had been removed, while just hiding itself. It could intercept any debugging I'd be trying to do, and feed me false data.

That's why I don't use proprietary kernel modules, and never run proprietary code with root permissions.

And I shouldn't have to. Games don't need client side anticheat.

Why do even many single player games now ship with anti-cheat? Because they want to protect their lootboxes and microtransactions.

And even competitive games don't need client side anti-cheat. Most games are perfectly fine with a well-written server-side anticheat, and the ones that don't work fine if you host a private server with people you know.

No other part of IT would ever trust the client. Giving the client information they shouldn't have is an instant CVE, and so is relying on client-side validation.

But client-side anticheat is cheaper, and matchmaking increases engagement, so alternatives are dismissed.

I don't want to play with randoms. Even in mmorpgs I prefer finding a group via the zone chat, which also encourages finding a guild and making friendships, over playing with randoms. Especially if the matchmaking doesn't even take party roles into account.

So why should I break my clients' trust to give control of my system to someone I don't know to install software I don't want just so I can play a game with matchmaking just because the developer didn't want to pay for proper server-side anticheat?

	▲	pabs3 3 days ago \| parent [-]
		Personally, I only ever play FOSS games, they are more freedom and privacy respecting. Is that an option for you?