What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 129 Stack Exchange communities.

I know we already have a fraud-detection script that removes serial downvotes (and maybe serial upvotes). This script is a temporal script; it is based on a number of votes occurring against a particular user during a short time period (probably 24 hours). It does not address at all the problem of routine upvoting on a regular basis by a sockpuppet.

Sockpuppets that are created for the sole purpose of upvoting a user's main account are easy to identify; they generally have less than 10 posts, and large percentage of their votes are cast against the main account.

Things get more muddy if the sock has several posts and hundreds of rep. Is this a sock, a coworker engaged in ring voting, or just an ardent fan? There are several steps a moderator can take to determine if a sock is really a true sock, but it's always a judgment call.

The only remedy a moderator has for dealing with this kind of cross-voting is to merge accounts, and that can be risky (and unfair) if the sock turns out to be someone else's account. My understanding is that account merges can be undone by SE developers, but it's a time-consuming and difficult process.

So I'd like to propose an algorithm that limits the percentage of upvotes any single account can make to any one user. I believe this would severely limit users' ability to use sock puppets to enrich their own accounts, but would not affect at all even the most ardent of fanboys (users who cast large numbers of upvotes at certain high-rep users).

I don't know exactly what this algorithm looks like yet, but I believe that a good starting point would be that no more than 50% of any one user's total votes could be cast towards a single person. With a little fine-tuning, I think you could even detect voting rings this way.

share|improve this question
6  
If this is to be implemented it probably needs to be excepted below some floor in votes (i.e. not apply until 10 votes have been cast). –  dmckee Dec 22 '11 at 19:45
1  
@dmckee: That sounds reasonable. –  Robert Harvey Dec 22 '11 at 19:46
3  
I wonder if this would have a negative effect on very early beta sites. It should probably not be implemented until a site is established to a certain degree. Just something to consider. –  David Dec 22 '11 at 19:51
5  
@David: It may just be a StackOverflow thing (possibly SuperUser). It's a "big city" problem. –  Robert Harvey Dec 22 '11 at 19:53
    
@RobertHarvey: Agreed, and I definitely like the idea. Once developed, I'd be curious to see the numbers from the smaller towns and hamlets as well, though. –  David Dec 22 '11 at 19:54
1  
Don't fanboys cast large numbers of upvotes at certain high-rep users, or was that sarcasm? –  Chris Frederick Dec 22 '11 at 20:03
5  
Won't this make it easier for a sock puppet to cast the maximum upvotes allowed without having to worry that they will go over the limit and even kick in the fraud detection mechanism? –  Martin Smith Dec 22 '11 at 20:31
    
@Martin: Are you asking if this might foil the voter fraud detection script? Perhaps, under certain, possibly rare conditions. But socks that already routinely evade detection by the voter fraud script are not limited in any way (other than they eventually show up on the suspicious voting patterns mod dashboard). –  Robert Harvey Dec 22 '11 at 20:38
1  
@RobertHarvey - I meant if you set some official limit beyond which upvotes are no longer allowed then doesn't it imply that it is OK to vote up to that limit? –  Martin Smith Dec 22 '11 at 20:40
1  
@MartinSmith: I'm not going to say we don't care about 10 votes, even if the limit is hit and the user subsequently earns high rep on his own two feet. But we definitely do care about low-rep users getting a disproportionate amount of reputation (and privileges) using socks. Rate limits don't imply tacit approval of activity below the limit, but they do make it significantly harder to execute bad behaviors above the limit. –  Robert Harvey Dec 22 '11 at 21:00
1  
@RobertHarvey - Nope, it's not just a big city thing, it's happening on Electrical Engineering as well. 2 of our top 50 users share several thousand rep. We're working on a resolution. –  Kevin Vermeer May 29 '12 at 15:21

6 Answers 6

I like this idea, but I would suggest that it also include a minimum number of votes to trigger it. In other words, you could not upvote a question or answer if

  • you have already cast 50% of your total upvotes on that same person's questions/answers and
  • you have upvoted at least, say, 10 questions/answers

The point is that we shouldn't worry too much about blocking a brand new user from upvoting two questions or answers from the same person in a row.

Martin Smith also brought up another important consideration in the comments:

Won't this make it easier for a sock puppet to cast the maximum upvotes allowed without having to worry that they will go over the limit and even kick in the fraud detection mechanism?

My interpretation of this feature request was that it would catch the sock puppets that already manage to avoid detection by the voter fraud detection script. In other words, by establishing an absolute limit on the percentage of upvotes that can be given to a single person, it provides one more way to catch suspicious voting patterns. Although some people may object that this implicitly encourages people to give 50% of their upvotes to the same person, the reality is probably that anyone—or any sockpuppets—who have exceeded this limit in the past will be capped and everyone else will continue to follow the same voting patterns.

share|improve this answer
    
50 answers is 500 rep. That seems like a lot of sock damage before limits kick in. At that point, the user would probably just create another sock. How about 10 answers instead? –  Robert Harvey Dec 22 '11 at 20:12
    
