Wikipédia:Bulletin du filtrage/2024

Comptes avec « Bot » dans le nom

Bonjour,

J'ai désactivé Spécial:Filtre_antiabus/375 pour permettre à un utilisateur avec 200 contributions de créer un bot. Ce cas est résolu, mais ce filtre me semble intrinsèquement problématique. En effet, pour un bot créé sur un autre wiki, il semble tout simplement impossible pour ce bot d'avoir aussi un compte sur Wikipédia en français (il ne peut pas être créé par son dresseur, vu que le compte global existe déjà). Il s'agit d'ailleurs de la plupart des détections (peut-être ces bots essayent-ils d'accéder à Wikipédia en français en lecture pour effectuer des tâches sur d'autre wikis, comme mon bot quand il traite le remplacement de {{Lien}}).

Y a-t-il encore des détections justifiant de garder ce filtre actif ?

Orlodrim (discuter) 4 mars 2024 à 23:25 (CET)

Salut. Alors plusieurs choses différentes pour le maintien du filtre 375 :

• Les comptes avec "bot" dans le nom sont interdits ici (16) et ne sont pas plus autorisés sur le wiki anglais par exemple : Thisyer+bot bloqué là-bas pour ce motif (quand il ne s'agit pas de compte bot autorisé)
• Le fait qu'un compte "bot" soit autorisé sur un Wiki ne l'autorise pas sur d'autres (comme compte "bot" j'entends). Donc qu'il ne puisse pas contribuer ici alors qu'il a été créé sur un autre wiki est bien mieux.
• Rien n'empêche de désactiver temporairement le filtre quand une demande est légitime pour permettre la création puis la réactivation à l'issue comme je viens de le faire car le bot en question a été créé.
• Ce filtre est dédié aux bot mais il a son pendant pour les noms d'utilisateurs (filtre 319) qui rassemble à la fois les noms interdits (vulgarités entre autres) et pénibles de longue durée. Il me semble impensable de désactiver ce filtre. D'ailleurs, la séparation entre le 319 et le 375 est floue : le 375 empêche la création de comptes "bot" mais c'est le 319 qui empêche les noms de comptes avec "script" qui pourraient être assimilés à des bots...

A l'inverse

• Sans parler de problème de compte "bot", il y a régulièrement des FP comme pour Duane Cabot par exemple.
• La règle d'interdiction des noms de compte avec "bot" date d'avant les comptes globaux il me semble. Du coup, elle interfère...

En résumé, pour moi, il me semble que désactiver ce filtre est une mauvaise idée : il apporte plus de bénéfices sur WP.fr que d'inconvénients.

Nota : dans l'idéal, pour résoudre le problème de lecture que tu évoques, il faudrait autoriser la création des noms problématiques avec un blocage automatique en écriture mais ce n'est pas une option dans les filtres.

Nota 2 : c'est  LD qui a créé le message de ce filtre et qui y parle du statut de "créateur de compte" que demandait Hugnome sur le bulletin des Bubus. 'toff ^[discut.] 5 mars 2024 à 09:04 (CET)

Bonjour @Orlodrim & @Supertoff,

Puisque l'identifiant unique rattache chaque wiki au primo-enregistrement CentralAuth ou à la primo-connexion locale, on peut couper la poire en deux. Le filtre a été mis en place avant l'introduction des variables CentralAuth (T130439), on pourrait (en théorie, pas testé) se servir de global_user_editcount pour permettre la primo-connexion locale dès lors que le compte a acquis assez de contributions globales. Cela continue d'empêcher le primo-enregistrement local.

