In response to the emotional discussion an our message board, i will give a review of the current state of cheating research (Thx for your hints). We want to keep this site free and just for fun. There will always be some poor guys unable to handle this freedom. I want to avoid obstruction of docile tacticians by counteractive measures. My strategy includes calmness and (from today) transparency but not confrontation. Detecting and exposing may be a good defense.

There are four main lines of cheating.

Multiple Registration

Use the high initial RD to get a high rating and stop as soon as RD < 100 and you are regarded as active. This is not a real cheat. Enjoing to be in top ten this way is rather infantile than malicious. As a simple solution it may be required to have at least 100 tries to be listed in top ten. The proposed non-free email account restriction known from FICS will obstruct innocent tacticians. This will not be a hurdle for those multiple personalities.

Time Cheats

Currently the chronometry is client-sided.
  • A simple but inconvenient cheat is to turn back your system clock just before executing the solution move (found by Fritz or hours of analysis).
  • Smarter cheaters (is this an oxymoron ?) inject a manipulated javascript via a URL-rewriting proxy server.
The only defense against this cheat is server-sided chronometry. The disadvantage of this approach are inequities caused by different network latencies. If you know some smart protocols to avoid this - please tell me! I will implement an additional server-sided time measurement to detect time cheats as soon as possible.

Solution Cheats

The solutions are given in plain text as javascript parameters in each problem document.
  • A simple cheat is to use the show page source feature of your browser and translate the coordinates to corresponding moves. A possible defense is obfuscating the javascript code for humans.
  • Another very simple cheat is to use the solution page of CTS itself. The fix is blocking the solution page of pending problems.
  • Injecting a javascript displaying the correct move is again a more sophisticated cheat. Because there is no way to protect javascript code against reverse egineering, the only defense is keeping the solution server-sided. This will cause additional network activity and requires a more eleborate implementation. (e.g. AJAX)
  • Build an HTTP-client with an embedded chess module (Crafty) or a Winboard interface. A way to detect this is the reverse Turing test a.k.a. CAPTCHA.

Protocol Cheats

Unfortunally there is a zero-chess cheat. Build an HTTP-client parsing the problem's ID from the resource and calling the rating request directly claiming success. This can be hampered by integrating the solution to the rating request. You can also do this manually (for the correct syntax of the request see our message board). Of course a Proxy Server is again more convenient for this.

According to te logfiles ChapoDeZozo(THX for publishing) is not the first one, who has detected this. Unfortunally there is no way to inhibit this as long as the results are recorded client-sided. It can be complicated e.g. by some hash functions in javascript, but this is error prone and time consumptive. Maybe detecting is better than preventing.