Au lieu d'envoyer quelqu'un en ExiléCommunauté en bannissant son IP, créez une page avec une cartographie de l'IP (avec des gammes peut-être) vers une page BacASable où le script envoye chaque édition ou différence que l'exilé écrit (comme la suggestion d'ouvrir la boîte de Pandore sur FeuDeForêt). De cette manière, il aura toujours un CanalDeCommunication mais nous n'aurons pas à perdre de temps à réinitialiser à chaque fois qu'il écrit. Il est important qu'il y ait une seule cage par personne plutôt qu'une cage unique partagée par tous les bannis, ou sinon vous créerez un BavardageTroll.
Ce schéma permettra de PasserPouvoir venant des bannisseurs traditionnels (RoiDieu et magiciens), et c'est un bannissement passant par la RévisionParLesPairs parce n'importe qui d'autre dans LeCollectif peut le réinitialiser s'il y a abus (sauf la cible). Alors que des abus évidents seront les trolls banissant les contributeurs majeurs, ce serait une belle manière de vous voir listé sur la page. Bien sûr, ceux listés sur la page sont incapables d'éditer la page, aussi à la fin, LeCollectif gagne. Pour aller plus loin, les victimes du processus ne perdent pas leurs travaux car leurs éditions seront appliquées rétroactivement après avoir dé-bannies. Pour les toutes petites communautés, il peut être utilie de DifférerAction pour éviter les abus.
L'aspect important de ce types de bannissement est que c'est simplement une cage. La victime peut encore parler et par conséquent parler à celles en dehors du bannissement. Si la cage enferme accidentellement d'autres personnes derrière l'IP, elles peuvent plaider leurs cas, ce qui pourrait les obliger à quelque travail de détective avec leur administrateur système ou FAI pour retrouver la trace de l'agresseur. Dans tous les cas, ce n'est pas aussi rageant que de fermer toute communication, mais c'est un bon moyen de DissuaderInteraction. C'est une meilleure EpreuveParExil.
Ceci ne fonctionne pas contre les échecs traditionnels des bannissements IPs, tels que l'incapacité d'identifier les personnes par l'IP, mais c'est une approche bien plus douce que de bannir directement, ainsi c'est vraiment un remplacement pour cette suggestion là. Notez qu'un agresseur peut être capable de se réinitialiser sous une ChaussetteMarionnette, une IP dynamique, ou par des cohortes, mais vous allier vous-même à un agresseur d'une telle façon serait une fois de plus un bon moyen a) de vous exposer b) de vous voir vous-même banni. Un IdentifiantUnique? parfait serait utile.
En plus de la pression sociale, on pourrait avoir un ProtecteurMontéeSubite qui liste automatiquement quelqu'un sur la page. Après tout cette technique ne fonctionne que rétroactivement, après que les dégâts soient produits. Si vous voulez vous montrer plus proactif, vous aurez besoin d'une approche fondée sur le script pour identier les agresseurs.
Comme d'habitude, si la CommunautéNestPasDaccord à propos d'un bannissement, alors vous devrez rentrer dans un énorme combat envers l'ExiléCommunauté. Si la personne a une ChaussetteMarionnette, vous aurez un grand combat sur "comment oses-tu dire que je suis une chaussette marionnette" quand la moitié des gens ne croiront pas que c'en est une. Vous aurez plus de problèmes que vous n'en aviez au démarrage. Même si la personne n'a pas de ChaussetteMarionnette, juste un défenseur, ce défenseur sera accusé d'être une ChaussetteMarionette? ce qui sera très mauvais.
Bien bien pire, la chose évidente à faire au moment de démarrer une attaque avec un BacASableAutomatique comme décrit ci-dessus est de passer à travers les derniers N (disons 90) jours des ModificationsRécentes, d'extraire toutes les IPs, et de les coller dans la page BacASableAutomatique. De cette façon seul l'attaquant a la capacité de modifier le site alors qu'à l'inverse LeCollectif est mis en cage. Heureusement, il n'est pas impossible de se protéger contre quelqu'un enfermant LeCollectif. Limitez le nombre maximum d'IPs, d'IDs, de domaines et de noms qui puissent être mis dans le BacASable par exemple. Vous pourriez aussi DifférerAction comme le RemplacementFichier?.
En un sens, ce pourrait être une bonne raison d'utiliser un ProtecteurMontéeSubite pour identifier les coupables. Après tout, vous ne voulez réellement empêcher que ceux qui sont (actuellement) en train d'infliger beaucoup d'énergie négative (cf FormuleDétectionTroll), pas simplement tout le monde car vous pouvez gérér une ou deux mauvaises éditions et pas toutes les personnes. Si c'est une attaque qualitative/psychologique plutôt qu'une attaque/engorgement quantitatif, le BacASableAutomatique est de toute façon la mauvaise réponse. Il ne peut qu'aider à alimenter un FeuDeForêt. Une approche plus étrange serait d'avoir le script qui enferme les personnes au hasard à des intervalles réguliers, supposant que les types utiles seront "délivrés" vraiment rapidement.
Ceci est plutôt comme du niveau d'accès"crapaud" : cf NiveauxAccès. Un WikiProgrammableParLaCommunauté reçoit automatiquement cette fonctionnalité, même si elles peuvent ne pas l'utiliser et que ce ne soit pas aussi facile à utiliser pour l'utilisateur.
Voir aussi ArrêtCitoyen, qui est plus extrême, et par conséquent peut-être plus sûr à utiliser.
DossierSécuritéDure DossierTechnologieWiki DossierTechnologieWikiNonimplémentée
Peut-être que nous devrions faire ça ici ? -- SunirShah
Etude de cas : voici comment vous bloquez RA (en se fondant sur [1]). Non seulement c'est incroyablement alambiqué, mais cela "attrape" aussi TarQuin. Y'a t'il un meilleur moyen (la route vers PointDeVue, peut-être )?
^(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])\.).*$
Ceci est seulement vu pour interrompre les attaques en cours, pas pour les bannissements directs. Le meilleur moyen est la RésolutionDeConflit, mais quelques personnes sont immunisées contre la PressionPair. Les choses allaient bien quand nous nous connaissions tous en wikidom mais ce n'est plus le cas. Le PointDeVue n'arrêtera pas tout parce que c'est sa popularité qui attire ces genres de conflits, pas un espace contraint. En bien des façons, il peut exacerber le problème parce qu'il n'y aura pas assez de défenseurs. Même s'il ouvre la possibilité d'abandonner un vieil endroit aux trolls pour les relocaliser quelque part ailleurs, mais cela semble peut être un peu triste. -- SunirShah
Je réalise que vous pouvez inverser le bac à sable et mettre le collectif entier dans une cage car vous migrez d'abord dans une attaque. Permette ça pourrait être une vraie mauvaise idée. Néanmoins, les reluqueurs inconnus, les RoiDieu et les net.fiends (ceux avec beaucoup d'IPs disponibles) pourront défaire la migration. -- SunirShah
Nouvelle proposition. Dans la veine de la FormuleDétectionTroll, après trois réinitialisations consécutives de vos étditions ou EffacementPage de nouvelles pages que vous avez récemment créées, le système vous place automatiquement dans le BacASableAutomatique. Un attaquant essayant de faire ça à une victime sera réinitialisé et placé dans le BacASableAutomatique. LeCollectif peut élire pour retirer les IPs d'une liste maintenue sur une page wiki, mais ne peut pas en ajouter plus, c'est à dire
ListeBacASableAutomatique?
Retirez n'importe laquelle des IPs suivantes pour libérer l'IP du bac à sable.
127.0.0.1 192.168.0.1 ...
Les agresseurs peuvent encore tourner autour du bac à sable en utilisant plusieurs IPs, mais comme précisé ci-dessus celles-ci seront détectées. Une question intéressante à penser est de réinitialiser le BacASableAutomatique. -- SunirShah