Wikipédia:Bulletin du filtrage/2012

vandalisme massif du jour

Bonjour,
Il me semble qu'un filtre pourrait bloquer assez génériquement les modifications de ce type (en faisant attention aux utilisateurs inscrits qui s'amusent à faire du positionnement fixe dans leur PU). Me gourge ? Cordialement, --Lgd (d) 20 février 2012 à 08:38 (CET)

Filtre 124. J'activerai l'interdiction d'ici quelques heures, sauf avis contraire, s'il n'y a pas de faux positif (peu de risque, seuls 15 pages hors de l'espace utilisateur utilisent ce mécanisme). Orlodrim ^[discuter] 20 février 2012 à 09:31 (CET)

Merci. Peut-être, pour améliorer : être plus générique sur l'élément conteneur ? Cordialement, --Lgd (d) 20 février 2012 à 09:40 (CET)

Maintenant, c'est générique. Orlodrim ^[discuter] 20 février 2012 à 09:53 (CET)

Interdiction activée et site blacklisté (d'ailleurs, en cas de contournement, si c'est urgent, il vaut mieux utiliser la blacklist à mon avis). Orlodrim ^[discuter] 20 février 2012 à 16:51 (CET)

Je viens d'ajouter le cas avec absolute puisque ça continuait [1]. –Akeron (d) 20 février 2012 à 20:50 (CET)

OK, mais il faudra surveiller de près tant que c'est activé : il y en a plus de 50 matchs avec absolute dans l'espace principal et 180 dans les modèles. Orlodrim ^[discuter] 20 février 2012 à 21:40 (CET)

Ok, je viens de vérifier les ajouts de ce type sur les 5 derniers jours, sur tous les espaces de noms, en dehors de ceux du fâcheux, il y a eu 4 ajouts dans l'espace utilisateur. Il y a donc peu de chance que ça gêne quelqu'un mais il faudra penser à l'enlever d'ici quelques jours. –Akeron (d) 20 février 2012 à 22:27 (CET)

J'ai fait un test rétroactif avec un truc perso en partant du 19 février, au cas où certains n'auraient pas été repérés :

• 88.80.28.70 (u · d · b)
• Eloheld0ngs (d · c · b)
• 96.44.163.76 (u · d · b)
• 204.69.190.254 (u · d · b)
• 62.217.113.46 (u · d · b)
• 85.21.78.23 (u · d · b)
• 82.149.225.171 (u · d · b)
• 184.82.107.166 (u · d · b)
• 85.24.188.130 (u · d · b)
• 88.198.100.230 (u · d · b)
• 176.9.53.41 (u · d · b)
• 81.2.197.33 (u · d · b)
• 95.96.189.177 (u · d · b)
• 81.170.186.175 (u · d · b)

C'est tout bon et tout a bien été bloqué sauf 204.69.190.254 (u · d · b) qui s'est étrangement révoqué lui-même. –Akeron (d) 20 février 2012 à 21:49 (CET)

Je ne connais pas le filtre mis, mais pourrait-on avoir aussi un filtre (non bloquant de préférence) sur l'insertion par des users non autopatrolled (ou non inscrit) de "|link=" dans une insertion de media ? Ceci afin non seulement couvrir ce problème mais aussi couvrir des problèmes de non respects des licenses lors de l'utilisation de cet attribut (souvent très mal utilisés, voir même abusivement utilisé pour insérer un lien externe, et encore plus rarement utilisé par une IP qui n'ait pas théoriquement habitué au langage wiki). Loreleil ^[d-c] 23 février 2012 à 18:23 (CET)

Pour les problèmes de ce type (i.e. pas besoin d'une action immédiate), ça coûte moins cher de faire une analyse statique sur le dump. D'ailleurs, voilà la liste complète au 2 février dans l'espace principal : Utilisateur:Orlodrim/Images avec link. De façon amusante, l'image apparaissant le plus de fois dans cette liste, hors domaine public, est Fichier:Official_gnu.svg. Orlodrim ^[discuter] 24 février 2012 à 00:12 (CET)

PS : en dehors des articles, il y en a tellement que je ne peux pas publier la liste complète... Orlodrim ^[discuter] 24 février 2012 à 00:16 (CET)

Merci Orlodrim, j'ai rajouté la dite image au passage dans Wikipédia:Crédits_graphiques#Divers vu son usage divers (license and co) Loreleil ^[d-c] 24 février 2012 à 00:31 (CET)

Est-ce qu'on conserve le filtre actif avec l'interdiction ? J'ai l'impression qu'il n'est pas gênant puisqu'il ne dérange pas les habitués et que c'est une syntaxe html avancée qui a peu de chance d'être utilisée par un nouveau. Vu l'impact [2], probablement amplifié par le système de cache pour les utilisateurs anonymes, je suis pour le conserver tel quel en surveillant de temps en temps s'il y a des faux positifs. Qu'en pensez-vous ? –Akeron (d) 26 février 2012 à 12:05 (CET)

Il me semble qu'il peut être conservé, si besoin en ciblant davantage en prenant en compte l'utilisation d'un paramètre permettant de mettre un lien externe sur une image s'il s'agit de viser uniquement ce type de défaçage (penser également au détournement d'imagemap dans ce cas, je n'ai pas testé, mais cela peut peut-être ouvrir une faille). Cordialement, --Lgd (d) 26 février 2012 à 12:12 (CET)

Mettre une combinaison de plusieurs paramètres multiplie les contournements possibles. D'un autre côté, bien que ce soit peu probable, le filtre peut être déclenché par un utilisateur qui n'a aucune connaissance de cette syntaxe et souhaite juste transférer du contenu d'un article à l'autre. Peut-être laisser comme ça, en mettant quand même un message d'avertissement qui décrit clairement ce qui est interdit par le filtre ? Orlodrim ^[discuter] 26 février 2012 à 13:22 (CET)

J'ai mis l'avertissement MediaWiki:Abusefilter-warning-124. Orlodrim ^[discuter] 29 février 2012 à 08:44 (CET)

Les possibilités de vandalisme avec lien externe sont réduites (celle-ci et l'imagemap il me semble). Si on ne vise que celles-ci, la modification que je proposais n'ouvrait guère de voie de contournement. Mais la conservation avec avertissement le fait aussi très bien. Merci, cordialement, --Lgd (d) 29 février 2012 à 08:50 (CET)

MediaWiki:Abusefilter-disallowed

Bonjour. Pour info, j'ai changé le message en donnant un lien vers Wikipédia:AbuseFilter/Faux positifs, plutôt que « veuillez contacter un administrateur et l’informer de ce que vous avez essayé de faire ». Orlodrim ^[discuter] 4 mars 2012 à 18:18 (CET)

Formulaire pour signaler un faux positif

Je signale qu'à la suite des remarques de Teofilo sur Wikipédia:AbuseFilter/Faux_positifs, j'ai simplifié un peu le formulaire quand on suit le lien "signaler un faux positif" dans un message d'avertissement : avant, après. Orlodrim ^[discuter] 13 avril 2012 à 21:11 (CEST)

J'approuve pleinement. Amicalement — Arkanosis ^✉ 15 avril 2012 à 19:54 (CEST)

Ménage

J'ai supprimé quelques filtres ne servant plus pour ramener les dépassements de condition à zéro (quelques-uns des miens et Spécial:Filtre anti-abus/112). Et OrlodrimBot fait maintenant le classement automatique de Wikipédia:AbuseFilter/Faux positifs (Wikipédia:AbuseFilter/Requêtes viendra quand j'aurai le temps). Orlodrim ^[discuter] 28 avril 2012 à 01:10 (CEST)

Filtre 124 - Spam CSS

Bonjour,

J'ai rendu les conditions du filtre 124 plus strictes, car les trois dernières détections sont des faux positifs. Je prévois de rajouter le test sur les liens externes évoqué dans la discussion initiale (quand j'aurai le temps).

Orlodrim ^[discuter] 22 mai 2012 à 11:06 (CEST)

Filtre bloquant

J'ai activé un filtre avec interdiction (Spécial:Filtre antiabus/121) en lien avec ceci. À surveiller/compléter si besoin. Orlodrim ^[discuter] 25 mai 2012 à 01:31 (CEST)

Un nouveau (un peu spécial) parmi vous

Salut. Les bubus m'ont accordé le flag pour lire vos filtres privés. J'ai promis de ne pas en profiter pour les modifier, et je ne vois pas pourquoi je le ferais. Mon unique but est de sucer la moelle de votre expérience pour améliorer les filtres du Wiktionnaire. Voyez wikt:WT:BF#Accès aux filtres de Wikipédia. Amitiés à toutes. --GaAs (d) 24 juin 2012 à 22:18 (CEST)

Bienvenue ,

N'hésite pas à nous faire des retours selon votre expérience sur le Wiktionnaire.

Amicalement — Arkanosis ^✉ 25 juin 2012 à 12:04 (CEST)

Autorisation de voir les logs des filtres privés

En janvier dernier, la résolution de bugzilla:33380 a supprimé la possibilité pour les autoconfirmed de voir les logs des filtres privés. Seuls les éditeurs de filtres le peuvent à ce jour, mais selon mw:MediaWiki_1.20/wmf6#AbuseFilter, on va pouvoir étendre cette possibilité à d'autres groupes (avec le droit abusefilter-log-private).

Je pense qu'il faudrait au moins que les admins aient ce droit. Je ne sais pas si les développeurs ont prévu quoi que ce soit à ce sujet ou s'il faut faire une demande. Peut-être serait-il même possible d'accorder ce droit à un groupe plus large (autopatrolled, autoconfirmed ?). C'est plus à la communauté qu'aux éditeurs de filtre de prendre la décision, mais j'aimerai quand même avoir des avis ici pour commencer.

Le bug 33380 visait surtout les filtres empêchant la publication de données privées. Or AbuseFilter n'est quasiment pas utilisé dans ce but sur Wikipédia en français. Je ne pense pas que ce soit un outil efficace pour cela (les filres bloquants sont une aide aux administrateurs, mais pas une solution miracle et ils sont toujours faciles à contourner). Donc je serai assez favorable au rétablissement de la visibilité pour un groupe large (autoconfirmed ou autopatrolled).

Orlodrim ^[discuter] 30 juin 2012 à 13:29 (CEST)

Tu m'as pris de vitesse ,

Je pense que le problème « résolu » par #33380 était un faux problème, et que sa résolution a par conséquent été une mauvaise résolution. Un filtre privé n'est pas un filtre qui doit se déclencher sans qu'on le sache, mais un filtre dont on ne doit pas voir le code. Le vrai problème, qui n'est pas résolu, c'est qu'il n'y a pas de support pour les filtres qui doivent se déclencher sans qu'on le sache.

Du coup, compte tenu que le seul filtre protégeant des données privées sur la Wikipédia francophone (le 59) ne s'est pas déclenché depuis janvier et que je viens de procéder au masquage de l'intégralité de son journal, je suis pour ma part favorable à la ré-attribution de ce nouveau-droit-qui-en-fait-n'en-est-pas-un à tous les contributeurs autoconfirmed (retour à la situation antérieure à #33380).

Il me semble que cela ne présente aucun risque sérieux dans la configuration actuelle de nos filtres, tout en rétablissant un de leurs intérêts majeurs, à savoir permettre aux patrouilleurs de repérer les contributions et contributeurs problématiques — ce qui n'est plus possible en l'état que pour les patrouilleurs-modificateurs de filtre.

Amicalement — Arkanosis ^✉ 30 juin 2012 à 21:43 (CEST)

Parfait, on est d'accord. À la réflexion, si on met "autoconfirmed", on rétablit simplement la configuration décidée lors de la prise de décision initiale donc je pense qu'on peut se passer de bureaucratie supplémentaire. J'attends encore deux jours et en l'absence d'opposition, je demanderai le changement sur bugzilla. Orlodrim ^[discuter] 4 juillet 2012 à 18:45 (CEST)

J'ai ouvert une demande : bugzilla:38216. Orlodrim ^[discuter] 6 juillet 2012 à 17:25 (CEST)

Le bug est traité mais il reste la moitié du problème, les patrouilleurs ne peuvent toujours pas voir la liste des détections d'un filtre privé (bugzilla:38223). Orlodrim ^[discuter] 6 juillet 2012 à 22:48 (CEST)

Appels à modèles avec des crochets

Hello, en passant par les pages liées de S, je me suis aperçu que dans une dizaine d'articles, le modèle {{s}} était appelé avec des crochets (et faisait donc un lien vers l'article consacré à la lettre tout en affichant le siècle...) Bon, je viens de corriger les entrées en question, mais je me demandais si ça ne serait pas pertinent de répertorier les modèles les plus courants et faire un filtre activant une entrée dans un journal si la syntaxe du « lien interne » correspond en fait à celle attendue pour le modèle (pour continuer sur mon exemple, "\[\[s\|[IVXLCM-]+(\|e)?\]\]") Qu'en pensez vous ? -Ash - (Æ) 4 juillet 2012 à 01:57 (CEST)

Ça me semble être une bonne idée, c'est typiquement les possibilités offertes par AbuseFilter ! Je vois déjà les modèles {{s}}, {{-s}}, {{s-}}, {{-s-}}, {{s2}}, {{-s2}}, {{s2-}}, {{-s2-}}, {{s mini}}, {{-s mini}}, {{s mini-}}, {{-s mini-}}, {{sp}}, {{-sp}}, {{sp-}}, {{-sp-}}. Tu en as d'autres en tête ? Toto Azéro ^{suivez le guide !} 4 juillet 2012 à 13:56 (CEST)

C'est possible, mais est-ce vraiment une erreur courante ? Sur les autres modèles de siècles tels que -s, s-, etc., ça doit être beaucoup moins fréquent car le lien est rouge. Il y a d'autres modèles où ce type d'erreur existe (par exemple [[Lien|...]]), mais quand le paramètre n'a pas une forme codifiée, c'est difficile d'éliminer les faux positifs. Orlodrim ^[discuter] 4 juillet 2012 à 18:20 (CEST)

On peut faire des stats sur les éventuelles erreurs existantes à partir d'un dump. Peut-être même qu'un projet de maintenance s'en charge déjà. — Arkanosis ^✉ 5 juillet 2012 à 01:18 (CEST)

Voici une liste de liens potentiellements erronés, construite de manière semi-automatique : Utilisateur:Orlodrim/Liens à la place de modèles. Les seuls modèles que j'ai vus où il y a plusieurs erreurs sont : {{API}}, {{Catégorie}}, {{Lien}}, {{Loupe}}, {{Officiel}}, {{Refnec}} (2 cas bien que Refnec soit rouge), {{s}}. Un filtre ne pourrait être activé que pour {{API}}, {{Officiel}}, {{s}} (format particulier) et {{Refnec}} (article inexistant). À mon avis, ça ne vaut pas le coup...

Il y aussi pas mal de liens vers Date de naissance, Date, DOI, ISBN et ISSN, mais là je ne sais pas s'il s'agit d'erreurs ou d'utilisateurs ignorant complètement l'existence des modèles (pour utiliser le modèle, il faudrait dans la plupart des cas changer la syntaxe du paramètre ; pour ISBN, il vaudrait mieux ne mettre ni lien ni modèle).

Orlodrim ^[discuter] 6 juillet 2012 à 22:46 (CEST)

Désactivations juillet 2012

Il y a de nouveaux filtres, il faudrait en désactiver d'autres parce que ça commence à saturer. Je pense que ceux-là peuvent être supprimés :

• Spécial:Filtre_antiabus/116 : 4 détections seulement
• Spécial:Filtre_antiabus/118 : 8 détections seulement
• Spécial:Filtre_antiabus/120 (à mon avis, ça n'apporte pas grand chose par rapport à Spécial:Nouvelles pages : plus de 10 % des créations de pages par les débutants sont balisées, et d'un autre côté ce n'est qu'un problème mineur par rapport aux copyvios, par exemple ; en plus il y a des faux positifs de ce type).
• Spécial:Filtre_antiabus/125 : pas de détection depuis mars
• Spécial:Filtre_antiabus/126 : créé en avril, aucune détection

Êtes-vous d'accord ? Orlodrim ^[discuter] 4 juillet 2012 à 19:11 (CEST)

• 116, 125, 126 : OK, sans commentaire.
• 118 : OK, les détections sont limite des faux positifs tellement c'est insignifiant.
• 120 : Beaucoup de faux positifs, effectivement, donc rien contre sa désactivation.

Merci d'avoir fait le tri — Arkanosis ^✉ 5 juillet 2012 à 01:32 (CEST)

J'ai supprimé les 5. Orlodrim ^[discuter] 6 juillet 2012 à 17:29 (CEST)

Fraude 4-1-9

Bonjour, Kilith (d · c) a signalé sur le Bulletin des patrouilleurs ce « problème » contre lequel, je pense, il est possible de mettre en place un filtre pour dans un premier temps baliser puis s'il n'y a pas de faux positifs envisager d'interdire la modification. Je souhaitais d'abord vous soumettre l'idée avant de commencer à travailler dessus. Cordialement, Linedwell ^[discuter] 4 juillet 2012 à 13:06 (CEST)

Le problème est que le diff en question a été masqué par un OS et qu'il n'est donc plus visible. Donc je ne sais pas exactement ce que tu veux filtrer, mais si tu te sens de faire un filtre, n'hésite pas (met le bien en privé par contre) ! Toto Azéro ^{suivez le guide !} 4 juillet 2012 à 13:52 (CEST)

Il s'agit d'un scam nigérien togolais classique. Je ne sais pas si c'est assez fréquent pour justifier un filtre, mais si c'est le cas, je suggère d'établir une liste des mots les plus fréquents dans les scams typiques (million, dollar, assistance, help, partner, nigerian, togo, bank, transfert, name, address, phone, thanks… ).

On devrait pouvoir trouver ça dans un antispam open-source, j'imagine.

Amicalement — Arkanosis ^✉ 5 juillet 2012 à 01:16 (CEST)

