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 ?
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)[répondre]
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)[répondre]
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*discuter3 septembre 2024 à 21:20 (CEST)[répondre]
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 ». — Antimuoniumdiscuter4 septembre 2024 à 00:04 (CEST)[répondre]
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.
@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).
@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.
┌─────────────────────────────────────────────────┘
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.
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)[répondre]
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*discuter17 octobre 2024 à 18:05 (CEST)[répondre]
@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)[répondre]
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*discuter18 octobre 2024 à 11:27 (CEST)[répondre]
┌─────────────────────────────────────────────────┘ 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 ?
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 ([1]), 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é.
Jules* : un poil plus clair avec la précision dans ta première phrase d'explication « par les utilisateursAF 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)[répondre]
@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*discuter17 octobre 2024 à 19:43 (CEST)[répondre]
@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)[répondre]
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)[répondre]
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*discuter19 octobre 2024 à 11:13 (CEST)[répondre]
(fr) Bonsoir, sur la même impulsion que nos collègues anglophones [2], 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 [3], 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).
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*discuter1 décembre 2024 à 13:09 (CET)[répondre]
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 ↗blah7 décembre 2024 à 07:43 (CET)[répondre]
