In the recent months, we heard concerns from patrollers about the additional time they needed to spend when dealing with abusive behavior. To ensure temporary account vandalism can be sustainably managed, we have decided to make it easier for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
We are starting by surfacing clusters of related temporary accounts to patrollers. We are also exploring other interventions that could improve early identification and rapid response. At the same time, our colleagues from the Moderator Tools team are working on deploying the Automoderator tool to more wikis. They will also evaluate its impact in reducing the amount of vandalism by temporary accounts that human patrollers need to deal with.
Regarding the clusters of temporary accounts, we have just introduced a few new features:
On Special:Contributions, upon checking contributions of a temporary account, users with access to temporary account IP addresses can now see a view of contributions from the related temporary accounts. The feature looks up all the IPs associated with a given temporary account within the data retention period and shows all the contributions of all temporary accounts that have used these IPs. Users can also see this by checking "Show contributions from related temporary accounts" in the search section.
On Special:Contributions, Special:GlobalContributions, and Special:IPContributions, all users with access to these pages can see a new line: "Temporary accounts from all associated IPs", or " Temporary accounts on this IP". This provides information about the expected amount of time needed to patrol all associated contributions.
: derniers déploiements et assistance continue dans les mois à venir
Impact des comptes temporaires
Nous sommes heureux d'annoncer qu'environ 96 % des modifications non enregistrées sur l'ensemble des wikis Wikimedia sont désormais effectuées à partir de comptes temporaires. Il y a six mois, ce chiffre était trois fois moins élevé. Nous sommes reconnaissants envers de nombreux membres de la communauté, en particulier les stewards et les bureaucrates de Wikipédia en anglais. Ils nous aident à améliorer les nouvelles fonctionnalités et nous avons établi des relations très étroites avec eux au cours des derniers mois.
Nous suivons actuellement l'impact des comptes temporaires sur l'activité des utilisateurs, les blocages et la création de comptes. Nous n'avons constaté aucune tendance préoccupante, telle qu'une augmentation relative des modifications annulées ou une diminution des inscriptions de comptes. Nous avons toutefois remarqué une nouvelle tendance en matière de blocages. La proportion de blocages effectués pour des comptes temporaires a augmenté, tandis que la proportion de blocages effectués pour des adresses IP/plages d'adresses IP a diminué (voir l'analyse ici). Si cette tendance se maintient, nous espérons que cela permettra de réduire le nombre d'éditeurs potentiels bloqués de manière collatérale.
Prochaines étapes
Dans le même temps, même si les comptes temporaires fonctionnent généralement comme prévu, nous reconnaissons que cela engendre de nouveaux coûts pour ceux qui luttent contre les abus. Notre prochain objectif est de rendre les outils de lutte contre les abus plus précis et plus efficaces. Si vous avez des suggestions de modifications à apporter, n'hésitez pas à nous contacter sur la page de discussion de l'équipe.
Retour sur les dernières améliorations apportées à nos fonctionnalités
Résultats de l'enquête menée en août et discussions ultérieures avec les contributeurs de Wikipédia en anglais
Analyse du sondage envoyé à 18 communautés
En août, nous avons contacté les communautés des grands wikis où des comptes temporaires avaient été créés afin de connaître leur avis sur ces changements. Nous avons diffusé un sondage sur 18 wikis, notamment en chinois, français, allemand et japonais. 337 personnes ont répondu au sondage, dont 63 % disposaient de droits étendus (le plus souvent, ceux d'administrateur). Voici l'analyse complète, dont émergent les points forts suivants :
81 % ont répondu « oui » lorsqu'on leur a demandé s'ils comprenaient les raisons qui ont motivé l'introduction des comptes temporaires.
38 % se sont dits au moins « très satisfaits », 37 % ont déclaré être modérément satisfaits et 25 % ont déclaré être peu satisfaits des fonctionnalités.
Un petit nombre de commentaires négatifs provenaient d'utilisateurs de comptes temporaires qui ont déclaré souhaiter des restrictions plus strictes concernant les personnes autorisées à consulter les adresses IP afin de mieux protéger leur vie privée.
58 % des répondants ont déclaré que les comptes temporaires ne perturbaient pas leurs tâches. La majorité des commentaires négatifs portaient sur la façon dont les comptes temporaires perturbaient les tâches : il était plus difficile de trouver et de bloquer les faux comptes, les comptes temporaires offraient aux vandales un nouveau moyen de « se cacher » et il fallait plus de temps pour traquer le vandalisme IP (remarque : certains utilisateurs n'avaient pas accès aux adresses IP au moment où ils ont répondu à l'enquête).
En marge de l'analyse des résultats de l'enquête, nous avons commencé à multiplier les échanges avec les responsables de Wikipédia en anglais. Les résultats de l'enquête et ces échanges ont permis d'améliorer certaines fonctionnalités, au bénéfice de tous les wikis.
Mises à jour des fonctionnalités visant à réduire l'impact de la création et de la désactivation temporaires de comptes
Nous constatons une forte augmentation du nombre de comptes temporaires. La plupart sont créés intentionnellement mais, dans certains cas, il s'agit d'éditeurs qui se déconnectent par erreur ou qui se déconnectent systématiquement après avoir effectué une modification, que ce soit de bonne ou de mauvaise foi. Nous avons apporté quelques modifications pour remédier à ce problème :
Étape de confirmation dans le flux de sortie de session pour les comptes temporaires (1 $) : nous voulions réduire le risque que les utilisateurs utilisent accidentellement trop de comptes en sortant de leur session. Cela devrait contribuer à rendre la communication avec les utilisateurs de comptes temporaires plus prévisible.
Au départ, la limite de fréquence était identique à celle des comptes enregistrés, mais elle n'était pas suffisante :
« Prise en charge de la plage IPv6 /64 » (2 $) : les limites de création de comptes temporaires s'appliquent désormais à la fois à une seule adresse IPv4 et à une plage /64 pour IPv6.
« Période de réflexion de 10 minutes entre les créations » (3 $) : si l'utilisateur A crée un compte temporaire pour vandaliser et tente de passer rapidement à un nouveau compte temporaire, il devra attendre au moins 10 minutes entre deux créations de compte.
« Inciter les utilisateurs temporaires qui ont atteint la limite de fréquence à créer un compte » (4 $) : nous voulions aider ceux qui, en raison de ces changements, sont découragés d'effectuer des modifications de bonne foi.
Modifications apportées à l'utilitaire anti-abus
Prolongation de la durée maximale de la divulgation automatique de l'adresse IP : nous avions mis en place la fonctionnalité de divulgation automatique de l'adresse IP pour les utilisateurs qui effectuent des patrouilles très fréquentes, afin de leur faciliter l'accès aux adresses IP des comptes temporaires. Cette fonctionnalité peut désormais être activée pour une durée maximale de 90 jours.
Groupes de numéros différenciés pour les comptes temporaires provenant de toutes les adresses IP associées dans la fiche d'informations utilisateur (T412212) : auparavant, si plus de 11 comptes temporaires partageaient une adresse IP, la fonctionnalité Informations utilisateur affichait « 11+ ». Étant donné que la gestion d'un groupe de 12 comptes temporaires fonctionnant à partir d'adresses IP partagées est différente de celle de 50 ou 100 comptes, nous avons souhaité fournir des informations plus utiles aux patrouilleurs et avons donc introduit davantage de catégories.
Autres modifications connexes : nous avons apporté quelques modifications mineures afin de faciliter la tâche aux patrouilleurs. Il s'agit notamment de l'ajout de Afficher l'adresse IP à Special:GlobalContributions ($1), de l'ajout d'un lien vers une plage /64 sur Special:IPContributions lors de la divulgation d'une adresse IP IPv6 ($2), de l'ajout de liens vers les plages /16, /24 et /32 sur Special:IPContributions ($3), de l'ajout d'un lien vers le journal des abus lors de la consultation des plages d'adresses IP ($4) et de l'ajout de liens dans le menu Outils ($5).These include adding a link to a /64 range on Special:IPContributions when revealing an IPv6 IP (T411943), adding links to /16, /24, and /32 ranges on Special:IPContributions (T409179), including a link to the abuse log when viewing IP ranges (T412341), and adding links in the Tools menu (T405568).
Autres modifications des fonctionalités
Révocation automatique du droit TAIV (« Temporary account IP viewer », visualisation des adresses IP des comptes temporaires) des utilisateurs inactifs (T375115) : les utilisateurs inactifs depuis plus d'un an devront demander à nouveau ce droit. L'inactivité est définie comme l'absence de modifications ou d'actions enregistrées. Cela ne s'applique pas aux utilisateurs qui obtiennent l'accès dans le cadre d'autres droits, comme les administrateurs.
Arrière-plan des noms d'utilisateur temporaires dans les pages de contenu et de discussion (T392775) : afin de faciliter l'identification immédiate des comptes temporaires, un arrière-plan coloré apparaît sur les pages de contenu, comme c'est le cas sur les pages de type journal telles que les modifications récentes ou la liste de suivi.
Option d'expiration par défaut pour le blocage des comptes temporaires (T398626) : le blocage indéfini des comptes temporaires peut encombrer inutilement la page Special:BlockList, car les comptes temporaires ne durent que 90 jours. Pour éviter cela, les communautés peuvent définir une autre durée d'expiration par défaut, par exemple 90 jours.
Les comptes temporaires utilisant des adresses IP bloquées peuvent demander leur déblocage (T398673) : les contributeurs non enregistrés utilisant des adresses IP ou des plages d'adresses IP bloquées peuvent demander leur déblocage en modifiant Special:MyTalk (de la même manière que cela fonctionnait avant l'introduction des comptes temporaires). Cette activité sera signalée afin d'informer les patrouilleurs qu'elle a été effectuée sur une adresse IP ou une plage d'adresses IP bloquée.
Notre communication concernant les comptes temporaires
Plus tôt cette année, nous avons créé des vidéos de formation pour mieux expliquer comment travailler avec des comptes temporaires :
Comment révéler les adresses IP
Comment fonctionne la révélation automatique
Nouvelle page spéciale : IPContributions
Comment utiliser les informations IP
Comment utiliser les informations utilisateur
Nous serions ravis de participer à des événements communautaires et à des ateliers pour vous présenter les nouvelles fonctionnalités. N'hésitez pas à nous faire part de votre intérêt, en particulier si vous pouvez nous mettre en relation avec des organisateurs d'événements communautaires. De plus, nous coordonnerons cela avec Movement Communications.
Anciennes mises à jour
: déploiement sur 18 Wikipédias de grande et moyenne taille, et nos projets pour les prochains mois
Déploiements récents – Au cours de la deuxième quinzaine de juin, nous avons déployé des comptes temporaires sur MediaWiki.org et 18 Wikipédias de taille moyenne à grande, notamment les versions française, allemande, chinoise, japonaise et bien d'autres encore. Vous trouverez la liste complète des wikis sur lesquels des comptes temporaires ont été déployés dans la FAQ. Nous remercions chaleureusement tous les bénévoles qui ont contribué au déploiement, que ce soit en mettant à jour AbuseFilter, en traduisant l'interface, en répondant aux questions des autres membres de la communauté, en rédigeant et en traduisant la documentation, en créant de nouveaux outils, etc. Nous exprimons notre gratitude à Albertoleoncio, DerHexer, Dragoniez, Ellywa, Hide on Rosé, Jules*, Johannnes89, Martin Urbanec, Matěj Suchánek, Msz2001, Neriah, NicoScribe, Titore, VZP10224, Ykhwong, *Youngjin et bien d'autres encore.
Impact des déploiements précédents – Dans une analyse récente, nous avons constaté que les comptes temporaires n'ont pas entraîné de changements significatifs sur les wikis pilotes. Le seul changement notable a été le passage du blocage basé sur l'adresse IP au blocage basé sur les comptes temporaires sur notre première série de wikis pilotes. Vous pouvez surveiller ce tableau de bord pour suivre les changements apportés par les comptes temporaires sur les projets où nous sommes déjà déployés.
Nouvelles pages de documentation – Deux nouvelles pages de documentation pourraient vous intéresser : Accès à l'adresse IP, qui explique tout ce qui concerne l'accès aux adresses IP des comptes temporaires, et Référentiel qui répertorie les nouveaux gadgets et scripts utilisateur. Sur cette dernière page, vous trouverez une nouvelle vidéo explicative sur la manière de modifier à l'aide d'un compte temporaire. Nous en créerons également au moins une autre pour les utilisateurs disposant de droits étendus, modérant l'activité des comptes temporaires.
Rencontres avec les communautés – Au cours des dernières semaines, nous avons rencontré plusieurs communautés : des contributeurs sud-asiatiques, des patrouilleurs de Wikipédia en français et des administrateurs de Wikipédia en japonais. Ces rencontres ont été utiles tant pour les membres de la communauté que pour l'équipe afin de planifier notre travail futur. Si votre communauté souhaite également nous rencontrer, veuillez envoyer un message à Sheila.
Travaux prévus dans les semaines à venir
Notre objectif pour cette phase est d'identifier les problèmes qui peuvent apparaître uniquement lors de l'utilisation à grande échelle de comptes temporaires. Nous sommes ravis de vous annoncer que ce travail progresse comme prévu. Vous pouvez vous abonner à la tâche T395134, analyse du déploiement des comptes temporaires dans les principaux projets pilotes, car cela a un impact sur la lutte contre les abus.
N'hésitez pas à informer Claudia si les comptes temporaires ont notablement entravé votre capacité à dissuader les comportements répréhensibles, vous ont aidé à mettre fin à des comportements indésirables ou ont facilité votre communication avec un utilisateur déconnecté.
Nous avons également reçu de nombreux commentaires et suggestions d'amélioration sur la page de discussion du projet. Nous documentons et hiérarchisons les prochaines tâches à accomplir en fonction de ces commentaires. Nous avons créé plusieurs tickets Phabricator depuis le déploiement. Vous pouvez les consulter sur ce tableau.
Plans pour les mois à venir – Le déploiement final sur tous les wikis restants est prévu pour septembre. Nous étudions différentes options pour limiter la portée de cette phase en procédant plus tôt au déploiement sur certains wikis. Veuillez écrire à Szymon si votre communauté souhaite disposer plus tôt (en juillet ou août) de comptes temporaires – nous inclurons volontiers votre wiki dans ces plans.
: modifications apportées à l'accès aux adresses IP des comptes temporaires, progrès réalisés sur les outils et fonctionnalités associés, et préparatifs en vue de nouveaux déploiements
Enquête de satisfaction sur le projet pilote – Nous avons mené une enquête afin d'évaluer l'impact du déploiement du projet pilote et de recueillir des commentaires sur les améliorations potentielles. Nous avons interrogé les stewards, les sysops globaux, ainsi que les CheckUsers et les administrateurs de 11 wikis pilotes mineurs. Nous avons été ravis d'apprendre que le niveau de satisfaction rapporté était modéré à élevé, et que les perturbations dans les flux de travail étaient faibles. Les idées qui y ont été partagées nous ont aidés à améliorer les fonctionnalités et la conception. Voir l'analyse complète.
Modifications apportées à l'accès aux adresses IP des comptes temporaires pour les utilisateurs qui ne disposent pas de droits étendus
Attribution manuelle : au départ, nous avons choisi des seuils numériques pour que les utilisateurs qui ne disposent pas de droits étendus puissent accéder aux adresses IP. Nous avons pris cette décision avant de déployer des comptes temporaires sur les wikis. Cependant, après avoir recueilli les commentaires issus de nos projets pilotes, nous avons réalisé que ces seuils étaient assez bas et qu'il était encore trop facile pour les acteurs malveillants d'accéder aux adresses IP des comptes temporaires. De plus, des acteurs extérieurs souhaitant accéder aux adresses IP pouvaient contacter les utilisateurs disposant de ce droit afin d'obtenir ces informations. Les comptes temporaires devraient améliorer de manière significative la confidentialité des éditeurs, nous avons donc décidé d'être plus restrictifs avant de déployer cette fonctionnalité sur les wikis avec de grandes communautés. C'est pourquoi nous avons mis à jour la politique et changé l'attribution de ce groupe de automatique à manuelle, effectuée par les administrateurs ou les stewards sur demande. Lisez le message complet que nous avons publié sur Meta-Wiki et 20 grandes Wikipédias.
Application technique : nous avons décidé d'empêcher techniquement l'attribution du groupe « Temporary account IP viewer » (Visualiseur d'adresses IP des comptes temporaires) aux comptes qui ne répondent pas aux critères. Les administrateurs pourront passer outre cette limitation. Voici la page du compte rendu de décision. Nous l'inclurons également dans la page Limites aux modifications de configuration.
Les prochains déploiements auront lieu en juin. À l'automne 2024, nous avons déployé avec succès des comptes temporaires sur de petits wikis. Depuis lors, les utilisateurs disposant de droits globaux ont commencé à voir comment les comptes temporaires fonctionnent dans la pratique et comment gérer les flux de travail inter-wikis. Nous sommes désormais prêts pour d'autres déploiements et, dans les semaines à venir, nous en discuterons avec les grandes communautés. Les communautés qui recevront des comptes temporaires en juin auront plus d'occasions et de temps pour suggérer des améliorations que celles qui bénéficieront de ce changement lors du dernier déploiement, plus tard dans l'année.
Modifications coordonnées avec le calendrier des nouveaux déploiements – Étant donné que les modifications suivantes dépendent de la modification de politique décrite ci-dessus et les unes des autres, nous les introduirons peu avant et après les prochains déploiements :
Accès aux informations IP sur les wikis avec comptes temporaires activés et Meta-Wiki – Les utilisateurs ayant accès aux adresses IP des comptes temporaires auront un accès complet à IP Info. Ceux qui n'ont pas accès aux adresses IP des comptes temporaires ne pourront pas utiliser IP Info. De plus, IP Info ne sera plus une fonctionnalité bêta et sera disponible en tant que fonctionnalité complète.
Accès aux informations IP sur les autres wikis – Cela ne change pas : les utilisateurs auto-confirmés auront un accès limité ; les utilisateurs disposant de droits étendus, tels que les administrateurs, auront un accès complet, et les informations IP resteront une fonctionnalité bêta jusqu'au déploiement des comptes temporaires.
Boîte de dialogue d'intégration (T373818) et Autoreveal (T374869) – Les fonctionnalités que nous avons mentionnées dans la mise à jour précédente seront également déployées au moment des nouveaux déploiements. La boîte de dialogue d'intégration sera affichée à tous les utilisateurs ayant accès à des adresses IP de comptes temporaires, à la fois sur les wikis où des comptes temporaires ont été déployés en 2024 et sur les wikis où les déploiements auront lieu en juin.
Statistiques sur les blocages sur les wikis pilotes – Nous avons recueilli des données sur le nombre de blocages d'adresses IP et de comptes avant et après le déploiement pilote. Nos résultats montrent que si le nombre de blocages de comptes enregistrés n'a pas changé, la plupart des autres blocages (environ 90 %) concernaient des comptes temporaires, et seulement 10 % environ étaient des blocages d'adresses IP. Cela semble confirmer notre hypothèse selon laquelle la plupart des activités abusives hors connexion peuvent être évitées grâce aux blocages de comptes, ce qui réduit considérablement les dommages collatéraux. Après les déploiements de juin, nous partagerons davantage de données.
'“'Special:MassGlobalBlock” – Nous avons créé une nouvelle page spéciale pour permettre aux administrateurs de bloquer plusieurs comptes et adresses IP à l'échelle mondiale. Cette fonctionnalité avait été demandée par les administrateurs en 2016. Nous nous sommes inspirés d'un gadget existant. Elle aide désormais les administrateurs à lutter plus efficacement contre les abus commis par des comptes temporaires et enregistrés. (T124607)
Mise à jour de la FAQ et de la documentation – Compte tenu de tous ces changements, nous avons mis à jour la FAQ afin d'y inclure l'attribution manuelle du groupe d'adresses IP des comptes temporaires et de donner plus de détails sur la patrouille rétroactive. Nous allons également reformuler la partie concernant la motivation du projet. Au cours des prochaines semaines, nous apporterons d'autres modifications à la documentation.
Nos projets pour le prochain exercice financier – Nous vous invitons à lire la version finale du plan annuel 2025/2026, et plus particulièrement la partie décrivant notre travail : résultats-clefs WE4.1 (système de signalement des incidents), WE4.2 (améliorations des outils anti-abus), WE4.4 (comptes temporaires) et WE4.5 (évaluation des risques et des opportunités liés à l'IA). Partagez vos commentaires sur la page de discussion jusqu'au 31 mai.
: Déploiement réussi sur les wiki pilotes et progression sur les fonctionnalités
Comme prévu, à la fin octobre et dans les premiers jours de novembre, nous avons lancé des comptes temporaires pour 12 projets. Nous sommes heureux de signaler que nous n'avons rencontré aucun problème qui nous a obligés à renverser le déploiement. Il y a beaucoup d'activité provenant de comptes temporaires sur ces projets. Nous sommes actuellement en train de collecter des données détaillées et publierons un rapport présentant nos conclusions à ce sujet dans les prochaines semaines. Nous mènerons également une enquête afin de mieux comprendre l'impact de ce déploiement sur les utilisateurs disposant de droits avancés. Un grand merci aux communautés des wikis pilotes, aux stewards, aux CheckUsers et aux sysops globaux pour leur ouverture d'esprit, leurs questions pertinentes et leurs propositions de changements.
Nous mettons en place une boîte de dialogue d'intégration afin d'aider les utilisateurs enregistrés à comprendre les comptes temporaires et les fonctionnalités associées. La boîte de dialogue présentera le concept des comptes temporaires, l'outil IP Info avec la fonctionnalité de révélation d'adresse IP, et plus encore. (T373818)
A mockup of AutorevealNous avons décidé de mettre en place une fonctionnalité de « révélation automatique ». Cela permettra à certains utilisateurs dotés de droits étendus de consulter toutes les adresses IP pour tous les comptes temporaires au cours d'une période donnée. Cette fonctionnalité aidera ces utilisateurs à réagir rapidement aux abus, par exemple aux actes de vandalisme qui nécessitent la vérification d'un grand nombre d'adresses IP. Nous sommes actuellement en train de définir les tâches et les conceptions types pour cette fonctionnalité. Nous vous serions reconnaissants de bien vouloir partager votre avis sur Autoreveal dans cette tâche Phabricator. La décision de le créer a été prise à la suite de nos discussions avec les administrateurs et autres utilisateurs disposant de droits étendus, et nous tenons à les remercier une nouvelle fois pour leur implication continue et leurs précieux conseils.
Special:GlobalContributions permettra prochainement d'afficher des informations sur les contributions inter-wikis des utilisateurs enregistrés, des adresses IP, des plages d'adresses IP et des comptes temporaires. (T375632)
: Déploiement sur des wikis-pilotes
Calendrier de déploiement
Nous avons finalisé la liste des projets de petite et moyenne taille pour lesquels nous déploierons des comptes temporaires au cours des deux prochaines semaines. L'objectif est de s'assurer que toutes les fonctionnalités essentielles (workflows des patrouilleurs, outils, etc.) des comptes temporaires fonctionnent comme prévu. Nous avons décidé de diviser cette phase en deux lots. De cette façon, nous aurons un meilleur contrôle sur les fonctionnalités-clefs et serons plus confiants avant l'introduction des comptes temporaires dans les plus grands des premiers projets pilotes.
Le 29 octobre, nous avons déployé des comptes temporaires pour :
Nous développons actuellement un tableau de bord public pour surveiller les indicateurs sur nos projets pilotes. Nous mettrons bientôt en place une page de documentation pour expliquer les indicateurs sur lesquels nous nous concentrons et pourquoi.
Special:GlobalContributions est désormais prêt pour la recherche de contributions cross-wiki à partir d'une adresse IP. Cette page ne sera accessible qu'aux utilisateurs qui sont qualifiées pour connaître les adresses IP associées à un compte temporaire. Nous sommes encore en train de mettre fin aux autorisations pour accéder à cette page. Nous disposerons la semaine prochaine d'une page de documentation à ce sujet.
Nous avons mis à jour IP Info pour prendre en charge les informations pour l'association de plusieurs adresses IP à un compte temporaire. Special:IPInfo devrait être disponible pour tous les projets où des comptes temporaires seront déployés.
Nous mettons à jour la politique d'accès aux informations IP afin qu'elle soit conforme à la politique de divulgation des adresses IP. Vous pouvez suivre cette tâche pour plus d'informations.
Les comptes temporaires peuvent désormais être bloqués à l'échelle mondiale. Les travaux d'autoblocage mondial sont en cours et devraient être mis en œuvre au cours des prochaines semaines.
Les comptes temporaires sont désormais disponibles sur tous les projets de cluster bêta, à l'exception des en-rtl à tester.
Nous sommes heureux d'annoncer notre calendrier et stratégie pour le déploiement des comptes temporaires sur tous les wikis.
Le plan a été co-créé par les départements produits et technologie, juridique et de communication de la Fondation.
Nous avons également consulté les stewards et informé les CheckUsers.
Toutes les dates ci-dessous sont sujettes à changement en fonction de l'étendue des travaux en cours.
Nous vous informerons si quelque chose change.
Fin octobre 2024, nous déploierons cette fonctionnalité sur environ 10 wikis de petite et moyenne taille. Cette phase s'appelle le déploiement pilote mineur. Nous avons présélectionné des pilotes potentiels en fonction de différents facteurs. Il s'agit notamment du nombre d'administrateurs actifs et de modifications provenant d'adresses IP par mois, de l'absence de bloqueurs liés à la configuration d'un wiki donné, de la disponibilité d'ambassadeurs potentiels et de membres techniques des communautés respectives, et plus encore. Après avoir déployé ce projet, nous surveillerons l'impact de ce projet sur la collaboration sur les wikis. Nous contacterons également les membres des communautés de ces wikis. Quelque temps plus tard, nous surveillerons ce qui se passera lorsque les adresses IP initiales des comptes temporaires ne seront plus disponibles pour les patrouilleurs.
Si les premiers déploiements sont couronnés de succès et que nous ne faisons pas face à une tonne de travail imprévu, en février 2025, nous procéderons alors au déploiement sur des wikis plus importants. C'est ce que nous appelons un déploiement pilote majeur. Il pourra inclure quelques-uns des 10 plus grands wikis, mais pas la Wikipédia anglophone.
Enfin, plus tard en 2025, nous déploierons les comptes temporaires sur tous les wikis restants en une étape soigneusement coordonnée. Après cela, nous fournirons une assistance, mesurerons les données, et résoudrons les problème au fur et à mesure de leur apparition.
Nous ferons tout notre possible pour informer à l'avance toutes les personnes concernées. Les informations relatives aux comptes temporaires seront disponibles sur Tech News, Diff, d'autres blogs, différentes pages wiki, des bannières et d'autres supports. Lors de conférences, par exemple régionales et nationales, nous ou nos collègues pour notre compte inviterons les participants à parler de ce projet. Nous allons aussi essayer d'y faire des présentations. De plus, nous contacterons les affiliés qui gèrent des programmes de soutien aux éditeurs disposant d'autorisations avancées. Abonnez-vous à notre newsletter pour recevoir des mises à jour régulières.
: Avancement de nos travaux techniques
Avant de déployer des comptes temporaires dans un wiki non testé, nous devons terminer notre travail sur quelques tâches restantes. Cela inclut :
Mesures actualisées en direct sur les comptes temporaires. Avant les déploiements prévus en octobre, nous créerons un tableau de bord présentant l'impact du déploiement des comptes temporaires sur les communautés. Il y aura différents graphiques montrant, par exemple, le nombre de retours, de blocages, des prévisualisations d'adresses IP des comptes temporaires ("Révélation d'IP"), des modifications réussies et abandonnées, et plus encore. Toutes ces données seront mises à jour très fréquemment, par exemple, tous les jours, pour donner à chacun une bonne visibilité du travail réel des comptes temporaires sur les wikis. (T357763)
Autoriser les autoblocages globaux pour les comptes temporaires (T368949), mettre en place un mécanisme accordant automatiquement aux utilisateurs éligibles le droit de révéler les adresses IP des comptes temporaires (T327913) et certaines autres tâches.
Dans le même ordre d'idées, nous souhaitions partager une demande aimable adressée aux responsables de la maintenance des codes appartenant à la communauté, tels que les outils, les robots, les gadgets, etc. Nous voulons éviter toute perturbation inutile de votre logiciel. Si elle utilise des données relatives aux adresses IP ou est accessible aux utilisateurs non connectés, veuillez lire notre documentation, et en particulier la section consacrée à la manière dont votre code pourrait devoir être mis à jour. Nous serons heureux de vous aider, et nous attendons vos questions.
Graduation de l'Info IP hors des fonctionnalités bêta.IP Info fournit des informations fiables sur les adresses IP à certains utilisateurs connectés. Conformément à une politique dédiée, cet outil ne peut être utilisé que dans le cadre d'enquêtes ou de mesures préventives visant à lutter contre les violations des politiques. Les utilisateurs peuvent y accéder s'ils cochent une case dans leurs préférences, acceptant ainsi d'utiliser cet outil conformément aux présentes conditions. Ensuite, ils peuvent voir un bouton « ⓘ » affiché à côté de l'adresse IP sur des pages telles que Modifications récentes, Liste de suivi et Historique de la page. Cette fonctionnalité est également disponible pour eux en haut de la page Special:Contributions lorsque les contributions d'une adresse IP spécifique sont répertoriées. Bientôt, nous en ferons une fonctionnalité régulière et la supprimerons de la liste des fonctionnalités bêta. Nous allons aussi apporter quelques modifications à sa fonctionnalité. Pour plus d'informations à propos d'IP Info, consultez sa page projet ou abonnez-vous à notre nouvelle newsletter. (T375084)
1 $ : Les blocages globaux sont arrivés. Comptes temporaires sur testwiki
Déploiement sur testwiki Nous avons déployé des comptes temporaires sur testwiki. Toute personne qui modifie testwiki sans compte verra ses modifications être attribuées à un compte temporaire. Nous tenons à souligner qu'il s'agit d'une version préliminaire et que des dysfonctionnements sont possibles. Ce déploiement permet à certaines équipes (comme Data Platform Engineering ou Apps) de commencer à adapter leur code aux comptes temporaires. Nous n'avons pas l'intention d'introduire de comptes temporaires sur aucun autre wiki pour l'instant. Au lieu de cela, nous inviterons des patrouilleurs de différentes communautés à tester le wiki et leur demanderons de se familiariser avec la nouvelle expérience et de partager leurs opinions avec nous. Actuellement, seuls les administrateurs de testwiki peuvent voir les workflows de patrouille mis en place (tels que la divulgation des adresses IP et la consultation des contributions IP) pour les comptes temporaires. Au cours des prochaines semaines, nous élargirons l'accès afin de permettre à davantage d'utilisateurs de tester les workflows liés aux comptes temporaires sur testwiki.
Blocage global Nous sommes très heureux d'annoncer que nous avons lancé les blocages de comptes globaux sur tous les wikis (T17294). Une demande de cette fonctionnalité a été documentée pour la première fois en 2008. C'était également l'une des six principales fonctionnalités figurant dans la [liste des souhaits des stewards en 2015]. Maintenant, les stewards peuvent bloquer les utilisateurs réguliers et temporaires de comptes à l'échelle mondiale. Lisez notre précédente mise à jour pour en savoir plus sur l'impact prévu des blocages globaux.
Wikimania. Nous organiserons les sessions « Les comptes temporaires arrivent » (ajouter à vos sessions favorites) et « Améliorer le blocage des activités indésirables sur les wikis » (ajouter à vos sessions favorites). Inscrivez-vous à Wikimania pour ajouter des sessions à vos favoris. Rejoignez-nous en personne ou virtuellement, et n'hésitez pas à contacter les membres de notre équipe pendant l'événement !
Filtre anti-abus. Certains filtres anti-abus existants, mis en place par les membres de la communauté sur différents wikis, devront être mis à jour pour fonctionner avec les comptes temporaires. (Voir nos instructions à l'intention des développeurs sur la manière de procéder.) Après le déploiement des comptes temporaires sur un wiki donné, les filtres anti-abus utilisant des données sur les adresses IP ainsi que les journaux associés seront masqués à la vue de tous. Les administrateurs pourront consulter et modifier ces filtres. Plus tard, nous pourrons modifier le groupe d'utilisateurs ayant accès aux filtres concernés, afin d'inclure éventuellement des éditeurs techniques qui ne disposent d'aucune autre autorisation avancée.
: Priorité pour les outils techniques et de patrouille
Changements au sein de l'équipe. Dans notre mise à jour de septembre 2023, nous avions indiqué que les changements au sein de l'équipe pourraient avoir une incidence sur le calendrier de ce projet. Cela s'est effectivement produit, comme nous l'avons indiqué sur la page de discussion plus tôt cette année. En bref, les équipes chargées des outils anti-harcèlement et des outils de confiance et de sécurité ont été fusionnées afin de travailler selon un plan unifié. Nous vous invitons à consulter notre page d'équipe actualisée et notre partie du plan annuel 2024-2025 : résultats clés WE4.1, WE4.2 et WE4.4. Les comptes temporaires sont documentés sous WE4.4.
Documentation. Nous vous invitons à lire la nouvelle FAQ, à visiter la page principale du projet et à cliquer ici et là. Nous avons migré les pages depuis Meta-Wiki, puis les avons restructurées et mises à jour. Nous espérons que cette nouvelle structure vous permettra de mieux comprendre les changements à venir, le fonctionnement des comptes temporaires et les raisons de cette modification.
Wikimania. Les membres de notre équipe animeront deux sessions lors de Wikimania 2024 : l'une sur les comptes temporaires et l'autre sur l'amélioration du blocage des activités malveillantes sur les wikis. Que vous soyez à Katowice ou connecté en ligne, rejoignez-nous !
Calendrier prévisionnel des déploiements :
Nous avons examiné nos plans antérieurs et avons donné la priorité au soutien des outils de patrouille et aux workflows anti-abus. La partie la plus importante de notre travail est de veiller à ce que les administrateurs et les patrouilleurs du wiki soient à l'aise avec le déploiement de comptes temporaires. Nous ne pouvons pas estimer combien de temps cette partie du travail prendra. En conséquence, nous ne pouvons pas annoncer les dates des déploiements.
En avril, nous avons demandé aux développeurs bénévoles de mettre à jour le code dont ils ont la charge. Il s'agissait d'un appel précoce afin de leur laisser le temps de se préparer. Certains outils devront peut-être être mis à jour avant le déploiement du wiki test.
Nous discutons actuellement de notre stratégie concernant le déploiement des wikis de contenu. Nous évaluons différents facteurs, notamment la cohérence des flux de travail des administrateurs entre les wikis, la disponibilité des fonctionnaires et la fréquence des abus sur différents wikis.
Modifications apportées aux fonctionnalités et aux outils. Comme nous l'avons mentionné, nous accordons la priorité à l'assistance aux patrouilleurs et aux administrateurs. Voici quelques exemples de nos travaux récents :
Blocage global Actuellement, il n'existe aucun outil permettant aux administrateurs de bloquer un compte de manière globale. Il n'existe que le verrouillage global, qui déconnecte la personne de son compte. Sans nos modifications, un titulaire temporaire de compte bloqué de cette façon perdrait son compte et créerait un nouveau lors de sa prochaine tentative de modification. Après nos modifications, ils ne seront pas déconnectés, et ils verront un avis de blocage lors de leur prochaine tentative de modification (T17294). Cela signifie également que les stewards seront en mesure de bloquer globalement les utilisateurs enregistrés, ce qui met en œuvre une fonctionnalité demandée depuis longtemps et fournit de meilleurs outils pour lutter contre les abus cross-wikis.
Autoblocages. Pour que ce qui précède soit efficace, nous prendrons également en charge les autoblocages, limitant ainsi la création de comptes temporaires (T355286). Cela limitera les possibilités d'abus si une personne utilisant un compte temporaire bloqué globalement quitte sa session et tente à nouveau d'effectuer une modification.
Contributions globales des utilisateurs. L'outil Contributions globales des utilisateurs permet aux patrouilleurs de suivre les modifications apportées par un utilisateur déconnecté sur tous les wikis et de suivre les abus inter-wikis. Il dépend toutefois de la publicité des adresses IP. À la suite de nos déploiements, il cessera de fonctionner. Nous sommes en train de développer un nouvel outil du même nom qui offrira les mêmes fonctionnalités (T337089).
Page spéciale pour les contributions IP. Actuellement, les administrateurs vérifient les contributions effectuées par les utilisateurs non connectés à partir d'adresses IP, à l'aide de la page Special:Contributions. Après notre déploiement, seules les contributions régulières et temporaires des titulaires de comptes seront répertoriées sur cette page spéciale. Nous construisons une nouvelle page, Special:IPContributions, pour maintenir la fonctionnalité (T358852).
Nous mettons également à jour d'autres outils comme AbuseFilter, outils CheckUser, action API, et plus encore.
: nouvelles fonctionnalités, nouveaux noms et Wikimania
Diapositives de présentation au Wikimania
Mises à jour du projet
Format du nom des comptes temporaires. Le format du noms des comptes temporaires sera ~YYYY-nnnnn-nnn. YYYY est l'année de création du compte temporaire. La n-séquence représente l'identifiant unique du nom de l'utilisateur temporaire. Par exemple, un compte temporaire créé en 2023 ressemblerait à : ~2023-27459-041. Le préfixe d'année permet de déterminer l'âge d'un compte temporaire. Cela fournit des informations aux patrouilleurs ou à quiconque cherche à communiquer avec le contributeur. Nous avons pris la décision après les échanges sur la page de discussion du wiki et sur Phabricator (T337103). Merci beaucoup à ceux qui ont pris part à ces débats !
Modification de l'équipe et proposition de calendrier pour les premier déploiements. L'équipe des Outils anti-harcèlement a été fusionnée avec l'équipe Outils de confiance et de sécurité. La nouvelle équipe s'appelle Produit de confiance et de sécurité (Trust and Safety Product). Elle aura une portée étendue. Cette modification de la structure peut avoir des effets sur le calendrier du projet. D'autres mises à jour suivront au fur et à mesure du développement du programme de la nouvelle équipe. Notre calendrier actuel prévu pour ce projet est le suivant :
Déploiement sur testwiki – janvier 2024
Déploiement des premiers wikis pilotes – à partir de mars 2024
Page des questions féquentes. Nous avons créé la page des questions fréquemment posées (FAQ). Nous allons l'étendre et la mettre à jour dans les semaines et les mois à venir.
Mise à jour de Wikimania et modification du nom de projet. Nous avons présenté une mise à jour du projet au Wikimania de Singapour. Vous pouvez accéder aux diapositives de la présentation. Il existe aussi un enregistrement de la présentation complète disponible sur YouTube. Au Wikimania, nous avons utilisé l'ancien nom de projet, masquage de l'adresse IP. Après cela nous avons décidé de le modifier en Comptes temporaires pour les contributeurs non enregistrés ou plus simplement Comptes temporaires. Il représente nos changements dans un langage simple, sans métaphore technique.
Nouvelles fonctionnalités
Blocage global. Nous allons travailler sur le blocage global des utilisateurs enregistrés et des utilisateurs temporaires. Actuellement, le blocage global ne fonctionne que pour les adresses IP et les intervalles d'adresses IP. Il existe une demande de longue date pour étendre cette fonctionnalité pour permettre de bloquer les utilisateurs également. Nous allons définir cette fonctionnalité et la développer au cours des prochains mois. Pour les mises à jour, vous pouvez suivre la tâche Phabricator (T17294).
Contributions globales de l'utilisateur. Cette fonctionnalité sera portée sur MediaWiki. Cette fonctionnalité existe actuellement via l'outil GUC. Notre changement permettra aux utilisateurs de voir plus facilement les contributions à partir des comptes dans les différents projets. Ce sera possible via une page spéciale. Cela sera particulièrement utile lorsque les comptes temporaires entreront en vigueur. Pour les détails techniques, voir T337089.
: Le plan pour le masquage des adresses IP
Comme promis, voici une mise à jour au sujet du masquage à venir des IP.
Elle porte sur les modifications touchant à la fois les contributeurs non enregistrés et ceux enregistrés.
Nous voulons souligner d'emblée que de nombreuses questions demeurent ouvertes, pour lesquelles nous n'avons pas pris de décision.
Ceci est notre plan initial et ne couvre pas tout ce que nous souhaitons faire durant ce projet.
Au fur et à mesure que nous avançons, nous découvrons de nouveaux éléments, qui n'avaient pas été anticipés.
Vos retours nous aideront à comprendre ce que nous pouvons entreprendre en plus pour rendre le masquage des IP plus accessible à nos communautés.
Cette mise à jour se présente sous le format d'une FAQ pour rendre les changements à venir clairs et compréhensibles.
Qu'est-ce que le masquage IP change du point de vue d'un contributeur non connecté ?
Actuellement, avant qu'un contributeur non connecté n'effectue une modification, il est informé que ses modifications seront attribuées à son adresse IP.
Dans le futur, avant qu'un utilisateur non connecté ne publie une modification, il sera informé que ses modifications seront attribuées à un compte temporaire.
Son nom d'utilisateur sera un nombre, qui s'incrémentera pour chaque nouveau compte temporaire.
Le compte sera lié à un cookie stocké dans le navigateur web du contributeur.
Tant que ce cookie existe, le contributeur gardera le même compte temporaire, et toutes ses modifications seront attribuées à celui-ci.
L'IP du contributeur est susceptible de changer, mais le compte temporaire demeurera le même tant que le cookie existe.
Un compte temporaire généré sur un wiki sera aussi opérationnel sur les autres wikis auxquels le contributeur serait susceptible de participer.
À quoi ressembleront les noms d'utilisateur temporaires ?
Nous ne savons pas encore.
Nos premières maquettes de travail envisageaient d'utiliser un astérisque comme préfixe, suivi d'un nombre s'incrémentant automatiquement.
(Exemple : *12345.)
Vous trouverez ces maquettes de travail ci-dessous.
Mais comme l'ont souligné certains volontaires, l'astérisque n'est pas un bon choix en raison d'un bug exceptionnel de MediaWiki.
Nous discutons actuellement de différentes possibilités de préfixes et effectuerons des tests auprès des utilisateurs.
Les principaux préfixes retenus pour le moment (sans ordre particulier) sont :
L'un de ces préfixes vous semble-t-il un excellent ou très mauvais choix ?
Merci d'ajouter vos commentaires soit sur la page de discussion ou dans Phabricator.
↑(Bien que le point d'interrogation soit un excellent signe utilisé pour quelque chose d'inconnu et qu'il soit largement compris par tous, il y a des détails que nous sommes encore en train de régler. Par exemple, il devra être encodé dans l'URL à l'aide de %3F. Cet encodage d'URL ne devrait pas poser de problème, mais pourrait gêner les utilisateurs ayant l'habitude de taper les URL à la main.)
Quelle est la durée de validité des noms d'utilisateur temporaires ?
Quelque temps après la première modification (en principe un an) ou à la suite de l'effacement de la mémoire cache de l'utilisateur, le cookie expirera automatiquement.
Les modifications existantes lui seront néanmoins attribuées.
Après l'expiration de l'ancien nom d'utilisateur, si l'utilisateur modifie à nouveau le wiki, il se verra attribuer un nouveau compte temporaire.
Qu'est-ce que le masquage des IP change pour les patrouilleurs ?
Divulgation limitée des adresses IP
Le plus grand changement est que les adresses IP ne seront plus visibles par le grand public.
Toute personne n'ayant pas de compte ou dont le compte ne remplit pas les conditions requises pour l'accès aux adresses IP (voir la mise à jour du service juridique) ne pourra pas voir les adresses IP.
Afin d'atténuer l'impact sur la patrouille, nous allons apporter des améliorations à la fonctionnalité information sur l'adresse IP.
Cela inclura les données du service Spur.
Obtention de l'accès aux adresses IP
Nous avons élaboré de nouvelles directives en collaboration avec le service juridique de la Fondation.
Celles-ci définissent le type d'utilisateurs pouvant accéder aux adresses IP et la manière dont ils pourront le faire.
Les utilisateurs qui remplissent les conditions requises pourront choisir d'avoir accès aux adresses IP par l'intermédiaire de Spécial:Préférences.
Découvrez en détail le fonctionnement de la fonctionnalité permettant d'avoir accès aux adresses IP.
Le fait d'accéder aux adresses IP sera enregistré dans les journaux, qui seront disponibles pour un groupe limité d'utilisateurs (vérificateurs d'adresse IP, stewards, Trust & Safety).
Meilleurs canaux de communication avec les contributeurs temporaires
Les comptes temporaires seront liés à un cookie du navigateur.
Tant que le cookie existe, les modifications apportées par l'utilisateur seront attribuées au même compte temporaire.
Les titulaires de comptes temporaires pourront également recevoir des notifications sur les pages de discussion, de la même manière que les utilisateurs enregistrés.
Nous espérons que cela permettra une meilleure communication avec les utilisateurs temporaires.
Cela pourra également résoudre certains problèmes de longue date soulevés par les communautés (voir T278838).
Documentation des adresses IP des vandales
Il sera possible de documenter publiquement les adresses IP des vandales par le biais des pages d'abus à long terme, comme c'est le cas actuellement.
En revanche, il convient de veiller à ne pas exposer les adresses IP d'autres utilisateurs temporaires.
Lors des discussions sur les éventuels vandales, des outils tels que la suppression doivent être utilisés si l'utilisateur suspecté se révèle ne pas être un vandale.
Plus de détails à ce sujet peuvent être trouvés dans les directives.
Nous sommes en train d'élaborer des directives pour les outils Cloud et les bots afin qu'ils accèdent aux adresses IP à des fins de patrouille.
Nous aurons bientôt des nouvelles à apporter à ce sujet.
Qu'advient-il des adresses IP existantes sur nos sites ?
Les adresses IP existantes qui ont déjà contribué sur nos wikis resteront inchangées.
Les modifications apportées après le masquage des IP seront attribuées à des noms d'utilisateur temporaires.
Étant donné que le masquage des IP sera mis en place progressivement, ce changement se produira sur différents wikis à différents moments.
Comment la fonctionnalité de révélation de l'adresse IP fonctionnera ?
Les utilisateurs pouvant accéder aux adresses IP pourront afficher les adresses IP des comptes temporaires.
Voir les maquettes de travail illustrant le fonctionnement de cette fonctionnalité :
Qu'arrivera-t-il aux outils et aux robots qui dépendent des adresses IP pour fonctionner ?
Nous travaillons actuellement pour comprendre l'impact du dispositif sur les outils gérés par les bénévoles.
Cette tâche incombe à notre équipe ainsi qu'aux équipes de recherche et d'ingénierie.
Ensuite, nous travaillerons avec le service juridique pour comprendre quels outils peuvent continuer à accéder aux adresses IP et quelles sont les directives qui régissent leur fonctionnement.
Nous ferons une mise à jour de cette page dès que nous aurons un plan d'action.
Plans de déploiement
Nous prévoyons de tester le masquage des IP progressivement, afin de laisser suffisamment de temps aux communautés pour faire part de leurs commentaires et de leurs essais.
Nous voulons que nos déploiements n'entravent pas les processus des communautés.
Notre autre priorité est d'éviter les effets indésirables sur la santé des communautés.
Nous avons mis en place des indicateurs que nous prévoyons de suivre au fur et à mesure que nous mettons en œuvre les changements.
Nous recherchons des communautés qui seraient intéressées pour tester le lancement du masquage des IP.
Nous prenons en compte des critères tels que le nombre de modifications réalisées par des adresses IP que les communautés reçoivent, l'urgence du travail de lutte contre le vandalisme, la taille du projet et les risques de perturbation du wiki.
Nous mettrons à jour cette page une fois les wikis candidats choisis à l'approche du lancement du dispositif de masquage des IP.
Si vous souhaitez que votre communauté teste le lancement du masquage des adresses IP, prenez une décision communautaire et faites nous le savoir sur la page de discussion.
: focaliser le travail sur le masquage IP
Hi all. We’re officially refocusing our work on the core IP Masking project, now that we have completed the first phase on IP Info feature and other related projects.We are moving forward with technical planning to understand what will need to change when IP Masking goes into effect.We will be reaching out to our technical volunteers to help evaluate changes and migrate tools, as needed.Some of this planning work has already started at phab:T324492, and you may reach out to us there if you have questions about specific tasks.
I will follow this up with another post shortly to share an outline of the MVP (Minimum Viable Product) we have landed on. This MVP is based on the conversations we have had with the community in the past, through this page and other mediums. Please feel free to peruse those previous conversations and read through the past updates on this page. If you have questions or concerns, you can reach out to us on the talk page.
: Stratégie d'implémentation et étapes suivantes
Bonjour à tous. Nous avons une mise à jour sur la stratégie d'implémentation du masquage de l'adresse IP.
First off, thank you to everyone who arrived on this page and offered their feedback. We heard from a lot of you about how this page is not easy to read and we are working on fixing that. We genuinely want to thank you for taking the time to go through the information here and on the talk page. We took every comment on the talk page into consideration before the decision about the implementation plan was made.
We want to preface this also by saying that there are still a lot of open questions. There is a long road ahead of us on this project and we would like you to voice your opinion in more of these discussions as they come up. If you haven’t already, please go through this post about who will continue to have IP address access before reading further.
We received mixed feedback from the community about the two proposed implementation ideas without a clear consensus either way. Here are some quotes taken from the talk page:
For small wikis, I think the IP based approach is better because it is unlikely that two anonymous users will have the same IP, and for a vandal modifying its Ip is most difficult that erasing cookies.
The session-based system does seem better, and would make it easier to communicate with anonymous editors. I'm an admin on English Wikipedia, and my main interaction with IP editors is reverting and warning them against vandalism. In several cases recently I haven't even bothered posting a warning, since it seems unlikely the right person would receive it. In one case I was trying to have a conversation about some proposed change, and I was talking to several different IP addresses, and it was unclear that it was actually the same person, and I had to keep asking them about that.
As an admin in German-language Wikipedia, of the two paths described here (IP based identity vs. session-based identity) I clearly prefer the IP based approach. It's just too easy to use a browser's privacy mode or to clear the cookies (I'm doing it myself all the time); changing your IP address at least requires a bit more effort, and we have already a policy against using open proxies in place. I agree with Beland that the session-based identity approach could probably make communication with well-meaning unregistered editors easier, but it just doesn't seem robust enough.
I prefer the session-based approach. It provides more value in being able to identify and communicate with legitimate anonymous editors. However, at the same time, we need abuse filter options to be able to identify multiple new sessions from a single IP. These could be legitimate (from a school, for example), but will most likely represent abuse or bot activity. One feature I haven't seen mentioned yet. When a session user wants to create an account, it should default to renaming the existing session ID to the new name of their choice. We need to be able to see and/or associate the new named user with their previous session activity.
I am leaning towards the IP-based identities, even if encrypted, as cookies seem more complicated to deal with and very bothersome to keep shutting their annoying pop-ups (very standard in Europe). I have to mention that I prefer that till this day, one could use Wikipedia without cookies, unless he wants to log in to edit with his username.
The ability to perform purely session-based blocks in addition to the existing IP+session blocking would be an interesting upgrade. Being able to communicate with IPv6 users through their session instead of their repeatedly changing IP address would also be a benefit.
In summary, the main argument against the session-based approach was that cookies are easy to get rid of and the user may change their identity very easily.
Les principaux arguments contre l'approche basée sur l'adresse IP étaient les suivants :
the encryption method can be compromised, hence compromising the IP addresses themselves
this approach does not provided the benefit of improved communication with the unregistered editors
does not allow for session-based blocking (in addition to IP based blocking)
In light of the above and the discussions with our technical team about the feasibility and wide-ranging implications of this implementation, we have decided to go with the session-based approach with some important additions to address the problem of users deleting their cookies and changing their identity. If a user repeatedly changes their username, it will be possible to link their identities by looking at additional information in the interface. We are still working out the details of how this will work – but it will be similar to how sockpuppet detection works (with some automation).
We are working out a lot of the technical details still and will have another update for you shortly with more specifics. This includes LTA documentation, communication about IPs, AbuseFilters, third-party wikis, gadgets, user-scripts, WMF cloud tools, restrictions for IP-viewer rights etc. We appreciate your input and welcome any feedback you may have for us on the talk page.
: Masquage des adresses IP et comment protéger les wikis
Nous avons discuté deux approches différentes que nous envisageons pour le masquage des adresses IP. À la suite de cela, nous avons proposé quelques workflows différents et nous avons envisagé la manière dont ils changeront avec chacune des deux implémentations.
Notez que dans les deux alternatives, les admins, stewards, vérificateurs d'adresses IP et les utilisateurs avec le statut IPviewer seront en mesure d'afficher les IP sur des pages telles que les modifications récentes et les historiques, à des fins de lutte contre le vandalisme.
Expérience de modification pour les contributeurs non enregistrés
Comportement actuel : À l'heure actuelle, les contributeurs non enregistrés peuvent modifier sans s'être connectés (sur la plupart des wikis). Avant d'effectuer une modification, ils voient une bannière les informant que leur adresse IP sera stockée et affichée publiquement indéfiniment.
Identité fondée sur l'adresse IP : Les utilisateurs non enregistrés seront en mesure de modifier comme à l'heure actuelle. Avant d'effectuer une modification, ils verront un message leur indiquant que leurs modifications seront attribuées à une version chiffrée de leur adresse IP. Leur adresse IP elle-même sera visible aux administrateurs et patrouilleurs. Elle ne sera stockée que pour une durée limitée.
Identité fondée sur la session : Cette alternative est identique à la précédente, excepté le fait que les utilisateurs seront informés que leurs modifications seront attribuées à un nom d'utilisateur généré aléatoirement.
Capture d'écran de l'identité fondée sur l'adresse IP.
Capture d'écran de l'identité fondée sur la session.
Communication à propos des utilisateurs non enregistrés
Comportement actuel : Les utilisateurs non enregistrés sont identifiés par leur adresse IP ou, s'ils sont des vandales au long terme, sont souvent dotés [par la communauté] d'un nom fondé sur leur comportement.
Identité fondée sur l'adresse IP : Les patrouilleurs et admins ne seront pas autorisés à se référer publiquement aux adresses IP mais pourront désigner les utilisateurs non enregistrés par leur adresse IP chiffrée, ou par le nom donné aux vandales de longue durée. Ils pourront partager les adresses IP aux autres contributeurs y ayant accès.
Identité fondée sur la session : Les patrouilleurs et admins ne seront pas autorisés à se référer publiquement aux adresses IP mais ils pourront se référer au nom généré aléatoirement. Ils pourront partager les adresses IP avec les auteurs contributeurs y ayant accès. Cela pourra aider à identifier un acteur précis mais cela peut également être source de confusion s'il y a plusieurs adresses IP derrière le nom généré aléatoirement, de la même manière que plusieurs personnes peuvent utiliser la même adresse IP actuellement. Afin de résoudre ce problème, nous élaborons un outil qui sera capable de fournir des informations au sujet des différentes adresses IP utilisées par un même contributeur.
Expérience en page de discussion pour les utilisateurs non enregistrés
Fonctionnement actuel : Un contributeur non enregistré peut recevoir des messages sur la page de discussion correspondant à leur IP actuelle. Lorsque l'adresse IP du contributeur change, ils reçoivent les messages sur la page de discussion de la nouvelle adresse IP. Cela fragmente les conversations et rend difficile de garder le contact avec certains contributeurs non enregistrés.
Identité basée sur l'IP : Dans cette implémentation, le comportement restera le même qu'actuellement. Les contributeurs non enregistrés recevront les messages sur la page de discussion correspondant à leur IP chiffrée, quand leur adresse IP change, la page de discussion qui leur est associée change également.
Identité basée sur la session : Dans cette implémentation, les contributeurs non enregistrés reçoivent les messages sur une page de discussion associée à un cookie dans leur navigateur. Même si leur adresse IP change, cela leur permet de recevoir les messages sur leur page de discussion. Si les cookies du navigateur sont effacés, ils ne conservent plus l'identité de session et le navigateur recevra un nouveau cookie, et une nouvelle page de discussion sera attribuée. Comme les IP changent plus souvent que les cookies, il est probable que plusieurs utilisateurs se retrouveront avec une page de discussion semi-permanente, à moins qu'ils fassent en sorte que ce ne soit pas le cas. Un autre avantage notable est que, dans ce scénario, les messages laissés sur une page de discussion ne seront jamais transmis à un mauvais destinataire.
Notification de page de discussion
Blocage des utilisateurs non enregistrés
Comportement actuel : Un administrateur peut directement bloquer une adresse IP ou une plage d'adresses IP.
Identité fondées sur l'adresse IP : Le comportement demeure le même qu'actuellement. Les IP sont masquées par défaut mais les admins et patrouilleurs avec les droits idoines peuvent y accéder.
Identité fondée sur la session : Cette implémentation nous permet de conserver le fonctionnement actuel de blocage par adresse IP. Il nous permet également d'opérer des blocages fondés uniquement sur les cookies. Cela peut être utile dans les scénarios dans lesquels des internautes partagent des terminaux (par exemple dans une bibliothèque ou un cyber café) et dans lesquels bloquer l'adresse IP ou la plage d'adresses IP peut causer des dommages collatéraux. Je souhaite souligner que cela ne fonctionnera pas lorsque les vandales sont des utilisateurs expérimentés qui peuvent se dérober aux blocages par cookies.
: Approches de mise en oeuvre du masquage des IP (FAQ)
Cette FAQ répond à des questions que la communauté va se poser à propos des différentes approches qui pourront être mises en oeuvre pour le masquage des IP et comment chacune va impacter la communauté.
Q : Suite à la mise en oeuvre du masquage des IP, qui pourra voir les adresses IP ?
Réponse : Les vérificateurs d'adresse IP, stewards et admins pourront voir les adresses IP complètes en cochant une case dans leurs préférences, indiquant qu'ils s'engagent à ne pas partager ces informations avec des personnes n'y ayant pas accès.
Les contributeurs qui participent aux activités anti-vandalisme, approuvée par la communauté, pourront obtenir le droit de voir les addresses IP afin de continuer leurs actions. Ce droit utilisateur sera géré par la communauté comme les autres droits utilisateurs et demandera un nombre minimum de modifications et de jours de contribution.
Tous les utilisateurs avec des comptes d'une certaine ancienneté et avec un nombre minimal de modifications (à déterminer) pourront accéder sans permission aux adresses IP partiellement affichées. Cela signifie qu'une adresse IP apparaîtra avec ses derniers octets (la fin de l'adresse IP) cachée. Ils pourront accéder à ces informations via leurs préférences, dans lesquelles ils devront s'engager à ne pas les partager avec des utilisateurs n'y ayant pas accès.
Tous les autres utilisateurs n'auront pas accès aux adresses IP des contributeurs non inscrits.
Q : Quelles sont les options potentielles de mise en œuvre technique ?
R : Au cours des dernières semaines, nous avons engagé de multiples discussions sur les possibilités techniques d'atteindre notre objectif de masquage IP tout en minimisant l'impact sur nos rédacteurs et nos lecteurs. Nous avons recueilli les réactions de différentes équipes et obtenu des points de vue variés. Vous trouverez ci-dessous les deux idées principales.
Identité basée sur l'IP : Dans cette approche, nous gardons tout tel-quel, mais remplaçons les adresses IP existantes par une version des IP. Cela préserve une grande partie de nos flux de travail existants mais n'offre pas de nouveaux avantages.
Identité basée sur la session : dans cette approche, nous créons une identité pour les éditeurs non enregistrés en nous basant sur un cookie de navigateur qui identifie le navigateur de leur appareil. Le cookie persiste même lorsque leur adresse IP change, et leur session ne se termine donc pas.
Q : Comment fonctionne le principe de lʼidentité basée sur l'IP ?
R : Actuellement, les éditeurs non enregistrés sont identifiés par leur adresse IP. Ce modèle a fonctionné pour nos projets pendant de nombreuses années. Les utilisateurs qui connaissent bien les adresses IP comprennent qu'une seule adresse IP peut être utilisée par plusieurs utilisateurs différents en fonction de la dynamique de cette adresse IP. Cela est plus vrai pour les adresses IPv6 que pour les adresses IPv4.
Un utilisateur non enregistré peut également changer d'adresse IP s'il fait la navette ou s'il édite depuis un autre endroit.
Si nous optons pour la solution de l'identité basée sur l'IP pour le masquage de l'IP, nous préserverons la façon dont les adresses IP fonctionnent aujourd'hui en les masquant simplement avec un identifiant crypté. Cette solution permettra de garder les IP distinctes tout en préservant la vie privée des utilisateurs. Par exemple, un utilisateur non enregistré tel que User:192.168.1.2 peut apparaître comme User:ca1f46.
Bénéfices de cette approche :
Préservation des flux de travail et des modèles existants avec un minimum de perturbations.
Inconvénients de cette approche :
N'offre aucun avantage dans un monde qui évolue rapidement vers des adresses IP plus dynamiques/moins utiles.
Q : Comment fonctionne le principe de lʼidentité basée sur la session ?
A: The path is to create a new identity for unregistered editors based on a cookie placed in their browser. In this approach there is an auto-generated username which their edits and actions are attributed to. For example, User:192.168.1.2 might be given the username: User:Anon3406.
Dans cette approche, la session de l'utilisateur persistera tant que le cookie est présent dans son navigateur, même s'il change d'adresse IP.
Avantages de cette approche :
Ties the user-identity to a device browser, offering a more persistent way to communicate with them.
L'identité de l'utilisateur ne change pas lorsque leur adresse IP change
This approach can offer a way for unregistered editors to have access to certain preferences which are currently only available to registered users
This approach can offer a way for unregistered editors to convert to a permanent account while retaining their edit history
Inconvénients de cette approche :
Significant change in the current model of what an unregistered editor represents
L'identité des contributeurs non enregistrés existe uniquement pendant le temps que le cookie du navigateur est présent
Les vandales en mode privé ou qui effacent leur cookies recevront une nouvelle identité sans modifier leur adresse IP.
Peut nécessiter une révision de certains flux de travail et outils communautaires
Q: La fondation a-t-elle une approche préférée ?
A: Our preferred approach will be to go with the session-based identity as that will open up a lot of opportunities for the future. We could address communication issues we’ve had for twenty years. While someone could delete the cookie to get a new identity, the IP would still be visible to all active vandal fighters with the new user right. We do acknowledge that deleting a cookie is easier than switching an IP, of course, and do respect the effects it would have.
: Proposition pour partager les adresses IP avec ceux qui ont besoin d'accès
Salut à tous. Cela fait quelques mois depuis notre dernière mise à jour sur ce projet. Nous avons pris ce temps pour parler à beaucoup de gens - à travers la communauté d'édition et au sein de la Fondation. Nous avons soigneusement réfléchi à toutes les préoccupations soulevées lors de nos discussions avec des membres expérimentés de la communauté concernant l'impact que cela aura sur les efforts de lutte contre le vandalisme dans l'ensemble de nos projets. Nous avons également entendu un nombre important de personnes qui soutiennent cette proposition comme une étape vers l'amélioration de la confidentialité des éditeurs non enregistrés et la réduction de la menace juridique que l'exposition des IP au monde fait peser sur nos projets.
Lorsque nous parlons de ce projet par le passé, nous n'avions pas une idée claire de la forme que prendrait ce projet. Notre intention était de comprendre comment les adresses IP sont utiles à nos communautés. Depuis, nous avons reçu beaucoup de commentaires sur ce point d'une série de conversations en différentes langues et dans différentes communautés. Nous sommes reconnaissant envers tous les membres de la communauté qui ont pris le temps de nous informer sur comment fonctionne la modération sur leurs wikis ou dans leur environnement spécifique de « multi-wikis ».
Nous avons maintenant une proposition plus concrète pour ce projet qui, nous l'espérons, permettra à la plupart des travaux anti-vandalisme de se dérouler sans se décourager tout en restreignant l'accès aux adresses IP des personnes qui n'ont pas besoin de les voir.
Je veux mettre l'accent sur le mot « proposition » parce qu'il n'est en aucun cas, une forme ou une forme de verdict final sur ce qui va se passer. Notre intention est de solliciter vos commentaires sur cette idée. Selon vous, qu'est-ce qui fonctionnera ? Que pensez-vous ne fonctionnera pas? Quelles autres idées peuvent améliorer cela ?
Nous avons développé ces idées au cours de plusieurs discussions avec des membres expérimentés de la communauté, et nous les avons affinées en collaboration avec notre service juridique. En voici les grandes lignes :
Les checkusers, les stewards et les administrateurs devraient pouvoir voir les adresses IP complètes en optant pour une préférence où ils acceptent de ne pas la partager avec d'autres qui n'ont pas accès à ces informations.
Les éditeurs qui participent à des activités anti-vandalisme, approuvées par la communauté, peuvent se voir accorder le droit de voir les adresses IP pour continuer leur travail. Cela pourrait être géré de la même manière que l'est l'attribution du statut d'administrateur sur nos projets. L'approbation de la communauté est importante pour garantir que seuls les éditeurs qui ont vraiment besoin de cet accès peuvent l'obtenir. Les éditeurs devront avoir un compte avec au moins un an d'ancienneté et 500 modifications.
Tous les utilisateurs avec des comptes de plus d'un an et au moins 500 modifications pourront accéder aux adresses IP partiellement non masquées sans autorisation. Cela signifie qu'une adresse IP apparaîtra avec son ou ses octets de queue - la ou les dernières parties - masquées. Celles-ci seront accessibles via une préférence où ils s'engagent à ne pas les partager avec d'autres qui n'ont pas accès à ces informations.
Tous les autres utilisateurs ne pourront pas accéder aux adresses IP des utilisateurs non enregistrés.
L'accès à l'adresse IP sera enregistré afin qu'un examen minutieux puisse être effectué si et quand cela est nécessaire. Ceci est similaire au journal que nous tenons pour vérifier l'accès des utilisateurs aux données privées. C'est ainsi que nous espérons trouver un équilibre entre le besoin de confidentialité et le besoin des communautés d'accéder aux informations pour lutter contre le spam, le vandalisme et le harcèlement. Nous voulons donner l'information à ceux qui en ont besoin, mais nous avons besoin d'un processus, nous avons besoin qu'il soit souscrit explicitement afin que seuls ceux qui en ont réellement besoin puissent le voir et nous avons besoin que les accès soient enregistrés.
Nous voudrions connaître vos opinions sur cette proposition d'approche. Merci de nous donner votre avis sur la page de discussion.
Capture d'écran de l'identité fondée sur l'adresse IP.
Capture d'écran de l'identité fondée sur la session.
.png)