L'idée de s'appuyer sur un antispam pour remplir le dictionnaire du filtre est effectivement une bonne idée. Si d'ici là personne n'a repris le bébé (qui sommeille pour l'instant dans le filtre 95) j'y jetterai un oeil dès que je serais de nouveau « pleinement présent ». Linedwell ^[discuter] 10 juillet 2012 à 21:18 (CEST)

Interdiction pour le pov-pushing écoles

Bonjour, si cela convient je compte activer l'interdiction pour le filtre 132, cette personne fait de nombreux contournements de blocages depuis des mois, cela a conduit à des blocages de plages entières [3] [4], le filtre n'a pour l'instant pas de faux-positifs et devrait être un bon intermédiaire. Cordialement. –Akeron (d) 12 juillet 2012 à 14:08 (CEST)

C'est fait. –Akeron (d) 12 juillet 2012 à 20:39 (CEST)

Interdiction filtre 133

Si personne n'y voit de problème, je pense activer demain l'interdiction pour le Filtre n°133, qui ne comporte aucun faux positif sur les détection actuelles (et le risque d'en voir un est quasi nul...). Toto Azéro ^{suivez le guide !} 17 juillet 2012 à 11:08 (CEST)

Aucune objection pour ma part. Linedwell ^[discuter] 17 juillet 2012 à 11:15 (CEST)

Il n'y a pas de risque, à mon avis tu peux même en rajouter. Orlodrim ^[discuter] 17 juillet 2012 à 12:05 (CEST)

Pour l'instant je n'avais pas jugé nécessaire d'en mettre davantage, mais s'il parvient à contourner le filtre, je n'hésiterai pas… Toto Azéro ^{suivez le guide !} 17 juillet 2012 à 21:17 (CEST)

Interdiction activée, donc… Toto Azéro ^{suivez le guide !} 18 juillet 2012 à 14:22 (CEST)

Désactivations juillet 2012 (2)

Si ça vous va, je propose de poursuivre avec :

• Spécial:Filtre antiabus/46 (sous-titre) : mis en place suite à cette discussion, balisage jamais activé. Une interdiction serait absurde (empêche de révoquer des vandalismes), un avertissement serait ignoré (cf. expérience de {{Commonscat}} avec Spécial:Filtre_antiabus/115). Est-ce que quelqu'un se préoccupe encore des problèmes avec ce modèle, de toute façon ?
• Spécial:Filtre antiabus/48 (nouvel article sans catégorie) : filtre destiné aux utilisateurs expérimentés, mais le balisage n'a jamais été activé. Comme pour le filtre 46, un avertissement serait sûrement ignoré par ceux qui comprendraient que c'est possible. De plus, Badmood s'occupe déjà de cette tâche, en mieux : il envoit un message d'information en différé sur les articles non catégorisés, et ainsi n'ennuie pas pas contributeurs qui créent un article et ajoutent les catégories quelques minutes après.
• Spécial:Filtre antiabus/49 (titre avec beaucoup de majuscules) : il y aura toujours des faux positifs (sigles) donc on n'activera jamais d'avertissement. Un balisage est inutile (ça se voit de façon évidente dans la liste des nouveaux articles).
• Spécial:Filtre_antiabus/70 (dissémination d'informations douteuses) : rien depuis novembre 2011
• Spécial:Filtre_antiabus/89 (vandalisme "Hugo B."/"Hugo M.") : rien depuis juin 2011
• Spécial:Filtre_antiabus/105 (Contournement de blocage F.) : vu son contenu, il balise de nombreuses modifications maladroites, mais apparemment plus rien en rapport avec le contributeur initialement visé.
• Spécial:Filtre_antiabus/119 (Contestation non valide) : les abus de la part de nouveaux contributeurs restent très rares

Orlodrim ^[discuter] 17 juillet 2012 à 23:17 (CEST)

OK pour moi. Toto Azéro ^{suivez le guide !} 18 juillet 2012 à 14:21 (CEST)

C'est fait. Orlodrim ^[discuter] 19 juillet 2012 à 22:06 (CEST)

Messages d'avertissement

Bonjour. Je signale déjà qu'il y a une discussion sur les messages d'abusefilter là. Ça m'a conduit à faire un test. Pour valider sous IP une modification contenant un lien externe et déclenchant un filtre, il faut passer par quatre écrans consécutifs :

• prévisualisation obligatoire ;
• CAPTCHA anti-spam ;
• message du filtre anti-abus ;
• CAPTCHA anti-spam, encore (bug connu).

Je ne sais pas ce qu'il faut en conclure, en tout cas il faut s'en souvenir avant d'activer des avertissements. Orlodrim ^[discuter] 31 juillet 2012 à 23:37 (CEST)

Optimisation des filtres

Bonjour, hier j'ai remarqué qu'un filtre que je surveille ne s'est pas déclenché à cause de la limite globale des 1000 conditions, n'ayant pas trouvé beaucoup d'infos précises là-dessus, j'ai commencé par faire des essais avec un wiki perso en utilisant une limite très basse. J'ai découvert que la fonction contains_any, que j'avais tendance à utiliser pensant qu'elle est moins gourmande qu'une regexp, est bien plus coûteuse en « conditions ». Cette fonction avec 1 paramètre coûte 4 conditions, plus 1 condition par paramètre alors qu'un rlike "x|y|z|..." n'utilise qu'une seule condition. J'ai aussi trouvé que ip_in_range coûte 4, il faut donc mieux faire un like (coût de 1) pour les /24 et /16, voir arrondir un peu des /18 par exemple si ça ne génère pas trop de faux positifs.

Je trouve dommage qu'il n'y ait pas un moyen simple de voir le nombre de conditions utilisées par un filtre, le nombre affiché dans les statistiques sur la page du filtre change régulièrement et n'a pas l'air utilisable. J'ai modifié un abuse filter chez moi pour qu'il affiche ce nombre lorsqu'on test un filtre, ce qui est assez pratique mais j'ai fini par faire beaucoup mieux pour avoir une vue d'ensemble pour WP : un script qui récupère tous les filtres actifs, les passe dans des fonctions abusefilter et affiche le nombre de conditions utilisées pour chaque filtre sur Wikipédia:AbuseFilter/Conditions utilisées. Les chiffres ne sont qu'indicatifs car ils dépendent de l'environnement de test qui est différent, les modifications utilisée pour les tests sont minimalistes et ne doivent presque rien déclencher et abusefilter peut avoir changé depuis la version que j'utilise. Ça donne quand même un bonne idée du coût de chaque filtre et lesquels sont à optimiser, actuellement il faudrait essayer d'améliorer le 19-Bac à sable qui utilise environ 1/4 de la limite à lui tout seul. J'ai prévu d'utiliser le même script pour faire une table du coût pour chaque fonction. –Akeron (d) 15 août 2012 à 17:53 (CEST)

Merci. effectivement le nombre de conditions affichés est bogué. J'avais jeté un coup d'oeil au PHP (voir Wikipédia:Bulletin du filtrage/2011/mars), mais je n'avais pas eu le courage de le modifier pour afficher le résultat. Orlodrim ^[discuter] 15 août 2012 à 18:15 (CEST)

Nouvelle version du filtre bac à sable en cours de test : Spécial:Filtre_antiabus/96. Orlodrim ^[discuter] 16 août 2012 à 00:43 (CEST)

Mise à jour faite. Orlodrim ^[discuter] 18 août 2012 à 22:56 (CEST)

Filtre 29

J'ai l'intention de remplacer le filtre par Spécial:Filtre_antiabus/97, où j'ai réécrit une grande partie de mes ajouts (c'est un peu plus large) et fusionné deux des lignes ajoutées par Akeron. Orlodrim ^[discuter] 18 août 2012 à 23:38 (CEST)

Aucune objection pour ma part. Linedwell ^[discuter] 27 août 2012 à 14:41 (CEST)

J'attire votre attention sur ceci, c'est à l'essai. –Akeron (d) 7 septembre 2012 à 15:44 (CEST)

Ce filtre est très large. Il y aura des faux positifs, ce n'est qu'une question de temps. Tu es en train de bricoler quelque chose pour reproduire une fonctionnalité de MediaWiki qui n'est volontairement pas activée ici. Je n'y suis pas favorable.

Plus généralement, je ne pense pas que le filtre anti-abus soit efficace pour bloquer totalement ce type de vandalisme et qu'il est inutile de chercher à faire cela. Le filtre est utile pour (1) éviter d'avoir à semi-protéger un grand nombre d'articles, (2) empêcher ce vandale de faire tourner en bourrique d'autres personnes que celles qui font volontairement un suivi de ses contributions.

Orlodrim ^[discuter] 7 septembre 2012 à 18:14 (CEST)

J'ai d'abord pensé à cette option qui est active sur d'autres wiki, mais je ne la trouve pas suffisamment configurable, pour être utilisée en l'état il faudrait de toute façon la coupler à des déblocages automatiques, d'où cette idée d'utiliser directement un script externe. Le but n'est pas de bloquer totalement mais de compliquer les contournements par essais/erreurs. J'ai bien conscience qu'il peut y avoir des faux positifs mais il n'y en a pas eu pour l'instant sur ce filtre et c'est temporaire, ça sera toujours moins pire qu'un blocage total de la plage qui a été fait plusieurs fois. D'autre part en cas de faux positif l'utilisateur ne pourra de toute façon pas effectuer la modif, j'ai remarqué que ceux qui subissent ce genre de chose ne comprennent pas d'où ça vient (ce qui est normal) et continuent d'envoyer la même modif sans succès. La différence est que ça empêchera d'autres modifs et de se plaindre ailleurs que sur sa pdd. Je pourrais éventuellement faire un filtre spécifique moins large et aussi ne pas activer le script tout le temps, si je suis là pour surveiller et corriger en cas de problème, je ne pense pas que ce soit plus embêtant qu'un faux positif classique qui empêche la modif. –Akeron (d) 7 septembre 2012 à 20:33 (CEST)

Il y a eu au moins un faux positif [5], causé par un motif dont le principe est encore utilisé dans la version actuelle.

Inversement, des utilisateurs ont déjà signalé des faux positifs sur des filtres bloquants : Wikipédia:AbuseFilter/Faux_positifs/2012#.5Btrait.C3.A9e.5D_Filtre_n.C2.B0122_2012-07-17_17:05, Wikipédia:AbuseFilter/Faux_positifs/2012#.5Btrait.C3.A9e.5D_Filtre_n.C2.B0132_2012-07-23_23:31.

Enfin, il me semble que depuis quelques temps, la plupart des modifications non filtrées sont des "nouveaux" vandalismes plutôt que des tentatives de contournement pour reproduire des vandalismes précédents. Cela qui limite l'efficacité de ton approche à mon avis.

Orlodrim ^[discuter] 7 septembre 2012 à 21:32 (CEST)

Ce faux positif ne concerne pas ce que je cible, par contre il vient juste d'y en a avoir un à cause de mon dernier ajout en bloc que je n'avais pas vérifié en détail par faute de temps (my bad), il y avait une chaîne très générique au milieu. J'ai corrigé le filtre et je compte maintenant lancer le truc uniquement lorsque je suis devant, pour vérifier et agir dans les 5 minutes si besoin. –Akeron (d) 8 septembre 2012 à 03:21 (CEST)

D'autre part, je me pose des questions concernant l'usage de cette plage aujourd'hui par un abuseur de faux-nez de longue durée en contournement de blocage (cf RA, CU et la tentative sur ma pdd)... –Akeron (d) 8 septembre 2012 à 03:27 (CEST)

J'ai un peu modifié le filtre. Par ailleurs, '\b' ne gère pas les caractères accentués ("un éléphant" rlike "\\béléphant" = faux ; "un éléphant" rlike "\\bphant" = vrai) donc certaines entrées sont inopérantes. Orlodrim ^[discuter] 8 septembre 2012 à 10:02 (CEST)

Je suis prêt à tout arrêter si vous me laissez une sous-page pour exprimer mes revendications sur Wikipédia. C'est un bon arrangement, non ?

Il y a environ 700 révocations par jour sur Wikipédia, ce n'est pas 1 ou même 10 de plus qui feront une différence, en plus tes vandalismes sont très faciles à repérer car toujours sur la même plage, et si ça devenait vraiment problématique il suffirait de la bloquer. D'autre part certains vandalismes pourraient tomber sous le coup de la loi et je pense que certaines associations seraient capables de porter plainte si on leur fournit tes IP, sans parler d'Orange qui pourrait couper ton accès pour en avoir abusé. –Akeron (d) 10 septembre 2012 à 12:33 (CEST)

Mise en page des diffs

J'ai ajouté ceci à Common.css pour la mise en page des diffs, pour éviter d'avoir des diffs qui font plusieurs écrans de large à cause des lignes sans espaces, mais il y a peut-être une meilleure façon de faire. –Akeron (d) 7 septembre 2012 à 15:12 (CEST)

Pour information, cet ajout ne semble plus nécessaire et je viens de le retirer : 200733214. od†n ↗^blah 24 janvier 2023 à 08:16 (CET)

Spambot

J'ai créé un filtre anti-blanchiment de User:OrlodrimBot dans Spécial:Filtre_antiabus/137. Je n'ai pas le temps de voir le log du filtre 134, mais à mon avis il y aurait peu de risque à activer quelque chose de similaire (ou encore plus simple : bloquer si la nouvelle taille est inférieure à un seuil donné) pour les pages les plus souvent effacées. Orlodrim ^[discuter] 26 septembre 2012 à 19:56 (CEST)

Je n'ai pas vu de faux positif sur le filtre 134 pour l'instant, il en détecte une bonne partie mais pas tout, par exemple lorsque la page est petite ou sur certaines pages de discussion. Je pense l'élargir avec d'autres approches. J'ai mis en place un avertissement aujourd'hui, ça pourrait suffire pour une bonne partie sans qu'on ait trop à craindre les faux positifs, j'ai remarqué que certains bots ont été bloqué par l'avertissement du filtre 1 anti blanchiment. Si l'avertissement n'est pas suffisant on pourrait effectivement passer certaines pages fixes en interdiction. –Akeron (d) 7 octobre 2012 à 14:34 (CEST)

Filtre 132

Bonjour,

J'ai fait un petit ajout de deux catégories sur ce filtre, n'hésitez pas à me taper sur les doigts si j'ai fait une erreur — S t a r u s – ¡Dímelo! – 6 novembre 2012 à 23:42 (CET)

Insultes sur une pdd utilisateur

J'ai ajouté il y a un certain temps la détection de l'ajout de « connard » sur une pdd utilisateur sur le filtre générique bloquant 29, ça fonctionne bien, parfois c'est suffisant, parfois c'est suivi d'un contournement (exemple [6] [7]). Du coup j'ai créé un nouveau filtre spécialisé, qui pourra facilement être étoffé : Spécial:Filtre_antiabus/139. Je pense activer l'interdiction d'ici quelques jours. –Akeron (d) 23 novembre 2012 à 14:56 (CET)