To maintain control over the abuse of this feature, any citizen who chooses to use this feature is putting their neck on the line by having themselves CitizenArrested. Note that the script not only reverts the changes by the IP, but HardBans the IP.
Unlike the AutomaticSandbox which was to control trolling, the CitizenArrest's chief purpose is to control spam and vandalism. While trolling is a very subjective response that requires ConflictResolution and thus an open ConflictResolution process, spam requires only a mechanical, non-semantic, economic response. As such, it should be blatantly clear when to use the CitizenArrest function, leaving would-be any PoliceForce's conscience free of charges VigilanteJustice. Rather, it's a more effective tool to encourage community SelfPolicing than the current techniques that advantage the spammers.
Clearly such a tool is open to abuse by vandals. The following measures can be put in place to deal with attackers abusing this tool to 'arrest' the innocent:
The appeals process is simple. When CitizenArresting someone who has citizen arrested someone else in the last 24 hours, the appeal will undo the previous CitizenArrest. And similarly, the person who has appealed can be CitizenArrested.
Clearly gangs of vandals are a real problem, with one CitizenArrest being appealed by another, being appealed by a colluder. However, there is a finite limit to how many arrests can be made this way before everyone is banned, and the overwhelming number of good people on the site (a la SoftSecurity) have taken care of the mess. Note that an IP can be CitizenArrested by multiple people.
The entire process will be published on pages listed in RecentChanges in order to maintain an OpenProcess as well as an AuditTrail. However, it may be useful to have RecentChanges filter out 'arrested' pages in order to clean up spam HijackingRecentChanges. This doesn't have to remove the entries, but merely create a class of pages lower than minor, which is arrested (cf. HiddenPages).
It may also be possible to scale the CitizenArrest across several sites with something as simple as the PeerToPeerBanList. That is, if one person on one site blocks an IP, everyone else in that group will block the IP, thereby radically increasing the cost of spamming. The drawback of course is abuse, malfeasance, or mistakes. If there is ever a false positive in the grid, the damage will be extreme.
In many ways, the CitizenArrest is like the gun defense often touted in the United States. If everyone has a 'gun', then breaking into one home may be your last home, and so it lowers crime. However, of course, guns are abused all the time to kill in anger. There is no social control that spans many sites. Constructing a centralized regime as in the case of guns is not a good strategy as it is calls out to be attacked (LimitTemptation).
However, unlike the gun defense, banning IPs does not have to be forever. It's not even meaningful to do this since spammers will rotate their IPs rapidly (instead, use an OpenProxy ban). If the bans were DynamicValues, then this is a natural appeals process. However, perhaps all that means is that spammers will get used to rotating IPs around the DynamicValue cut off period. Again, use an OpenProxy defense.
That being said, with a NetworkDistance-type block, we can have spam-infested regions of the network construct their own blockades against themselves simply by building a coalition of sites that have CitizenArrested many of their IPs. Since this requires a lot of data points to be effective, the best way to do this in the face of DynamicValues that expire data is to gather a large volume of data through a PeerToPeerBanList.
Since the PeerToPeerBanList is based on a publish-and-pull system, commmunities may elect to only rely on other neighbouring communities they know and trust. For the time being until new theory is developed, mass aggregration is not feasible. But certainly only "network" solutions to spam that are widespread, collective responses without centralized authority have a probability of long-term success.
I'm not convinced that implementing this will be enough to unblock China, but I hope to build a system that will have China automatically block itself. -- SunirShah
It seems to me any decent access control mechanism is going to rely on a far more robust user account creation system than the current Preferences cookie. Simply put, the login mechanism must be fixed, and passwords must be more secure. Any mechanism depending on the identity of the users invoking it depends on such a fix. There's probably ten or more ChuckAdams's floating around the account "database" because of the sloppy hack that is the Preferences and login systems. --ChuckAdams
We don't have a login system. The preferences are just that. Preferences. We have so far worked on the principle that LoginsAreEvil. Personally, I don't like the world that accounts create, since I don't want to have my behaviour accounted. -- SunirShah
Personally, I consider lack of unique logins to be a wee problem... --SunirShah (not really)
PeerReview is supposed to solve IdentityTheft problems. But that presumes we all know and care about each other. The more strange we are to each other, the more social problems we will have. -- SunirShah (really)
Am I the only one who has problems with this? I mean while I could technically CA anyone I wanted to, this seems to actually lend sanction to escalating conflict with insta-bans. -- ChuckAdams (wow, I just verbed my initials ... Cliff's too I guess)