[Feature request] Some way to distinguish "cheaters" and legit players using Proton.

Feature Request

I confirm:

• that I haven't found another request for this feature.
• that I have checked whether there are updates for my system available that
  contain this feature already.

Description

Some way to prove to the automatic anti-cheat systems that Proton is not being used to cheat.

Or some kind of whitelist for Proton, so that the simple fact of using Proton is not enough to get you flagged as cheater.

Justification

The problem is that, currently, using any kind of emulation/compatibility layer can lead to getting hard-banned or soft banned. This leaves legit players out in the cold, they are not cheating, but might lose access to playing a game entirely (hard-ban), or are only allowed to play with other people labeled as cheaters (soft-ban).

Many online games have some kind of cheat-detection system, which triggers when using Proton/Wine/DXVK etc. So this problem is not in any way exclusive to Proton itself.

Enabling Linux users to safely play online without fear of getting banned will, I think, be helpful to improving Linux user-base on Steam. But how much the user-base would increase, I don't know.

Possible routes to getting a solution:

Now I have given this some thought, and have come up with two solutions.

First way:

Somehow convince stakeholders (game-developers/anti-cheat makers/publishers/moderators) to whitelist Proton use. Really simplified:

Honestly, our users are nice people, and they won't abuse Proton to cheat. So can you whitelist us?

This appeal, I think, has limited believably and sustainability.
There will always be trolls, cheaters, etc. who will abuse Proton to cheat.
Let's assume that the Proton whitelist will be granted, that the appeal works; people will still find a way to cheat. The well will be poisoned by those users, and we're back to square one: Proton users are banned on sight.

Way the second:

Implement some kind of technical proof that Proton is not used to cheat.

Maybe something like GPG-keys and SHA256SUMS can be used to prove that the Proton install is legit and wasn't tampered with. However we will also need to prove during run-time that nothing is hooking into Proton to cheat. This will likely prove to be a hard problem to solve.

The end-game here would probably be developing new anti-cheat measures for Proton or implementing existing anti-cheat solutions (such as Steam's VAC system) into Proton. I have a feeling that both of those will be out-of-scope for the Proton development team.

Risks

• It might be impossible/really hard to distinguish between legit Proton usage and cheating with Proton.
• It might cost too much time/effort/money to get this fixed.
• Ongoing support in the form of patching the system might cost to much money/time/effort too, whatever is implemented will surely get "hacked" by people looking to troll...
• Reputation damage Valve/Proton: either solution will place trust in Valve/Proton, if people still cheat after Valve's/Proton's guarantee, this might reflect negatively on the reputation of Valve/Proton, and affect the ability to do business with stakeholders in future.
• The opportunity cost for this feature request might be too high, in that it's a better return on investment to focus on other things for now, that have a bigger impact on Linux market-share.

References

This issue affects games which are wholly online or have online components and use some form of anti-cheat system.

I've linked issues for games which seem to be affected by not having EAC, or other forms of anti-cheat integrated into Proton.

Conclusion

I'm fully aware that solving this problem might be out-of-scope for the Proton team itself.
Any solution will also require buy-in from others, and this might cost a lot of time/effort/money.

No files, tests, or entry points are identified. Start by reviewing the referenced game and anti-cheat issues, then determine whether a Proton whitelist or technical proof can be defined within the Proton team's scope, including stakeholder support and runtime tamper concerns.