Continuation of https://05command.wikidot.com/forum/t-16747557/discussion-public-statement-regarding-the-scp-8000-contest
Mirror: https://scp-wiki.wikidot.com/forum/t-16906096/discussion:contest-security
In our last discussion, we had a rousing exchange of ideas on how to best curtail the malicious voting endemic to Kcons and other major contests.
So far, most cases of large scale vote manipulation have been found in 6kon and 8kon, both of which were defined by how close the top articles were, where the winner was decided by the swing of only a dozen votes. Other than fundamentally changing how contests work, two things need to be considered — limiting the number of votes that count and making it harder for malicious voters to identify the top articles.
To this end, the Contest Team has been discussing things behind the scenes and we've come up with some ideas. This thread is to discuss those options
Vote Filtering
During the 8kon incident, the majority of users found to be involved in malicious voting were new accounts. The most non-intrusive solution to this would be to filter out these accounts using their join dates, but thanks to Wikidot, this is impossible to automate. Doing this manually would place an undue burden on the Contest Team, so other criteria must be used to determine what counts as a "new account".
Here are some ideas:
- Only people with X amount of votes on the site (-EN) should have their votes counted.
- What should this amount be?
- This is the most reasonable option, but trivial to circumvent for a dedicated user that knows about this rule.
- As such, this rule will not be on the contest page
- Only people with a page on the site should have their votes counted.
- An entry to the Kcon itself would count as a page.
- Only people who have joined the contest should have their votes counted.
We've also seen suggestions to close applications during the contest period, but we found this idea undesirable. It also doesn't stop anyone who just creates their sockpuppets earlier.
Vote Obfuscation
Most articles affected by vote manipulation are targeted for some reason related to placement, such as that the article is one of the front-runners or is about to overtake a favorite article of the brigader. It is reasonable, then, to implement measures that make it harder to rank articles.
Some inital ideas:
- Hide the vote count in the rating module via CSS.
- This is to be done with a special category that all contest pages will go into.
- This is really, really easy to circumvent.
- Ban leaderboards and other listpages.
- This can't be perfectly enforced. Working listpages can be created in the preview window of the page editor without needing to publish the page at all.
- Coordinate with the proprietors of CROM and ScpperDB to hide contest vote-counts on their end.
- Do note that the fiftynine is not the most responsive user.
Cumulatively, this should discourage the casual vote-manipulator from downvoting the top 5 entries and running away. It should be noted, however, that all of these solutions are imperfect, and thanks to Wikidot's unseemly infrastructure, there is no way to effectively hide an article's rating while still allowing users to vote.
The Nuclear Option: Project SCRAMBLE
The creation of automated bots with the intent of polluting article ratings by scrambling them. This is an aggressive vote obfuscation method that makes it extremely difficult to determine the rankings of contest entries.
Here's a brief overview of its implementation:
- Simple CSS measures are used to hide the ratings in articles.
- This is the front line of defense and is expected to be circumvented easily.
- The purpose of this is to communicate to users that they should not view the page ratings because they have been obfuscated, in addition to not discouraging authors for being signifcantly downvoted.
- A large amount of staff-controlled bots are created.
- Thanks to permissive account requirements, it is easy to mass create these accounts.
- The bots will use @scp-wiki.net email accounts to ensure staff control.
- To combat abuse, the bots should be clearly identifiable as staff-controlled accounts and listed in 05command.
- At the end of the posting period, or a few days after, the bots will vote automatically to scramble the rankings of every article. These votes will be recorded in a database.
- This database should be accessible to members of the Contest Team, the Tech Team, and Administrators.
- The database should clearly indicate what articles are being affected by the bots, what vote modifications are being applied, and what their true ratings are.
- The database should have a publicly viewable page listing affected articles.
- The database should indicate what articles are within the deletion threshold, accounting for their true rating. If an article is below -15 without the bots, all bot votes will be removed allowing for normal deletion.
- The system should have mechanisms in place to recall the bots and undo their votes in case of an emergency.
- Every day, the system will rescramble the rankings and the bots will vote accordingly.
- At the end of the contest, the bots will automatically undo their votes, leaving only the true ratings.
This is a "Have your cake and eat it" type solution that effectively addresses voting manipulation without drastically altering how the contest is run or how users interact with the articles. This has also been deemed viable by members of the Tech Team, so it's really a matter of how far we're willing to go to solve this issue.
It's a really annoying and ridiculous solution, I know, but with the way Wikidot is built, it can't be helped. Treat it like a last resort.
Other ideas
If you have any other options we haven't considered, we are all ears!
However, here are some solutions we have considered and will not be implementing:
- Closing applications during a Kcon.
- This is harmful to the site overall, as Kcons are one of the few events with enough visibility to attract new membership.
- Additionally, these types of contests are telegraphed so early that a particularly dedicated brigader can just make their sockpuppets before applications are closed.
- Anonymizing the entire contest.
- The staff team that handles anonymous articles has already rejected this idea.
- External voting/any type of voting not involving Wikidot's rating module.
- This is too disruptive to other wiki processes
Finally we can keep the current procedures, if these options are all too disruptive
This discussion will go one for one week