Trenches Labs: How #TwitterGulag Works Part 3 – Report Someone For SPAM 100s Of Times
In our prior two posts on How TwitterGulag Works we covered Reply Traps as well as how to see Blocks accumulate in real time.
Together, these articles show that there is some degree of sophistication in the Twitter SPAM algorithms. That degree of sophistication carries an assumption – that any account can only issue a “Block” or ”Block and Report for SPAM” against another account once. So if you have your account @Jane and you want to Block and Report @Tarzan for SPAM you can only do it once. If you carry that assumption, then you infer from hearing about “100 Blocks” against @Tarzan that 100 different people sent them.
Maybe you are experienced enough as a Social Media user to recognize that many activists have multiple accounts. So you modify your inference – you figure that 100 Blocks against @Tarzan could plausibly have come from 20 different activists with 5 accounts each.
But what if you could issue multiple blocks from your account against a single account? What if @Jane can simply keep hitting the “Block & Report For SPAM” button or the “Block” button and hit @Tarzan with 100 Blocks all by herself? Well if she is using the old TweetDeck desktop client or the Android Twitter Client (not TweetDeck Android, oddly enough) or a handful of other Twitter client applications, @Jane can blast away at @Tarzan until the blocks stick and he goes to Twitter Gulag.
When We Got This Tip We Discovered Where The Problem Is : The API
When we got the tip on the TweetDeck client we found an old machine with it, fired it up and confirmed the ability to keep hitting the “Block” buttons. But we wondered: “Is this an issue with TweetDeck or with the Twitter API?” Now before we go much further, the term “API” should be explained. API (ay – pee – eye) stands for Application Programming Interface. In the case of Twitter, you can think of the API being a set of commands that can be sent to Twitter’s servers. Different commands will have the servers do different things. The application sending these commands has to establish a secure connection with Twitter and submit security credentials with just about each request using a standard called “OAuth.” When you submit a command Twitter acts on it and replies with a code generally indicating success or failure. Want to add a follower? There is a command for that, and a response code for success, one for failure (maybe that user is blocking you).
To test the API, we found an Open Source Twitter Client and we modified it. ”Open Source” software is software that comes with the source code that anyone is free to modify. So we cracked open the code, found the line of code that submits the Block & Report For Spam and we modified the section of code around it. First – we made it so the “Report” button that the user hits stays active after it has been used once. Then we decided to get rid of the “Are you sure” popup that makes submitting 100 Blocks a drag.
We the tested and saw that the API accepts multiple Blocks as well as multiple SPAM reports against the same user from the same user. Here is an extract from a log we created in testing (out of courtesy to Twitter we redacted the OAuth security items and the “source” so that it is harder for someone to forge what we did). The “[Req]” is the part our code submitted and the “[Streams XHR]” is the response from Twitter.
[Req] {“type”:”POST”,”url”:”https://api.twitter.com/1/report_spam.json”,”data”:”follow=true&oauth_consumer_key=[redacted]&oauth_nonce=[redacted]&oauth_signature=[redacted]&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1343409515&oauth_token=[redacted]&oauth_version=1.0&screen_name=KelseyBrewer7&source=[redacted]“}
[Streams XHR] readyState: 3, status: 200, responseText.length: 55285, times: 2, createAt: July 27, 2012 10:17:36 AM PDT
[Req] {“type”:”POST”,”url”:”https://api.twitter.com/1/report_spam.json”,”data”:”follow=true&oauth_consumer_key=[redacted]&oauth_nonce=[redacted]&oauth_signature=[redacted]&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1343409515&oauth_token=[redacted]&oauth_version=1.0&screen_name=KelseyBrewer7&source=[redacted]“}
[Streams XHR] readyState: 3, status: 200, responseText.length: 55285, times: 2, createAt: July 27, 2012 10:17:36 AM PDT
[Req] {“type”:”POST”,”url”:”https://api.twitter.com/1/report_spam.json”,”data”:”follow=true&oauth_consumer_key=[redacted]&oauth_nonce=[redacted]&oauth_signature=[redacted]&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1343410056&oauth_token=[redacted]&oauth_version=1.0&screen_name=KelseyBrewer7&source=[redacted]“}
[Streams XHR] readyState: 3, status: 200, responseText.length: 21526, times: 1, createAt: July 27, 2012 10:27:00 AM PDT
With the API bug confirmed, we modified the code one more time. We had it submit 5 SPAM reports at a time, each a few seconds apart. The result?
10 …
5 …
0 …
(and if you are wondering how an account with 1 follower can register in Twitter’s servers as having 10, that’s because the SPAM community has found another bug that lets them “pad” their accounts.)
This is a bug. Big time. This bug offers any “hacktivist” the ability from a single account to “hose down” an enemy on Twitter with Blocks and Block And Report For SPAM. Fixing the client applications to hide the “Block” and “Report” buttons after either is used won’t work – “hacktivists” roll their own code. And “blacklisting” such accounts (not that we have ever heard of anyone being suspended or blacklisted for abusing the Report For SPAM feature) will simply cause them to request from Twitter new OAuth credentials with forged information and start again via a new proxied IP address. Just like SPAMmers do.
A whopping 5 minute delay for mass speech suppression.
We are happy to report that the bug we identified yesterday was rapidly attended to. You can no longer see blocks accumulating on an account using the method we described yesterday. Plugging that bug “raises the cost” of reverse engineering Twitter’s SPAM algorithms. Sadly a great many have already been reverse engineered and are employed daily to send people to TwitterGulag as we have already shown.
This bug is far more damaging to Twitter and the integrity of their platform. It is being abused and is now no longer a dirty secret. Because of this bug, whatever subtlety exists in the SPAM algorithms at Twitter stands no chance of being relevant under a barrage of Reports coming in on an account. If @Jane wants to take down @Tarzan she should have to either get a bunch or friends to help her or leave the signature in the Twitter logs of someone controlling multiple sock accounts directed at the same effort which is a TOS violation.
Building a Twitter Nuke
Now with that put in place, we realized it would not take a lot of effort to do a few things:
- modify the button that says “Block & Report” to say “Suspend” and then write a script for that button to launch
- have the suspend script analyze the “birth date” of the account, the follower count, the following count, the last 20 tweets and determine the best way to suspend the account
- proceed to schedule the blocks and the reports and have the different twitter accounts submit theme – choreographed to take advantage of the selected SPAM algorithm
That would be pretty powerful stuff. What if there were a funded Progressive effort to do just that?
Stay tuned …









Pingback: Twitter Gulag Part 4 – the 5G Era and Twitter Nukes | The Trenches
Pingback: Trenches Labs : How #TwitterGulag Works Part 1 – Setting Reply Traps | The Trenches