The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

CrowdHaiku | jkcclemens' Blog

So, CrowdHaiku is a thing I discovered. I also quickly discovered that, with a few computers and a script, it is easily controllable. I even wrote a script to rig results and used six boxes at once to control the output. Here are some successes. Heres a partial failure. Heres how I did it.

When I found CrowdHaiku, I used it as intended. I upvoted the words I like and downvoted the ones I dont like. If I really didnt like the haiku, I could vote to restart it.

After an upvote, you cant upvote again until the leaderboard refreshes, but you can press the Refresh Leaderboard button to manually refresh and have the ability to upvote again. This sparked some curiosity on my part, so I opened Firefoxs network pane to investigate what requests were made on upvotes, downvotes, and word submits.

I found that /voting/vote and /voting/submit are both used. Knowing this, I rigged up a quick Python script to send requests for words I liked. However, there was some rate-limiting from the site. After trial and error, I discovered a optimal amount of requests to make before waiting a few seconds and sending another batch of requests.

This worked well enough with one computer. It manipulated the haiku, but it didnt completely rig them. I wanted to completely rig them. I opened up my dedi and VPS and got the scripts loaded on them. Using three machines significantly tipped the scales in my favor, but with enough effort, the people not cheating could downvote my chosen words or vote to restart the haiku. That wouldnt do.

I have a lot of DigitalOcean credit, so I threw together three droplets, made a git repo for the script, and cloned the repo on all of the machines. Using tmux and synchronize-panes, I was able to simultaneously start the script on all of the machines and completely control the haiku. I used four boxes to constantly upvote my chosen words and two boxes to constantly downvote the restart option.

This resulted in a site that was completely under my control, for the most part.

How the script works

The script is fairly simple. Theres a route on CrowdHaiku that gets information about a haiku, which the script checks to determine what word it needs to upvote.

I have a file with various haiku saved in it, which is loaded and fed to the script. The script then loops through each line and each word, determining the index and then checking that index on CrowdHaiku. If the index is missing, the script submits the appropriate word from the saved file and upvotes it until a word wins (hopefully the one the script is upvoting). The script prints out whether or not the word was successfully chosen and moves on to the next word. It does this for every word in the file.

How this could be prevented

Checking the browsers user agent and IP would go a long way. Im using the Python requests module, and Im not changing anything about the requests being sent.

Obviously, this could be easily circumvented, but it would be a start. The site already rate limits clients, but the rate-limiting is way, way too lax. I can execute three votes every two seconds across four boxes, which gives me twelve votes every two seconds.

If the site detects a bot consistently voting for one word, it should time the bot out. That would completely break my script. Timeouts for non-browser UAs should probably be more harsh than timeouts for browser UAs.

Until this is fixed, however, Ill continue having fun. The repo for the script is on GitHub, but it is private. If enough people want access, I can open it up. With great power, etc.

Continue reading on