@RobertHarvey Good point. Done. –  Chris Frederick Dec 22 '11 at 20:13
    
In this case the sock puppet account would simply cast 50% of its votes to random posts.. Since to not get detected it means casting few self-votes per day, it wouldn't really be difficult to cast an equal or greater amount to other posts. –  Andreas Bonini Dec 25 '11 at 22:17

I like the idea, but I doubt this helps moderators in determining if votes are suspicious:

  • What stops puppeteers from upvoting random other posts after seeing the error message? Sure, there's a daily vote limit, but I think random votes harm the sites. And maybe make it even more difficult to detect voting patterns.

  • Instead of upvoting random posts: doesn't any limit imply that the number of socks will be increased once that limit has been reached? Isn't a 50% limit easily circumvented using two sockpuppets? (Especially when an error message does not imply a penalty, hence no tactics are needed.)

However, I think it might be a great enhancement of the vote fraud detection script itself, the maximum percentage being one of its secrets.

(But then, I am not a moderator. If it helps, then count me in to support it!)

share|improve this answer

I do not agree with this.

Some people are just really really good at answering (or asking) questions on certain topics and therefore garner a lot of upvotes on all their posts from many of the same users. (aka Jon Skeet)

Maybe putting a limit per day would be better.

share|improve this answer
2  
We already have per-day limits, as I explained. I also explained that such a feature would not affect fanboys at all, if it were tweaked properly. Suggest an alternative algorithm, like making user accounts immune to this cap if they are above 2500 rep, or something like that. –  Robert Harvey Dec 22 '11 at 19:41
    
@RobertHarvey With your suggestion -- That would mean I would be limited in Skeet'ing upvotes. –  amanaP lanaC A nalP A naM A Dec 22 '11 at 19:42
5  
I can assure you, you wouldn't be. Remember, I have access to your stats. :P –  Robert Harvey Dec 22 '11 at 19:43

It was mentioned in comments that this sort of thing could hurt beta sites, and is more of a "big city" problem that larger sites like SO would be more concerned with. However, a narrow tag niche within a larger site could also be harmed by something like this for the same reasons. What if there are just one or two primary answerers in a given tag? Those users are already probably not getting many votes, and this proposal could just reduce that further if there are just a few avid users of that tag routinely upvoting the one or two experts.

I therefore have to disagree with this proposal, especially since it isn't clear if this extra line of defense is even all that necessary. Do you have any stats that would suggest it is desperately needed, enough so to offset the potential damage to niche answerers?

share|improve this answer

I think this is one of those ideas that seem good, but would be impossible to implement effectively.

I wouldn't be surprised if people like Mark Gravel, Jon Skeet, Eric Lippert, etc, upvote only the highest quality, difficult answers, which would more often than not come from within this small group. Preventing a disproportionately high percent of Jon's votes going to Mark from triggering a false positive would be difficult.

And as Arjan mentioned, an intelligent sock puppet is already upvoting lots of other posts to cover his tracks, and stupid sock puppets are probably already being caught with the existing fraud detectors.

share|improve this answer
    
I checked all three accounts of the people you mentioned. The highest percentage of votes anyone in this group has cast against a single person is 6%. –  Robert Harvey Dec 26 '11 at 3:51
    
@Robert - my example may well turn out to be false, but I still fear the odd edge case this would raise, especially considering the relatively small number of sock puppets this would catch—those that are just smart enough to evade the current fraud detectors. –  Adam Rackis Dec 26 '11 at 4:06
4  
@RobertHarvey - I can confidently say that 100% of Eric's upvotes have gone to a single user without having access to any stats! </pedant> –  Martin Smith Dec 26 '11 at 11:50

Maybe the standing of the user who is being upvoted could be factored into the calculations - either based on rep or avg/top score in the question's tags. For example Jon Skeet, being more "trusted", would be allowed to receive a greater percentage of any given user's votes than somebody less proven.

This is based on the assumption that most puppet masters are themselves low rep/tag score, at least before having successfully gamed the system (and even then still leagues apart from the rock stars). Adding this aspect to the equation could exempt the big dogs that others have pointed out would be false flags in your solution.

The narrower tag niches are more sensitive to any strategy, as St. Gnick's answer points out. Given this, I think tag score would be a more meaningful factor than rep, since it would let the algorithm scale to the size of the niche. But calculating the upvote ceiling for a receiver based on tag score instead of rep is more problematic, since tags obviously vary across the range of a user's answers. This would vary the ceiling for a given upvote based on which tags the question had. So it would be easier just to relax this part of the algorithm on narrower tag niches (I'm wondering if it's acceptable only to focus on the mainstream tags - or can puppet masters benefit equally from obscure tags?)

Anyway I just wanted to throw this idea out there in support of yours. Like you, I have no idea what the numbers would look like for what I'm suggesting, but I think the concept is worth considering.

I think the biggest weakness in your overall strategy was pointed out in Arjan's answer - the fact that any puppet can cover its tracks by also voting on a myriad of other random answers (or more deceptively, a pool of semi-random dummies). It's clear that for the algorithm be successful, it would need to be pretty finely tuned.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .