The weekend before Memorial Day was an interesting one.
The TL;DR version:
- A user was banned permanently for running an automated script against the site, faving the universe & more.
- That kind of mass-faving just to draw attention to themselves provides zero value to the community and causes issues on the site.
- To curb that behaviour, faving was put under the guard of the same anti-spam filter used throughout the site.
For a more detailed rundown of what happened, including information about the filtering that was implemented, you’ll have to read through the post. Site issues
At around 6am PST on Sunday, the dT team discovered an increasing amount of database issues affecting one of our servers which stores deviant data (deviations, favourites). On deviantART, all of the user-generated data is spread evenly across a number of servers, so seeing only one of them affected by unusually high load to the point of causing issues raised some eyebrows, especially considering 6am on a Sunday is usually a calm period.
Looking into that specific server, it was immediately noticed that sporadic issues started happening around 1am, reached a steady rate of 20 issues per second at 2am and have been steadily rising by another 20 per second with every hour. By 6am it had reached 100 issues per second.
One hundred issues per second directly translates to 100 failed page views per second. Not good.
The activity log for the problematic server revealed a long list of seemingly identical queries all related to a single deviant, piling on at a rate that could not have been caused by regular use of deviantART, no matter how quick you are with the mouse. The activity? Faving of what seemed to be damn near everything in sight.
The rate at which these requests were coming in told us without a doubt this was not a human-generated activity but a script or a bot running against deviantART, impersonating a deviant. Since affecting the site’s stability, especially in this way, is explicitly against our Terms of Service, the deviant generating these requests was banned, after which the issues immediately subsided and remained at a flat 0 for the remainder of the morning, as can be seen in the following image.
The banned deviant had accumulated almost half a million favourites in the short 2 months they have been a member, which comes out to an average of one fave every 10 seconds for 24 hours a day, every day since they’ve joined. This is not a rate a human being could sustain.Introducing the velocity filter on Faving
Favouriting deviations was one of the last remaining user actions on deviantART that had no anti-spam measures implemented because, unlike commenting on deviations and deviant profiles, and posting in forums, it gives a very limited exposure to the person doing it, making it very difficult to find motivation to abuse it. Even our own realitysquared
recently made a Journal in which he explained that there’s no such thing as “abusing Faves” or giving out too many, and asking deviants to stop reporting instances of that behaviour to helpdesk.
After the incident described above and after looking into the amounts of faves other deviants have accumulated, it was decided a limit should exist, but be set sufficiently high, so that no normal user could trigger it. To accomplish this, a velocity filter - the same mechanism already in place all over the website - was to be implemented for faving. The limits were adjusted for faving to be much more forgiving than for other activity, taking into account the reduced visibility of faves and the fact that it’s legitimately possible to hand out dozens in the time it takes to write a single comment. Our intention was to curb scripted mass-faving (or “favbombing” as the community has come to call it), while allowing near-unlimited faving by genuine deviants, within reason.
At around 4pm the same day, the velocity filter was implemented and the first reports from users hitting the limits started coming in. The limits were obviously set too low, and the affected users were very vocal about it. Taking that feedback, another round of discussion was had and the conclusion was to increase the limits to a value high enough that it would be theoretically impossible to hit even during a faving frenzy. After the changes were implemented, only a handful new complaints were registered, all from deviants with unusually high amounts of faves.
The weekend following the incident, almost a week after the initial rollout, we gathered some stats for this blog post, to give us a view of how many deviants were still hitting the limits. The stats were gathered from Friday night to Tuesday morning, and the velocity filter was hit a total of 30,900 times by 500 unique users. Of that, over 40% of the hits were produced by just 10 deviants, with one deviant in particular being responsible for 10% of the hits that weekend. The user was attempting to favourite at 300 times a minute (or 5 times a second) for several hours. The numbers here indicate the number of times a faving action was denied, once the user has reached the limit and continued trying to fave.
We are still seeing the occasional favbomb run; for example on Tuesday the 7th we saw a noticeable spike in velocity filter activity, caused by one or more deviants hitting the limits 8 times per second, as shown in the image below.
Since that unusual spike subsided, we’re seeing an average of fewer than 1 fave in 5 seconds being rejected, with obvious attempts at favbombing cropping up here and there and quickly giving up.How much is too much?
It’s important to note that the velocity filter, which as mentioned is the same mechanism providing one of many anti-spam measures to all of dA including comments, devwatch and notes, is not a single number or a “this many in this much time” thing. It’s a special sauce that includes some fancy maths, cooked up by dT’s smartest. Because of this, there is no single answer to the question that will surely come up - “how many faves can I give out?”. There’s still no limit to the absolute number of faves a user can give out and we’re not looking to change that.
The limits are meant to prevent server issues like the ones we experienced on Memorial Day weekend, but also to stop users from using faving purely as a method of drawing attention to themselves at a massive scale while providing zero value to the rest of the community. We hope you’ll agree these changes are for the good of everyone on the site.