All of these are just my ideas, and none of them **proves** that a user is cheating, but I think they could help identify cheaters :D <br>↵
Also, I used AI to make my writing better because I'm not really good at English ):<br>↵
↵
Introduction↵
============↵
I think we all know that AI has kind of removed the "**competitive**" from competitive programming. With the increasing use of AI, a lot of users are using it to solve problems.<br>↵
I've been thinking about a possible cheating detection system on Codeforces. I call it a _cheating detection system_ rather than an _anti-cheat system_ because I don't think these methods can prove with 100% certainty that someone is cheating. They can only help identify suspicious behavior.<br>↵
These ideas are partly inspired by [Chess.com's](https://www.chess.com/home) cheating detection system.<br>↵
I'd also really like to hear your ideas, because mine are probably not perfect and these are just some examples!<br>↵
↵
1. A Report System↵
===================↵
The first thing I thought about was a report system. I think we all know that spotting obvious cheaters is usually pretty easy, and there are already a lot of users on Reddit and in Codeforces blogs who notice and discuss suspicious contestants.<br>↵
However, Codeforces doesn't seem to have a proper way for users to report them. Because of that, people usually end up making a blog post or a Reddit post about the suspected cheater instead of directly reporting them to Codeforces.<br>↵
With that being said, I think a report system could actually solve a lot of these problems. In my opinion, it would be one of the most effective ways to reduce cheating.<br>↵
If something from this blog were to actually be added to Codeforces, I think the report button would be the best place to start. The other ideas I'm going to talk about are useful too, but I don't think they are nearly as effective as this one.<br>↵
↵
↵
2. Behavioral Data↵
==================↵
The things I'm going to talk about won't identify someone as a cheater by themselves, but they could still be useful signals.<br>↵
↵
Copy↵
----------↵
Codeforces could track whether somebody copied the problem statement or not, since one possible reason for doing so is to paste it into an LLM.<br>↵
Now, there are some issues with this.<br>↵
A lot of users actually translate problems by simply copying the statement, so it wouldn't be very effective to use this data alone to identify cheaters.<br>↵
I've also seen people suggest that Codeforces should add a system to prevent users from copying problem statements, but I don't think that would be a good idea because:<br>↵
1. It would make it harder for users to translate problem statements.<br>↵
2. Cheaters could easily take a screenshot, OCR, or use a browser extension that disables the copy restriction. This would actually make it harder to track their copying behavior.<br>↵
Remember, we can never completely stop a cheater, but we can potentially identify less careful cheaters. If we prevent copying, we might lose useful behavioral data that could help identify them.<br>↵
↵
Mouse Behavior↵
--------------↵
Now this is actually not that important, but we could track a user's mouse movement.<br>↵
For example, if someone switches from Codeforces to their IDE using the taskbar, their mouse may move toward the taskbar. If instead we see their mouse moving toward the browser tabs, it could indicate that they are switching to another website.<br>↵
However, there are many problems with this idea. The taskbar and browser tabs might not even be where we expect them to be, and users can also switch windows with keyboard shortcuts, multiple monitors, or other methods. Also, some people use online IDEs in their browser.<br>↵
Some cheaters might also use an AI tool directly inside their IDE, while someone else might simply have another legitimate website open.<br>↵
So I don't think mouse behavior would be a very reliable signal by itself, but it could still be useful as **one small piece of behavioral data**.<br>↵
Still... it's an idea XD<br>↵
↵
3. Contest History and Performance↵
==================================↵
Now this is where the real thing begins!<br>↵
Codeforces already has a large amount of historical performance data for each user, so it could potentially be used to establish a baseline for their normal performance.<br>↵
Let's say a user's rank in contests is usually around 2000–3000, but in the next contest they suddenly jump to rank 100. This is suspicious!<br>↵
Or maybe a user usually takes around 5 minutes to solve problem A, but suddenly solves in 1 minute. Of course, the problem might simply have been easier for them, so this alone doesn't prove anything. However, after the contest, we can estimate the difficulty of each problem based on how other contestants performed and see whether it was actually easy or not.<br>↵
We could also look at more than just rank. For example, we could track things like solve times, problem difficulty, submission patterns (for example, a user usually gets a lot of WAs but suddenly solves every problem on the first try), and how a user's performance changes over time.<br>↵
Another interesting thing we could do is compare a user with other users who have a similar rating and similar historical behavior.<br>↵
For example, if a user's performance suddenly becomes very different from both their own history and the typical behavior of users at a similar level, that could make the case more suspicious.<br>↵
Again, none of this proves that someone is cheating, but I think this kind of historical data could be one of the more useful signals for a cheating detection system.<br>↵
↵
4. Changes in Coding Style↵
==================================↵
Another potentially useful signal is a contestant's coding style.<br>↵
Most experienced competitive programmers develop relatively consistent habits: variable naming, formatting, function structure, template usage, preferred algorithms, and so on.<br>↵
Of course, this is not enough to consider someone a cheater, because a user's coding style can change over time. They might start using a different template, learn a new programming style, or simply decide to write their code differently.<br>↵
AI-generated code can also have some recognizable patterns, but I don't think trying to detect whether a piece of code "looks like AI code" would be very useful. A user can simply edit the generated code or tell the AI to use a different coding style. Also, some people's natural coding style might already be very similar to what AI generates.<br>↵
Instead, I think it would be more useful to compare a user's current code with their previous submissions.<br>↵
↵
5. Combining the Signals↵
========================↵
And now, the most important part: combining all of them.<br>↵
Now we have a lot of data about a user, but how do we actually combine it?<br>↵
I think we could use something like a **risk score**. Whenever something suspicious happens, the user's risk score increases. Different signals could have different weights depending on how suspicious they are.<br>↵
For example, a sudden change in coding style might increase the score by a small amount, while a combination of unusual solve times and a huge performance jump could increase it much more.<br>↵
Then, if the risk score passes a certain level, the account could be sent to a moderator for further investigation.<br>↵
The important part is that reaching the level should **not automatically mean a ban**. It should simply mean that the account is suspicious enough to deserve a closer look from a human.<br>↵
↵
Conclusion↵
==========↵
First of all, thanks for reading! I've had this idea in my mind for a long time, and I finally decided to post it.<br>↵
If you guys have any other ideas, I'd really appreciate it if you shared them. I might add them to the blog too :D<br>↵
I don't think any of these signals should independently be used to punish someone. There will always be legitimate explanations for unusual behavior.<br>↵
Instead, I think these signals could be used together to identify cases that are worth investigating.
Also, I used AI to make my writing better because I'm not really good at English ):<br>↵
↵
Introduction↵
============↵
I think we all know that AI has kind of removed the "*
I've been thinking about a possible cheating detection system on Codeforces. I call it a _cheating detection system_ rather than an _anti-cheat system_ because I don't think these methods can prove with 100% certainty that someone is cheating. They can only help identify suspicious behavior.<br>↵
These ideas are partly inspired by [Chess.com's](https://www.chess.com/home) cheating detection system.<br>↵
I'd also really like to hear your ideas, because mine are probably not perfect and these are just some examples!<br>↵
↵
1. A Report System↵
===================↵
The first thing I thought about was a report system. I think we all know that spotting obvious cheaters is usually pretty easy, and there are already a lot of users on Reddit and in Codeforces blogs who notice and discuss suspicious contestants.<br>↵
However, Codeforces doesn't seem to have a proper way for users to report them. Because of that, people usually end up making a blog post or a Reddit post about the suspected cheater instead of directly reporting them to Codeforces.<br>↵
With that being said, I think a report system could actually solve a lot of these problems. In my opinion, it would be one of the most effective ways to reduce cheating.<br>↵
If something from this blog were to actually be added to Codeforces, I think the report button would be the best place to start. The other ideas I'm going to talk about are useful too, but I don't think they are nearly as effective as this one.<br>↵
↵
↵
2. Behavioral Data↵
==================↵
The things I'm going to talk about won't identify someone as a cheater by themselves, but they could still be useful signals.<br>↵
↵
Copy↵
----------↵
Codeforces could track whether somebody copied the problem statement or not, since one possible reason for doing so is to paste it into an LLM.<br>↵
Now, there are some issues with this.<br>↵
A lot of users actually translate problems by simply copying the statement, so it wouldn't be very effective to use this data alone to identify cheaters.<br>↵
I've also seen people suggest that Codeforces should add a system to prevent users from copying problem statements, but I don't think that would be a good idea because:<br>↵
1. It would make it harder for users to translate problem statements.<br>↵
2. Cheaters could easily take a screenshot, OCR, or use a browser extension that disables the copy restriction. This would actually make it harder to track their copying behavior.<br>↵
Remember, we can never completely stop a cheater, but we can potentially identify less careful cheaters. If we prevent copying, we might lose useful behavioral data that could help identify them.<br>↵
↵
Mouse Behavior↵
--------------↵
Now this is actually not that important, but we could track a user's mouse movement.<br>↵
For example, if someone switches from Codeforces to their IDE using the taskbar, their mouse may move toward the taskbar. If instead we see their mouse moving toward the browser tabs, it could indicate that they are switching to another website.<br>↵
However, there are many problems with this idea. The taskbar and browser tabs might not even be where we expect them to be, and users can also switch windows with keyboard shortcuts, multiple monitors, or other methods. Also, some people use online IDEs in their browser.<br>↵
Some cheaters might also use an AI tool directly inside their IDE, while someone else might simply have another legitimate website open.<br>↵
So I don't think mouse behavior would be a very reliable signal by itself, but it could still be useful as **one small piece of behavioral data**.<br>↵
Still... it's an idea XD<br>↵
↵
3. Contest History and Performance↵
==================================↵
Now this is where the real thing begins!<br>↵
Codeforces already has a large amount of historical performance data for each user, so it could potentially be used to establish a baseline for their normal performance.<br>↵
Let's say a user's rank in contests is usually around 2000–3000, but in the next contest they suddenly jump to rank 100. This is suspicious!<br>↵
Or maybe a user usually takes around 5 minutes to solve problem A, but suddenly solves in 1 minute. Of course, the problem might simply have been easier for them, so this alone doesn't prove anything. However, after the contest, we can estimate the difficulty of each problem based on how other contestants performed and see whether it was actually easy or not.<br>↵
We could also look at more than just rank. For example, we could track things like solve times, problem difficulty, submission patterns (for example, a user usually gets a lot of WAs but suddenly solves every problem on the first try), and how a user's performance changes over time.<br>↵
Another interesting thing we could do is compare a user with other users who have a similar rating and similar historical behavior.<br>↵
For example, if a user's performance suddenly becomes very different from both their own history and the typical behavior of users at a similar level, that could make the case more suspicious.<br>↵
Again, none of this proves that someone is cheating, but I think this kind of historical data could be one of the more useful signals for a cheating detection system.<br>↵
↵
4. Changes in Coding Style↵
==================================↵
Another potentially useful signal is a contestant's coding style.<br>↵
Most experienced competitive programmers develop relatively consistent habits: variable naming, formatting, function structure, template usage, preferred algorithms, and so on.<br>↵
Of course, this is not enough to consider someone a cheater, because a user's coding style can change over time. They might start using a different template, learn a new programming style, or simply decide to write their code differently.<br>↵
AI-generated code can also have some recognizable patterns, but I don't think trying to detect whether a piece of code "looks like AI code" would be very useful. A user can simply edit the generated code or tell the AI to use a different coding style. Also, some people's natural coding style might already be very similar to what AI generates.<br>↵
Instead, I think it would be more useful to compare a user's current code with their previous submissions.<br>↵
↵
5. Combining the Signals↵
========================↵
And now, the most important part: combining all of them.<br>↵
Now we have a lot of data about a user, but how do we actually combine it?<br>↵
I think we could use something like a **risk score**. Whenever something suspicious happens, the user's risk score increases. Different signals could have different weights depending on how suspicious they are.<br>↵
For example, a sudden change in coding style might increase the score by a small amount, while a combination of unusual solve times and a huge performance jump could increase it much more.<br>↵
Then, if the risk score passes a certain level, the account could be sent to a moderator for further investigation.<br>↵
The important part is that reaching the level should **not automatically mean a ban**. It should simply mean that the account is suspicious enough to deserve a closer look from a human.<br>↵
↵
Conclusion↵
==========↵
First of all, thanks for reading! I've had this idea in my mind for a long time, and I finally decided to post it.<br>↵
If you guys have any other ideas, I'd really appreciate it if you shared them. I might add them to the blog too :D<br>↵
I don't think any of these signals should independently be used to punish someone. There will always be legitimate explanations for unusual behavior.<br>↵
Instead, I think these signals could be used together to identify cases that are worth investigating.