• Pour le dire autrement (moins technique) : les comptes « -bot » qui sont créés ailleurs ne seront pas automatiquement importés mais pourront l'être s'ils atteignent un seuil de contributions. Cela évitera d'avoir de faux robots, sans omettre la possibilité d'en avoir un vrai (même s'il faudra toujours une intervention manuelle de temps en temps).

Le défaut de la situation actuelle réside dans le fait que MediaWiki:Abusefilter-disallowed-375 n'est pas exhaustive. Il faudrait soit complémenter Wikipédia:Créateur de comptes, soit créer Aide:Créer un compte de robot (ou complémenter WP:BOT). LD (d) 5 mars 2024 à 12:28 (CET)

Je ne connaissais pas global_user_editcount. Si ça marche, ça me semble une bonne idée pour empêcher de bloquer complètement la création automatique de compte (par exemple, autoriser la création du compte sur Wikipédia en français si global_user_editcount > 500).

Je note la réticence de  Supertoff même pour les comptes globaux, mais je crois que par rapport aux vandales, c'est une situation qui a beaucoup moins de chance d'être problématique.

• D'une part, un robot ne va pas se mettre à contribuer sur Wikipédia en français simplement par erreur. Si le compte d'un robot actif sur un autre wiki commence à contribuer sur Wikipédia en français, c'est que son dresseur a expressément choisi de le faire.
• Commencer à contribuer avant de demander le statut de bot est la procédure normale sur ce wiki. Si quelqu'un demandait le statut de bot avant d'avoir montré que le bot fonctionne, on lui refuserait sa demande.
• Les problèmes avec les utilisateurs expérimentés peuvent normalement être résolus par la discussion. Mettre un filtre bloquant visant de tels utilisateurs devrait exceptionnel et seulement en réponse à un problème avéré.

Orlodrim (discuter) 8 mars 2024 à 18:23 (CET)

Hello. +1 Orlodrim concernant « Commencer à contribuer avant de demander le statut de bot est la procédure normale sur ce wiki ». Àmha on peut passer le 375 en non bloquant, c'est ce qu'il y a de plus simple. (En revanche, d'accord avec Supertoff, pas de raison de toucher au 319.) — Jules* ^discuter 8 mars 2024 à 18:37 (CET)

 Orlodrim : je crois qu'on ne se comprend pas :

• Si le compte d'un robot actif sur un autre wiki commence à contribuer sur Wikipédia en français, c'est que son dresseur a expressément choisi de le faire. : sauf erreur, il n'a pas le droit de le faire sans autorisation pour chaque wiki ? Autrement dit : un compte avec le suffixe "bot" doit être un bot autorisé sur chaque wiki : soit ce n'est pas un bot autorisé et il n'a pas le droit de contribuer avec ce nom (c'est l'esprit de Wikipédia:Nom d'utilisateur#Noms d'utilisateur déconseillés ou interdits), soit il est autorisé et donc c'est un compte de bot...
• Commencer à contribuer avant de demander le statut de bot est la procédure normale sur ce wiki. : sauf que le filtre est là pour empêcher la création de faux comptes bot, par pour empêcher la création de vrais bot. Empêcher la création de vrais comptes bot n'est qu'un effet de bord.

Mais bon, comme je suis le seul à penser que c'est une mauvaise idée de désactiver ce compte, mon avis n'a plus d'importance. On verra bien ce que ça donne. J'espère avoir tort mais je vous conseille avant de le désactiver de bien vérifier les détections du filtre car, sauf erreur, Orlodrim n'émet que des hypothèses sans certitude au début de cette section... 'toff ^[discut.] 8 mars 2024 à 20:01 (CET)

Ce que LD et moi avons proposé assouplirait le filtre seulement pour les comptes ayant déjà plus de 500 contributions sur d'autres wikis. Il est donc extrêmement improbable que ce soient de faux comptes bot. Si je comprends bien ton point de vue, cela ne devrait pas te poser de problème.

Je comprends que sa désactivation complète ne semble pas consensuelle, donc je ne compte pas faire ça (même si ça ne me dérangerait pas).

Orlodrim (discuter) 9 mars 2024 à 18:14 (CET)

Pour aussi tout moyen d'éviter le blocage de bots légitimes. Même s'ils ne font pas d'edits sur frwiki, ils peuvent lire du contenu ici (par ex framabot (d · c · b) se connecte à n'importe quel wiki pour vérifier la source des traductions). Dans tous les cas, les bots doivent être connectés et ne devraient pas faire de requête anonymement. -Framawiki ^✉ 9 mars 2024 à 21:03 (CET)

J'ai ajouté une condition sur global_account_editcount (plutôt que global_user_editcount, vu phab:T345632). La variable est censée exister spécifiquement pour l'action de création de compte. Cependant, la variable ne semble pas enregistrée pour les détections passées avec l'action « autocreateaccount », donc j'ai un doute. On verra bien. Orlodrim (discuter) 13 mars 2024 à 17:16 (CET)

C'est parce que le patch a ajouté ces nouvelles variables dans le hook "AlterVariables" (pour les détections au moment où elles se produisent), mais pas dans le hook "GenerateVarsForRecentChange" (quand on examine les détections passées).

Et il s'avère que ce n'est pas possible… Quand on examine les détections passées, les variables affichées ne sont pas des valeurs qui ont été enregistrées au moment de la détection… En fait, les variables sont regénérées à partir des données de la RC (voir cette table ; données stockées indéfiniment, en l'occurrence). Oui, c'est relativement mal pensé comme système, et cela cause divers bugs de variables avec des valeurs erronées (par exemple, la variable user_editcount contient l'edit count actuel de l'utilisateur, pas celui au moment de la détection).

À propos, j'avais rencontré une histoire similaire avec la variable page_id, qui auparavant était erronée dans les détections passées. Voir T334617. Pour cette histoire, il était possible de déterminer la valeur correcte (int 0) à partir des données de la RC (car elle indique si c'est une création de page). Mais pour la présente histoire, je pense qu'on ne peut rien faire de plus. Au moment présent, la seule information disponible est l'edit count actuel de l'utilisateur, on ne dispose plus de son edit count au moment où il a effectué la modification.

od†n ↗^blah 19 mars 2024 à 00:09 (CET)

Huuummm. En examinant les dernières détections du filtre, il y a pourtant des variables global_account_editcount. Peut-être que le hook AlterVariables est aussi appliqué aux RC (enfin bon, j'ai déjà assez fouillé comme ça). De plus, les variables figurent seulement dans les dernières détections, et pas dans les détections passées ; je suppose que le moment du changement coïncide avec celui du passage en prod du code ajoutant les variables. Il semble il avoir un certain enregistrement des informations, j'ai dû louper quelque chose.

Ceci étant, les variables sont bien fonctionnelles pour les détections, et c'est l'essentiel. Et quand on examine les détections passées, il faut de toute façon s'attendre à diverses anomalies dans les valeurs de variables fournies.

od†n ↗^blah 19 mars 2024 à 00:58 (CET)

Bonjour. Je viens d'avoir le cas avec une demande de JJMC89 (d · c · b) pour son bot CopyPatrolBot (d · c · b) qui d'après sa page utilisateur sur Meta est un bot qui patrouille les RC et signale les copyvios, sans jamais effectuer de modification ; il ne devrait donc jamais atteindre 500 contributions. Étant donné que le demandeur est de confiance (admin et steward), j'ai temporairement désactivé le filtre 375 pour créer le compte local via Special:CreateLocalAccount et réactivé le filtre. Pas d'autre modification du filtre à réaliser àmha en l'état, ce genre de cas peut être traité au cas par cas (mais j'ajoute un témoignage à ce que disait Framawiki ci-dessus ). — Antimuonium ^{U wanna talk?} 10 avril 2024 à 00:36 (CEST)

De manière un peu liée à phab:T345632 et à la nécessité de réactiver/désactiver, @Orlodrim, @Od1n et @Antimuonium, j'avais soumis phab:T360765, fusionnée avec phab:T307828 (qui n'a pas entièrement de rapport sauf le titre, mais bref). Pas certain que ça voit le jour (rapidement), mais je suis peut-être médisant. LD (d) 10 avril 2024 à 00:56 (CEST)

page_last_edit_age

Hello,

Un petit mot pour signaler l'arrivée d'une nouvelle variable, page_last_edit_age (phab:T269769). Elle a pour valeur le nombre de secondes écoulées depuis la dernière modification de la page. Utile pour éviter les faux-positifs, notamment en combinaison avec page_recent_contributors.

— Jules* ^discuter 28 avril 2024 à 20:53 (CEST)

Wikipédia:AbuseFilter/Modifications bloquées en rade

Hello (ping @Do not follow),

Wikipédia:AbuseFilter/Modifications bloquées n'est plus mis à jour par AkeronBot (d · c · b) depuis une semaine. J'ai envoyé ce jour un mail à @Akeron pour l'en informer.

En attendant, les modifications interdites par des filtres peuvent être consultées ici.

— Jules* ^discuter 29 avril 2024 à 17:11 (CEST)

Je ne découvre que maintenant ce message et la panne. L'historique montre que cela fonctionne à nouveau depuis le 2 mai. -- Habertix (discuter) 10 mai 2024 à 02:32 (CEST).

Statut d'Abuse Filter

Bonsoir,

Comme il est coutume de le faire, j'annonce ici même que j'ai fais une demande pour obtenir le statut d'Abuse Filter sur le bulletin des Bubu.  Aelxen ^Plaît-il ? 8 juin 2024 à 21:21 (CEST)

Filtre 71

Bonjour, le filtre 71 sert actuellement à gérer la problématique dont il est discuté ici.

Depuis la mise en œuvre en 2021, le filtre a effectué énormément de détections, mais j'ai le sentiment qu'il ne s'agit maintenant plus que de FP. Cependant, les détections étant très larges, il est difficile de les analyser.

J'envisage de désactiver le filtre, de façon assez similaire à ce que j'ai récemment effectué pour le filtre 368. La différence est que dans le cas présent, il s'agit d'un pénible beaucoup plus tenace. J'aurais donc besoin de savoir s'il est encore dans les parages, ou s'il a disparu des radars. Et même dans le cas où le pénible serait encore présent, le filtre aide-t-il vraiment encore à le repérer ?

Pour notification :  Do not follow, Hégésippe Cormier, LD et Panam2014. (à propos, pour ceux d'entre vous qui n'ont pas les droits AF, je vous invite à les solliciter, cela vous permettrait de voir le contenu des filtres)

od†n ↗^blah 12 juin 2024 à 20:12 (CEST)

@Od1n il revient très souvent. Dernièrement avec Michel Patrick Boisvert. Panam (discuter) 12 juin 2024 à 20:14 (CEST)

C'est ce que je craignais, merci pour la réponse. Je laisse le filtre en place. Néanmoins, les détections du filtre sont-elles pertinentes, en fais-tu usage ? od†n ↗^blah 12 juin 2024 à 20:20 (CEST)

Je viens d’annuler une modification détectée par le filtre (10 juillet 2024 à 12:46). Il est vraiment très large, mais comme il n’est pas bloquant, il semble avoir une certaine pertinence, quoique peut-être anecdotique, en plus d’être très peu "empêcheur de tourner en rond". Kirham ^{qu’ouïs-je?} 10 juillet 2024 à 17:00 (CEST)

Pourquoi le site www.elusa.fr est-il filtré ?

Bonjour, lorsque j'essaye de mettre un lien externe vers ce site qui relate de l'ancienne cité Elusa devenu la ville d'Eauze dans le Gers, j'ai un filtrage qui empêche tout ajout de lien. En connaissez vous la raison ? Cordialement, FHd (discuter) 2 juillet 2024 à 22:28 (CEST)

Bonjour. Ce site est effectivement en liste noire depuis 2016. Il avait apparemment été ajouté en raison de spam (pour faire sa promotion de la part de la chargée de communication). Je ne connais pas la qualité de ce site web.  Thibaut120094 pour info. — Antimuonium ^{U wanna talk?} 2 juillet 2024 à 23:29 (CEST)

Et pour le coup, ce n'est pas en lien avec le filtrage. 'toff ^[discut.] 3 juillet 2024 à 07:26 (CEST)

Barmitzva FC

Bonsoir,

J'ai bloqué au moins un certain nombre d'IP ces derniers jours, qui ont toutes pour caractéristiques de procéder, entre autres actions bizarres et non-constructives, au remplacement du nom de clubs de football par « Barmitzvah FC » ou comparable :

• 2A01:E0A:8CE:78C0:0:0:0:0/64 (d · c · b),
• 2A01:E0A:B11:2630:0:0:0:0/64 (d · c · b),
• 2A02:A03F:69D7:8601:0:0:0:0/64 (d · c · b),
• 2A01:CB18:2F4:A700:0:0:0:0/64 (d · c · b).

Un filtre serait-il envisageable et et réalisable ? --Laurent Jerry (discuter) 12 juillet 2024 à 18:19 (CEST)

 Laurent Jerry : filtre 264. 'toff ^[discut.] 12 juillet 2024 à 19:00 (CEST)

Filtre 30

Bonjour !

Pensez-vous que nous pourrions rajouter des réseaux sociaux au filtre 30 comme LinkedIn, Flickr, Reddit ou d'autres à discuter, cela pourrait être utile en vue de leur notoriété ? (je mentionne @Antimuonium qui a aussi eu l'idée). Bien à vous, ShifaYT ✉Tchater 18 août 2024 à 14:08 (CEST)

Bonjour, pas contre dans l'idée, en partant peut-être de Wikipédia:Rapports/Liens externes les plus utilisés dans l'espace principal et/ou d'une discussion WP:ODS. LD (d) 18 août 2024 à 14:12 (CEST)

Bonjour. Oui, pourquoi pas en rajouter quelques-uns (sans être exhaustif). Nous avons déjà ajouté x.com (car il y avait déjà Twitter). J'ai parcouru rapidement la Catégorie:Réseau social en notant ceux qui pourraient paraître pertinent : LinkedIn (linkedin.com), Flickr (flickr.com), Snapchat (snapchat.com), Tumblr (tumblr.com), Reddit (reddit.com) et Quora (quora.com). On a aussi BeReal (bere.al) et les principales instances de Bluesky Social (bsky.social) et Mastodon (mastodon.social) mais qui ne semblent pas avoir d'occurrence sur Wikipédia.

Je ne connais pas en détail tous ces réseaux sociaux donc certains sont sûrement peu pertinents mais on peut peut-être partir de cette liste pour en discuter (l'ODS n'est pas une mauvaise idée). — Antimuonium ^discuter 25 août 2024 à 10:48 (CEST)

L'ajout de LinkedIn me semblerait tout particulièrement justifié (mélange de réseau social et de vitrine à autopromotion). Reddit et Quora sont tout à fait des réseaux sociaux (même si le deuxième est plutôt un Q&A). Snapchat, je ne sais pas si cela peut se trouver en lien publié. Flickr, ce sont des galeries d'images, donc à voir s'il y a des liens vers eux (mais je suppose que oui). Tumblr, je ne sais pas trop où ça en est, mais c'est effectivement un réseau social.

J'allais mentionner Instagram (galeries d'images, mais c'est un réseau souvent mentionné sur YouTube), mais il est déjà dans la liste.

Je pourrais ajouter Telegram (feeds consultable sur le domaine "t.me"), et Medium (un site sur lequel apparemment tout un chacun peut publier, du coup j'y ai quelquefois trouvé des publi-informations déguisées ; toutefois il n'est pas un réseau social, donc il est peut-être en dehors du cadre de ce filtre).

od†n ↗^blah 25 août 2024 à 12:45 (CEST)

Option CAPTCHA

Rebonjour, j'écris un message différent car c'est encore un autre sujet !

Pensez-vous que nous pourrions utiliser la nouvelle option (action entreprise en cas de détection) CAPTCHA qui nécessite que l'utilisateur procède à la résolution d'un CAPTCHA afin de poursuivre l'action, notamment je pensais pour le filtre 321 (filtre privé) par exemple en raison des FPs, ça pourrait être une alternative plus légère à l'option du filtre bloquant ? Qu'en pensez-vous ? Après pas forcément l'utiliser sur ce filtre là en particulier, mais peut-être qu'elle pourrait servir sur d'autres filtres actuels ou à venir, principalement les filtres luttant contre le spam/spambot du coup. ShifaYT ✉Tchater 18 août 2024 à 14:27 (CEST)

Salut. Quelle nouvelle option captcha ? Tu n'es pas assez explicite. 'toff ^[discut.] 18 août 2024 à 19:14 (CEST)

Autant pour moi je n'ai pas détaillé plus ; c'est une nouvelle fonctionnalité (cf. docu mediawiki et actus techniques sur méta) qui a comme effet d'afficher un CAPTCHA à résoudre lorsqu'un utilisateur déclenche un filtre avec cette option activée, à l'instar des actions comme empêcher la modification, baliser la modification, et bien celle-ci permet d'obliger l'utilisateur à réalisé un CAPTCHA s'il souhaite que sa modification soit publiée/confirmée ; c'est la dernière option dans la section "Actions entreprises en cas de détection" :

[...]

- "[-] Baliser la modification pour une relecture ultérieure"

- "[-] Nécessite que l'utilisateur doive résoudre un CAPTCHA afin de poursuivre l'action. Les utilisateurs autorisés à ignorer le CAPTCHA en sont exemptés."

Du coup je pensais qu'elle pourrait être utile pour lutter contre le spam/spambot car elle obligerait la réalisation d'un CAPTCHA anti-robot pour que des modifications suspectées d'être du spam/spambot soit publiées ; si le CAPTCHA n'est pas réalisé la modification n'est pas approuvée par le filtre. Dis moi si c'est plus clair @Supertoff . ShifaYT ✉Tchater 18 août 2024 à 20:32 (CEST)

Sur le principe, je dirais oui. De ce que je comprends, c'est que l'extension ConfirmEdit est à priori présente à partir de MediaWiki 1.18 (donc sur WP.fr ?) et qu'il fait utiliser un des modules présents ici (FancyCaptcha me semble correspondre à ce qui se fait souvent sur différents sites web). Il faudrait aussi que Extension:AbuseFilter/Rules format soit mis à jour. Dit moi si j'ai bon ? 'toff ^[discut.] 18 août 2024 à 20:50 (CEST)

C'est cela oui @Supertoff ! Je vais essayer de voir si je peux utiliser un filtre de test pour tester ou trouver un autre moyen de faire un essai. ShifaYT ✉Tchater 18 août 2024 à 21:50 (CEST)

Du coup j'ai pu testé sur le wiki de test2. En cas de déclenchement d'un filtre avec l'option CAPTCHA, il y a un CAPTCHA à texte qui s'affiche en bas de la fenêtre pour enregistrer une modification (juste en bas de la zone de saisie du résumé), l'IP (ou l'utilisateur non autoconfirmé) doit entrer le texte qu'il voit sur l'image du CAPTCHA pour pouvoir publier sa modification. Donc c'est FancyCaptcha @Supertoff  ! À priori donc, il pourrait être intéressant de voir pour s'en servir pour le spam/spambot. ShifaYT ✉Tchater 20 août 2024 à 10:29 (CEST)

Ok pour moi. A voir peut-être avec les autres collègues qui ont modifié ce filtre. 'toff ^[discut.] 20 août 2024 à 17:29 (CEST)

Je soutiens grandement, déjà au moins pour tester, surtout que c'est très facile à mettre en œuvre (juste une case à cocher). En général je déteste les captchas (comme tout le monde), à part lorsqu'ils sont pertinents, et je pense que présentement ceux-ci seraient vraiment appropriés.

Cela permettrait de soulager de la crainte des FP, ce qui serait justement très indiqué dans le cas de ce filtre 321 et de l'enfer pour l'affiner (j'ai encore en local des essais bien complexes pour réduire les FP tout en continuant d'avoir un bon niveau de détection).

La documentation indique que les captchas disponibles seraient assez peu efficaces contre les bots, mais on peut espérer que des bots de faible qualité tels que le pénible ciblé par le filtre 321 n'aient pas de système anticaptcha, à voir.

od†n ↗^blah 20 août 2024 à 19:43 (CEST)

+1, pour ce filtre. — Jules* ^discuter 23 août 2024 à 11:18 (CEST)

 LD et NB80 : Je vous mentionne car vous avez aussi édité le filtre 321. Seriez-vous pour un essai de l'option CAPTCHA sur ce filtre ? ShifaYT ✉Tchater 23 août 2024 à 12:06 (CEST)

@ShifaYT, feu vert LD (d) 24 août 2024 à 21:47 (CEST)

 Fait. ShifaYT ✉Tchater 25 août 2024 à 07:57 (CEST)

Un peu en retard mais +1 pour essayer et faire un bilan dans quelques semaines ou mois. — Antimuonium ^discuter 25 août 2024 à 10:17 (CEST)

Mauvaise nouvelle : les dernières détections montrent que ce p*tain de bot arrive à passer le captcha. od†n ↗^blah 3 septembre 2024 à 22:23 (CEST)

Détection des reverts

Hello,

Cf. filtre 214, son contournement opéré par Je suis la pour contribuer (d · c · b), et phab:T159725. Si quelqu'un a une idée, en attendant un miracle du côté de MW… — Jules* ^discuter 3 septembre 2024 à 19:27 (CEST)

Hmm, pouvoir faire appel aux balises serait le top mais je n'ai pas l'impression que ce soit trop d'actualité vu les changements que cela demanderait... Et comme nous ne pouvons pas non plus accéder au contenu de la révision précédente (pour comparer)... On peut aussi faire appel à des sous-chaînes mais quelqu'un de motivé finira toujours par contourner le filtre. D'ailleurs, je pense que la WP en anglais a le même problème. (Réponse peu aidante, je le sais, mais au moins je ne laisse pas le message de Jules* seul ). — Antimuonium ^discuter 4 septembre 2024 à 01:35 (CEST)

Filtre 214 : extension aux IP

Hello,

Pour info, j'ai élargi le périmètre du filtre 214 aux IP à la suite de cette requête connexe.

— Jules* ^discuter 22 septembre 2024 à 16:51 (CEST)

Hello, ça marche. Merci encore @Jules* ! ShifaYT ✉Tchater 22 septembre 2024 à 16:55 (CEST)

Bilan du filtre 321 avec l'option CAPTCHA

Détections du filtre 321 du 26 août 2024 au 5 octobre 2024 :

• 36 modifications détectées avec l'option CAPTCHA (100%)
• 23 modifications bloquées au total sans considération de la suite (63,9%)
• 18 modifications bloquées mais acceptées par la suite avec la validation du CAPTCHA (50%)
• 13 modifications acceptées au total sans considération des essais (36,1%) dont 9 révoquées (69,2%)
• 5 modifications bloquées et sans validation du CAPTCHA par la suite (13,9%)
• 3 modifications acceptées avec la validation directe du CAPTCHA (8%) dont 3 révoquées (100%)

 Supertoff, Od1n, Jules*, LD et Antimuonium : Je vous mentionne en tant que partcipant à la discussion initiale pour tester l'option . ShifaYT ✉Tchater 6 octobre 2024 à 10:32 (CEST)

Demande de récupération des Outils d’AF

Bonsoir, Il y a maintenant un an, j’ai demandé à ce que me l’on me les retire, car mon temps libre était limité et Wikipédia ne m’intéressait plus trop, mais désormais Wikipédia recommence à m’intéresser, principalement la patrouille, (filtres, etc) (je suis Félix felines) j’ai juste demandé à changer de pseudo pour une raison personnelle

cordialement Melanthos ^{(Συζητώ)} 17 octobre 2024 à 23:10 (CEST)

J'ai transféré ton message sur le WP:BB @Melanthos . ShifaYT ✉Tchater 18 octobre 2024 à 09:27 (CEST)

Merci Melanthos ^{(Συζητώ)} 19 octobre 2024 à 09:21 (CEST)

Mise à jour des filtres en vue de l'arrivée des comptes temporaires

Hello,

Je compte commencer tranquillement à mettre à jour les filtres suivant les consignes indiquées ici. Exemple (seul remplacement que j'ai entrepris pour l'instant). Est-ce que vous y voyez un inconvénient ?

Ping @Supertoff, @Antimuonium, @ShifaYT, @LD et @Od1n. — Jules* ^discuter 3 septembre 2024 à 19:48 (CEST)

 Jules* : Hello, pas de soucis pour moi, et surtout merci d'avoir commencé à procéder à la mise à jour des filtres . ShifaYT ✉Tchater 3 septembre 2024 à 20:06 (CEST)

 Jules* : avant tout, tu peux ré-expliquer (car je ne suis pas du tout toutes les avancées mediawiki) ce qui va se passer pour les IP ? De ce que j'ai cru comprendre, les IP ne vont plus être affichées et à la place il y aura un nom générique de contributeur ? Quand ça va se passer ? Est-ce que ces noms génériques sont réutilisables (i.e. sont-ils temporairement attribués puis réattribués ?) Je dois avoir d'autres questions qui ne me viennent pas pour l'instant. 'toff ^[discut.] 3 septembre 2024 à 20:25 (CEST)

@Supertoff : tu as plein d'infos sur WP:Remplacement des adresses IP par des comptes temporaires, mais pour te répondre rapidement : oui, c'est ça, nom générique à la place des IP. Quand ? Dans quelques mois, sans doute plutôt en 2025. Non, les noms ne sont pas réutilisables. — Jules* ^discuter 3 septembre 2024 à 20:42 (CEST)

OK merci. Du coup, certains filtres ne seront plus fonctionnels car ils ciblent "spécifiquement" certaines plages d'IP ? Comment gérer ces cas ? (un exemple au hasard : le filtre 29) ? 'toff ^[discut.] 3 septembre 2024 à 20:51 (CEST)

Sous réserve que je comprenne bien, on pourra toujours cibler des IP (et des plages) via les filtres, via user_unnamed_ip, avec un code du type user_unnamed_ip irlike "^110\.25\.". C'est simplement que ip_in_range et user_name ne seront plus fonctionnels. (Par ailleurs, en tant qu'AF nous pourrons voir les IP utilisées par les comptes temporaires, donc nous serons toujours en mesure d'identifier des plages problématiques.) — Jules* ^discuter 3 septembre 2024 à 21:20 (CEST)

Et a priori je comprends bien : phab:T357772#9964850 confirme. Le filtre 29 fonctionnera à l'identique. — Jules* ^discuter 3 septembre 2024 à 21:23 (CEST)

Va falloir s'habituer de toute façon 'toff ^[discut.] 3 septembre 2024 à 22:47 (CEST)

À noter que pour l'instant, user_unnamed_ip ne peut pas encore être utilisé, cf. phab:T369610. — Jules* ^discuter 3 septembre 2024 à 23:08 (CEST)

Bonjour  Jules*. Merci d'attirer notre attention là-dessus. Sais-tu si les réflexions sont assez matures pour que nous commencions à effectuer des changements ? J'ai l'impression qu'ils essaient déjà de se dépatouiller de manière globale avec les comptes temporaires et que les réflexions commencent à peine sur les filtres (pas mal de tâches Phabricator depuis juillet). J'imagine que ton idée est de partir des quelques préconisations, faire quelques tests ici (comme WP:fr s'est proposé en tant que wiki pilote), leur faire des retours si nécessaire, mais sans modification à grande échelle de nos filtres pour le moment ? D'accord avec le début de ton message : « commencer tranquillement ». — Antimuonium ^discuter 4 septembre 2024 à 00:04 (CEST)

C'est simplement que ip_in_range et user_name ne seront plus fonctionnels : sauf erreur, user_name continuera de fonctionner mais uniquement pour les utilisateurs enregistrés tandis qu'il faudra utiliser user_unnamed_ip pour les adresses IP.

Tout ne semble pour le moment pas 100 % clair (et tout est « subject to change ») mais j'ai espoir de voir une communication sur les modifications à apporter aux filtres (pas trop tard, une fois que les réflexions auront avancé). — Antimuonium ^discuter 4 septembre 2024 à 00:12 (CEST)

Bonjour, pas d'inconvénient.

@Antimuonium, les équipes CU ont été solicitées il y a un mois à peu près (à la fois pour des tests et des retours), ce que je peux en dire c'est que cela a bien progressé car nous avons une "visibilité" sur les tâches.

Normalement, cette tâche devrait être prise en charge avant le déploiement sur les wikipilots, ou à peu près dans le même temps. De ce que je comprends du calendrier, l'extension CU doit d'abord être terminée (il reste 4 tâches directes, davantage dans temporary account IP reveal) pour envisager un déploiement sur les wikipilots mais il y a du retard sur le sprint. En tout cas, les AF n'auront accès à rien tant que cette tâche ne sera pas résolue (mais Legal a déjà clarifié la Politique, donc ce n'est plus qu'une question de "droit de statut" à écrire dans la configuration des wikis).

Si besoin je peux demander à l'équipe de préciser le calendrier, poser des questions ou remonter des infos. LD (d) 4 septembre 2024 à 05:37 (CEST)

@Antimuonium : oui, pour user_name, c'est ça, j'ai fait un raccourci car dans le contexte nous parlions des IP.

Effectivement, tout n'est pas encore totalement définitif, surtout du côté de user_unnamed_ip, car pour le reste ça semble assez stable. Mais l'air de rien le projet a l'air de bien avancer (déploiement récent sur le Test2wiki, notamment), et @LD semble confirmer ça.

Pour l'instant, je vais déjà m'occuper du remplacement de user_age. — Jules* ^discuter 5 septembre 2024 à 23:21 (CEST)

┌─────────────────────────────────────────────────┘
Petite update : user_unnamed_ip peut désormais être utilisé par les utilisateurs possédant le droit abusefilter-access-protected-vars, moyennant une case à cocher dans les préférences. Tout filtre utilisant cette variable devient définitivement (même en cas de retrait de ladite variable) inaccessible aux modificateurs de filtres ne possédant pas le droit en question.

Pour le moment, ce droit n'est attribué (pour ce qui nous concerne) qu'aux Abusefilters Helpers (AFH), à savoir, chez nous, parmi les AF actifs, @Supertoff et @ShifaYT et moi-même (il y a aussi NoFWDaddress et Hégésippe Cormier). À terme, il doit être attribué aussi aux admins (cf. phab:T369610).

Tant que le droit n'est pas distribué aux admins, et afin d'éviter que des filtres ne soient plus accessibles qu'à trois AF, je propose que nous sursoyions au remplacement de user_name par user_unnamed_ip dans les filtres existants.

— Jules* ^discuter 17 octobre 2024 à 13:09 (CEST)

Je suis d'accord, +1. ShifaYT ✉Tchater 17 octobre 2024 à 16:32 (CEST)

Merci des infos @Jules*. En "procédure", admin et AF ont été dissociés mais pas nettement en droit (les admins en conservent divers). Je ne trouve pas que confier abusefilter-access-protected-vars aux admins soit localement pertinent (on peut être AF sans être admin ...), même si je comprends aisément que c'est transitoire, fait à l'image de méta.

De fait, y'a-t-il des objections à ce que j'ouvre une section dédiée et/ou un sondage sur une "réforme" des droits ? LD (d) 17 octobre 2024 à 17:45 (CEST)

Je pense (sans aucune certitude) que seuls les admins qui sont AF pourront vraiment bénéficier du droit abusefilter-access-protected-vars, sans quoi ça n'aurait effectivement pas grand sens @LD. Quant au fait que les AF non admins n'y auraient pas accès, c'est encore un autre sujet. Dans tous les cas, je pense qu'il est prématuré de prendre une quelconque initiative de réforme motivée par l'arrivée des comptes temporaires. Mais peut-être ai-je mal compris ce que tu proposais. — Jules* ^discuter 17 octobre 2024 à 18:05 (CEST)

@Jules* Les développeurs donnent toujours les droits aux admins car c'est le choix par défaut pour le logiciel Mediawiki. Sauf que, comme beaucoup de wikis, on réattribue les droits parmi des groupes, dont un dédié.

Ce que je veux dire : c'est davantage une question de "choix par défaut" que nous devrions communiquer aux développeurs. Que ce soit pour le droit abusefilter-modify-blocked-external-domains, ou même abusefilter-access-protected-vars, il aurait fallu que la communauté soit consultée. LD (d) 17 octobre 2024 à 22:27 (CEST)

En résumé, ces droits auraient dû, dans le contexte de notre wiki, être attribués aux AF et non aux admins ; si c'est ça, pas besoin de sondage à mon sens, ce n'est pas sujet à controverse, une simple discussion suffit. Sauf pour abusefilter-modify-blocked-external-domains : l'usage sur fr-wp est que les admins puissent modifier MediaWiki:Spam-blacklist, il est donc logique qu'ils puissent modifier Spécial:BlockedExternalDomains. — Jules* ^discuter 18 octobre 2024 à 11:27 (CEST)

┌─────────────────────────────────────────────────┘
 Jules* : je dois être fatigué, j'ai rien compris...

• Dans mes préférences, j'ai vu la case à cocher "Enable revealing IP addresses for temporary accounts in AbuseFilter" (je suppose que c'est ça "abusefilter-access-protected-vars" ?) Et où et comment un contributeur (qui n'est pas AF) peut-il utiliser user_unnamed_ip ?
• "Tout filtre utilisant cette variable devient définitivement (même en cas de retrait de ladite variable) inaccessible aux modificateurs de filtres ne possédant pas le droit en question" : à partir de quand ? Si c'est déjà le cas c'est trop tard non ? Et quel rapport avec les contributeurs ayant coché la case ?

Vraiment rien compris... 'toff ^[discut.] 17 octobre 2024 à 18:37 (CEST)

• Oui, c'est ça : c'est parce que en tant qu'Abusefilter helper (droit global) tu as le droit abusefilter-access-protected-vars que la case apparaît et que tu peux la cocher. Un utilisateur qui n'est pas AF ne peut pas utiliser user_unnamed_ip. Seuls les AF qui ont le droit abusefilter-access-protected-vars et qui ont coché la case dans leurs préférences peuvent utiliser cette variable.
• À partir de tout de suite. C'est trop tard... si on l'utilise. Pour l'instant on ne l'a pas utilisée (), donc tout va bien. Le rapport avec les utilisateurs ayant coché la case, c'est que seuls eux peuvent utiliser cette variable et consulter les filtres qui l'utilisent ou l'ont utilisé.

Dis-moi si c'est plus clair, @Supertoff. — Jules* ^discuter 17 octobre 2024 à 18:46 (CEST)

 Jules* : un poil plus clair avec la précision dans ta première phrase d'explication « par les utilisateurs AF possédant le droit abusefilter-access-protected-vars, moyennant une case à cocher dans les préférences ». Mais je ne comprends pas comment on peut ou pas utiliser une variable ? L'écriture dans les filtres est "libre". Pour moi la limitation est liée aux filtres pas aux contributeurs. Après si par "utiliser user_unnamed_ip", tu veux écrire "voir le code du filtre qui l'utilise" alors là ou, je comprends mieux. 'toff ^[discut.] 17 octobre 2024 à 19:17 (CEST)

@Supertoff : « L'écriture dans les filtres est "libre". » Si un AF qui ne possède pas le droit abusefilter-access-protected-vars insère la variable user_unnamed_ip dans un filtre, au moment de sauvegarder le filtre, il en sera empêché et un message d'erreur s'affichera. J'en ai fait l'expérience en tant ça dans un filtre de test sans avoir coché la case idoine dans mes préférences. — Jules* ^discuter 17 octobre 2024 à 19:43 (CEST)

Ah ok. C'est une fonction qui n'existe que sur cette variable alors ? Et c'est quoi l'utilité finale ? 'toff ^[discut.] 17 octobre 2024 à 20:47 (CEST)

@Supertoff L'objectif affiché est la restriction des informations confidentielles (l'accès aux IPs) en n'y donnant pas accès par défaut (d'où une case à cocher). LD (d) 17 octobre 2024 à 22:08 (CEST)

 LD : merci, c'est clair.  Jules* : pour en revenir à ta question initiale, ça me paraît évidemment logique. Une dernière question (j'espère) : quand tu dis Tout filtre utilisant cette variable devient définitivement (même en cas de retrait de ladite variable) inaccessible aux modificateurs de filtres ne possédant pas le droit en question, est-ce qu'à l'inverse l'obtention du droit permet de redonner l'accessibilité à ces filtres, ou est-ce que le "définitif" reste "définitif" ? 'toff ^[discut.] 19 octobre 2024 à 10:55 (CEST)

L'obtention du droit permet en effet d'y avoir accès, @Supertoff. Par « définitif », je voulais dire que retirer la variable du filtre ne le rend pas de nouveau accessible aux AF ne possédant pas le droit (car l'historique du filtre et le journal des filtrages contiennent des IP). Bon week-end ! — Jules* ^discuter 19 octobre 2024 à 11:13 (CEST)

Chiant le français : faut bien choisir ses mots 'toff ^[discut.] 19 octobre 2024 à 11:20 (CEST)

 Jules* : Hello, je viens de voir que les sysops ont désormais le droit abusefilter-access-protected-vars. ShifaYT ✉Tchater 29 octobre 2024 à 15:54 (CET)

Accès aux filtres protégés pour les AFs

Enregistré sur Phabricator
Tâche 381722

• Nom du proposant : ShifaYT (d · c · b) 30 novembre 2024 à 18:40 (CET)
• Argumentation :

(fr) Bonsoir, sur la même impulsion que nos collègues anglophones , je propose l'ajout logique de la permission abusefilter-access-protected-vars aux AFs locaux de notre wiki à la place des admins, qui ne l'ont pas par défaut avec l'ajout automatique des permissions (donnée aux sysops par défaut car sur la plupart des wikis ils gèrent AbuseFilter mais ce n’est pas le cas ici), afin de faire remonter ça sur Phabricator pour permettre aux développeurs d'implémenter la permission à ce groupe techniquement ; mais il faudrait avant ça un consensus par souci de formalité, comme fait sur enwiki.

(en) Hello, on the same impulse of our English-speaking colleagues , I suggest the logical addition of the abusefilter-access-protected-vars permission for local EFMs on our wiki instead of sysops, that don't have it by default (given only for sysops by default because they handle AbuseFilter on most wikis but it’s not the case here), in order to create a ticket on Phabricator to allow devs to implement the permission for this group technically; but before that, we should get a consensus for the sake of formality, as done on enwiki.

• Remarque : Ce droit permet de modifier et d'accéder aux filtres utilisant la variable user_unnamed_ip, c'est-à-dire utilisant des IPs (lorsque les comptes temporaires seront déployés).
• Lien connexe : cf. mw:Extension:AbuseFilter/Rules format#Protected_variables (documentation en anglais sur les variables protégées)
• Mentions :  Antimuonium, Jules*, Kirham, LD, NB80, Od1n et Supertoff (AFs ayant modifié les filtres récemment ou étant intervenus récemment ici)
• Clôture : au plus tôt le 7 décembre 2024 18:40 CET (7 jours me semble raisonable)

Discussions ( Ouvert à tous même aux non AFs, donc intervention possible pour tout contributeur sur ce sujet du BF)

• Pour, en tant que proposant. Shifa ✉Tchater 30 novembre 2024 à 18:40 (CET)
• Pour évidemment, pas de raison que ce soit limité aux admins, puisque sur ce wiki on a un statut AF dédié. — Jules* ^discuter 30 novembre 2024 à 19:35 (CET)

  @Jules* (Re)hello, j’ai rajouté de retirer le droit pour les sysops du coup. Shifa ✉Tchater 1 décembre 2024 à 00:17 (CET)

  Yes, parfait. — Jules* ^discuter 1 décembre 2024 à 00:19 (CET)

• Pour par la même occasion le retirer aux admins (ça ne leur sert à rien). LD (d) 30 novembre 2024 à 22:18 (CET)
• Pour mais cela veut dire, si j'ai bien suivi, que les AFs non admins devront par cohérence respecter les critères d'accès aux IP fixés par la communauté. — Antimuonium ^discuter 1 décembre 2024 à 13:01 (CET)

  Pas sûr : c'est une attribution technique de droit, c'est juste que chez nous tous les admins ne sont pas AF et tous les AF ne sont pas admins. Mais si je me trompe et que c'est bel et bien le cas, ce n'est pas un souci àmha : l'accès AF n'est donné qu'aux utilisateurs expérimentés, en pratique. À clarifier avec la WMF. — Jules* ^discuter 1 décembre 2024 à 13:09 (CET)

• Pour Pour renforcer le consensus, et parce qu'il me semble plus logique d'attribuer ce droit aux AF plutôt qu'aux administrateurs, les premiers ayant déjà accès à diverses informations sensibles contenues dans les filtres. od†n ↗^blah 7 décembre 2024 à 07:43 (CET)

Résultat
Consensus unanime pour attribuer le droit abusefilter-access-protected-vars aux AFs et le retirer aux administrateurs. ShifaYT ✉Tchater 7 décembre 2024 à 18:42 (CET)