AutomaticSandbox

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Instead of sending someone to CommunityExile by banning their IP, create a page with a mapping of IP (with ranges, perhaps) to a SandBox page where the script automatically sends every edit or difference the exiled writes (a la the suggestion to can the worms on ForestFire). That way they still have a CommunicationChannel, but we do not have to waste time reverting everything they write. It is important that there be one cage per person rather than a single shared cage for all banned, or else you will create a TrollTalk.

This scheme will DevolvePower from the traditional banners (GodKings and wizards), and it is a PeerReviewed ban since anyone else in TheCollective can revert it if it is abused (except the target). While obvious abuses will be trolls banning major contributors, that would be a good way to get yourself listed on the page. Of course, those listed on the page are incapable of editing the page, so in the end, TheCollective wins. Further, victims of the process do not lose their work as their edits can be retroactively applied after they are unbanned. For very small communities, it may be useful to DelayAction to avoid abuse.

The important aspect of this type of ban is that it merely a cage. The victim still can talk and therefore talk themselves out of a ban. If the cage accidentally traps other people behind the IP, they can plead their case, which might require them doing some detective work with their system administrator or ISP to track down the attacker in return for access. Either way, it isn't as infuriating as shutting down all communication, but it is a good way to DissuadeInteraction. It's a better TrialByExile.

This does not work against the traditional failures of IP bans, such as the inability to identify people by IP, but it is a more soft approach than outright banning, so it's really a replacement for that suggestion. Note that an attacker may be able to revert themselves given a SockPuppet, a dynamic IP, or cohorts, but allying yourself with an attacker in such a manner would once again be a good way to a) expose yourself, b) get yourself banned. A perfect UniqueIdentifier? would be useful.

Additionally to social pressure, one could have a SurgeProtector automatically list someone on the page as well. After all, this technique only works retroactively, after damage is done. If you want to be more proactive, you will need a script-based approach to identifying attackers.

Problems

As usual, if the CommunityDoesNotAgree about a ban, then you will get into a huge fight over whom to CommunityExile. If the person has a SockPuppet, you will have a big fight over “how dare you say I'm a sock puppet” when half the people won't believe it is one. You will have more problems than you started with. Even if the person has no SockPuppet, just a defender, that defender will be accused of being a SockPuppet, which will be very bad.

Much, much worse, the obvious thing to do when beginning an attack with an AutomaticSandbox as described above is to go through the last N (say 90) days of RecentChanges, pull out all the IPs, domains, and UserNames, and paste them all to the AutomaticSandbox page. That way only the attacker has the ability to modify the site whilst inversely TheCollective is caged. Fortunately, it's not impossible to protect against someone caging the collective. Limit the maximum number of IPs, IDs, domains, and names who can be sandboxed, for example. You could also apply DelayAction a la FileReplacement.

In one way, that might a good reason to use a SurgeProtector to identify the culprits. After all, you really only want to deflect those who are (currently) inflicting a lot of negative energy (cf. TrollDetectionFormula), not just anyone as you can handle one or two bad edits, and not good people either. If it is a qualitative/psychological attack rather than a quantitative/flood attack, AutomaticSandbox is the wrong answer anyway. It's only to help can a ForestFire. A weirder approach would be to have the script randomly cage people at irregular intervals, assuming that the useful folks will be ‘let out’ pretty quickly.

This is rather like ‘toad’-level access: cf. AccessLevels. A CommunityProgrammableWiki gets this feature automatically, though they may not use it, and it's not as user-friendly.

See also CitizenArrest, which is more extreme, and thus perhaps more safe to use.

Perhaps we should do this here? -- SunirShah

Case study: here's how you block RA (based on [1]). Not only is this incredibly convoluted, but it also "catches" TarQuin. Is there a better way (the road towards ViewPoint, perhaps)?

 ^(64.12.(9[6-9]|1[01]\d|12[0-7])|149.174.(14\d|15[0-5])\.|
   152\.163\.(24\d|25[0-3])\.|172\.(12[89]|1[3-9]\d|20\d|21[01])\.|
   195\.93\.(3[2-5]|4[89]|5[01]|6[4-9]|[78]\d|9[0-5])\.|
   198\.81\.([0-389]|1[6-9]|2[0-367])\.|
   202\.67\.(6[46-9]|[7-9]\d|1[01]\d|12[0-7])\.|
   205\.188\.(11[2-9]|12[0-7]|178|19[235-9]|20[0189])\.).*$

It's only meant to stop attacks in progress, not outright bans. The better way is ConflictResolution, but some people are immune to PeerPressure. Things were going well when we knew everyone in wikidom, but not any more. ViewPoint won't stop anything since it is popularity that attracts these types of conflicts, not a constrained space. In many ways, it may exacerbate the problem as there won't be enough defenders. Although it does open up the possibility of abandoning an old location to the trolls to relocate somewhere else, but that seems kind of sad. -- SunirShah

I realize you can invert the sandbox and put the entire collective into a cage as your first move in an attack. Allowing this is might be a really bad idea. However, unknown lurkers, GodKings, and net.fiends (those with many IPs available) will be able to undo the move. -- SunirShah

A new proposal. In the vein of the TrollDetectionFormula, after three consecutive recent reverts of your edits or PageDeletions of new pages you have recently created, the system automatically puts you into the AutomaticSandbox. An attacker attempting to do this to one victim will be reverted and put into the AutomaticSandbox. TheCollective can elect to remove IPs from a list maintained on a wiki page, but they cannot add any more. e.g.

 AutomaticSandboxList?

 Remove any of the following IPs to free the IP from the sandbox.

 127.0.0.1
 192.168.0.1
 ...

Attackers can still get around the sandbox by using multiple IPs, but as mentioned above these will be detected. An interesting question to think about is reverting the AutomaticSandbox. -- SunirShah

I don't think any of the ideas on this page are workable. They're only likely to catch out people who don't know the system — newbies, who consequently won't know they're in a SandBox, nor how to appeal for clemency. Any system can be gamed, so an AutomaticSandbox can only give a false sense of security.

I think we should rewrite the introduction of the page to make the problems a lot more prominent. -- ChrisPurcell

: Depending on which problems you speak of, i.e. The problems that inspired the proposal or your perceived problems with this proposal, editorially speaking, the proper format is that the former makes sense as a precis, the latter should be in a coda after the proposal. -- SunirShah

I was thinking Wiki:ThereforeBut form. (Why do we not have that pattern here?) -- ChrisPurcell

That's hardly necessary. The page is already split into proposal and problems. -- SunirShah

Hmm. I think this might have been my wigging out when I read the page, then. -- ChrisPurcell

CategoryHardSecurity CategoryWikiTechnology CategoryUnimplementedWikiTechnology

AutomaticSandbox

Problems

Discussion