We have a finalized list of small-to-medium sized projects where we will be deploying temporary accounts over the next couple of weeks. The goal is to ensure all critical functionality (patroller workflows, tools etc.) for temporary accounts works as expected. We decided to split this phase into two batches. This way, we will have more control over the key functionality and more confidence before temporary accounts are introduced on the largest of the first pilots.
We are developing a public dashboard for monitoring metrics for our pilot projects. We will have a documentation page in place shortly to explain which metrics we are focusing on and why.
Special:GlobalContributions is now ready for looking up cross-wiki contributions from an IP address. This page will only be accessible to users who qualify to see IP addresses associated with a temporary account. We are still ironing out permissions for this page access. We will have a documentation page up about it over the next week.
We have updated IP Info to support information for multiple IP addresses that may be associated with a temporary account. Special:IPInfo should be available on all projects where temporary accounts will be deployed.
We are updating IP Info access policy to be at par with the IP Reveal policy. You can follow along with this task for further information.
Temporary accounts can now be globally blocked. Global autoblocks work is in progress and should be implemented over the next couple of weeks.
Temporary accounts are now available on all beta cluster projects except for en-rtl for testing.
We are looking forward to your comments on the talk page.
: Deployment plan is ready!
We are happy to announce our timeline and strategy for the temporary accounts deployments across all wikis.The plan was co-created by the Product and Technology, Legal, and Communications departments at the Foundation.We also consulted stewards and informed CheckUsers.All the date below are subject to change based on the extent of pending work.We will be informing you if anything changes.
In late October 2024, we will roll out on approximately 10 small and medium-sized wikis.This phase is called the minor pilot deployment.We have pre-selected potential good pilots based on different factors.These include: the numbers of active admins and IP edits per month, lack of blockers related to the configuration of a given wiki, availability of potential ambassadors and technical members of the respective communities, and more.After we deploy there, we will be monitoring the impact of this project on collaboration on wikis.We will also be contacting community members of these wikis.Some time later, we will monitor what will happen when the initial IP addresses of temporary accounts are not available to patrollers.
If the first deployments are successful and we don't have a ton of unexpected work, then in February 2025, we will roll out on larger wikis.We call this major pilot deployment.It may include some top10 wikis, but not English Wikipedia.
Next, in May 2025, we will deploy on all remaining wikis in one carefully coordinated step.After that, we will be providing support, monitoring metrics, and solving issues as they arise.
We will do our best to inform everyone impacted ahead of time.Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms.At conferences, for example regional and national ones, we or our colleagues on our behalf will be inviting talk about this project with attendees.We will also try to have presentations there.In addition, we will be contacting affiliates running programs of support for editors with advanced permissions.Subscribe to our new newsletter to stay close in touch.
: Progress on our technical work
Before we deploy temporary accounts to any non-test wiki, we need to complete our work on a few remaining tasks.These include:
Live-updated metrics on temporary accounts.Before the October deployments, we will build a dashboard presenting the impact of temporary accounts on communities.There will be different graphs showing, for example, numbers of reverts, blocks, temp accounts' IP address previews ("IP Reveal"), successful and abandoned edits, and more.All these will be updated very frequently, for instance, every day, to give everyone a good visibility of the actual work of temporary accounts on wikis. (T357763)
Allowing global autoblocks for temporary accounts (T368949), building a mechanism automatically giving the eligible users the right to reveal IP addresses of temporary accounts (T327913), and some other tasks.
Relatedly, we wanted to share a kind request to the maintainers of community-owned code like tools, bots, gadgets etc.We want to avoid any unnecessary disruptions to your software.If it uses data about IP addresses or is available for not logged-in users, please read our documentation, and in particular, the section on how your code might need to be updated.We will gladly help you out, and we're waiting for your questions.
Graduating IP Info out of beta features.IP Info provides reliable information about IP addresses to some logged-in users.According to a dedicated policy, this tool may only be used for the investigation or prevention of violations of policies.Users can access it if they select a checkbox in their preferences, agreeing to use this tool in accordance with these terms.Then, they can see a button ⓘ displayed next to the IP address on pages like Recent Changes, Watchlist, and page history.The feature is also available for them at the top of the Special:Contributions page when contributions of a specific IP address are listed.Soon, we will make this a regular feature and remove it from the list of beta features.We will also make some changes to its functionality.For more information about IP Info, watch its project page or subscribe to our new newsletter. (T375084)
: Global blocks are here. Temporary accounts on testwiki
Deployment on testwiki. We have rolled out temporary accounts to testwiki. Anyone who edits testwiki without an account will see their edits being attributed to a temporary account. We would like to emphasize that this is an early release, and things may break. This deployment makes it possible for some teams (like Data Platform Engineering or Apps) to start adjusting their code to temporary accounts. We aren't planning on introducing temporary accounts on any other wiki just yet. Instead, we will invite patrollers from different communities to testwiki and ask them to familiarize themselves with the new experience and share opinions with us. Currently, only testwiki admins can see the implemented patroller workflows (such as revealing IPs and view IP contributions) for temporary accounts. Over the next few weeks we will broaden the access to allow more users to test temporary accounts related workflows on testwiki.
Global blocking. We are really glad to announce that we launched global account blocks on all wikis (T17294). A request for this feature was first documented in 2008. It was also the top6 feature in the stewards' wishlist from 2015. Now, stewards can globally block regular and temporary account users. Read our previous update to learn more about the expected impact of global blocks.
Wikimania. We will be hosting sessions "Temporary Accounts are coming" (add to your favorite sessions) and "Getting better at blocking bad activity on the wikis" (add to your favorite sessions). Register to Wikimania to add sessions to favorites. Please join us in-person or virtually, and don't hesitate to get in touch with our team members during the event!
AbuseFilter. Some existing edit/abuse filters set up by community members on different wikis will need to be updated to work with temporary accounts. (See our instructions for developers on how to do this.) After the deployment of temporary accounts on a given wiki, abuse filters using data about IP together with related logs will be hidden from general view. It will be possible for admins to view and edit these filters. Later, we may change the group of users with access to the impacted filters, to potentially include technical editors who don't have any other advanced permissions.
Anciennes mises à jour
: Priority for functionary and patroller tools
Team changes. In our update from September 2023, we wrote that changes to the team may have an effect on the timeline of this project. Indeed, they had, as we wrote on the talk page earlier this year. Briefly, the Anti-Harassment Tools and Trust and Safety Tools teams were merged into one to work according to a unified plan. Now, we encourage you to look at our refreshed team page and our part of the 2024–2025 annual plan: key results WE4.1, WE4.2, and WE4.4. Temporary accounts are documented as WE4.4.
Documentation. We invite you to read the new FAQ, visit the main project page, and click around. We have migrated pages from Meta-Wiki, and restructured and updated them. Hopefully, the new structure makes it easier to learn about the future changes, how temporary accounts will work, and why this change will happen.
Wikimania. Our team members will hold two sessions at Wikimania 2024: about temporary accounts and about getting better at blocking bad activity on wikis. Whether you're going to be in Katowice or connecting online, join us!
Projected timeline for deployments:
We have reviewed our previous plans and prioritized support for patroller tools and anti-abuse workflows. The most important part of our work is ensuring that wiki functionaries and patrollers are comfortable with the rollout of temporary accounts. We can't estimate how much time this part of work will take. As a result, we can't announce the dates of deployments yet.
In April, we asked volunteer developers to update the code they maintain. This was an early call to give them time to prepare. Some tools may need to be updated before the test wiki deployment.
We are discussing our strategy for content wiki deployments. We're weighing different factors, including consistency of functionaries' workflows across wikis, and availability of functionaries and frequency of abuse on different wikis.
Changes to features and tools. As we mentioned, we are prioritizing support for patrollers and functionaries. Below are examples of our recent work:
Global blocking. Currently, there is no tool that allows stewards to globally block an account – there is only global lock, which logs the person out of their account. Without our changes, a temporary account holder blocked this way would lose their account and create a new one with their next edit attempt. After our changes, they will not be logged out, and they will see a block notice on their next edit attempt (T17294). Doing this also means that stewards will be able to globally block registered users, which implements a long-requested feature and provides better tools to combat cross-wiki abuse.
Autoblocks. To make the above effective, we will also support autoblocks, limiting temporary account creations (T355286). This will limit the avenues for abuse if a person using a temporary account that is globally blocked exits their session and tries to make an edit again.
Global User Contributions. The Global User Contributions tool allows patrollers to track a logged-out user's edits on all wikis and track cross-wiki abuse. It depends on IP addresses being public, though. As a result of our deployments, it will stop working. We are building a new tool with the same name which will provide the same functionality (T337089).
Special page for IP contributions. Currently, functionaries check contributions made by logged-out users from IPs, using the page Special:Contributions. After our deployments, only regular and temporary account holders' contributions will be listed on this special page. We are building a new page, Special:IPContributions, to keep the functionality (T358852).
We are also updating other tools like AbuseFilter, CheckUser tools, action API, and more.
: 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 le patrouillage, 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.
<span id=":_Refocusing_work_on_IP_Masking">
: 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 on Phabricator, 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.
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.
<span id=":_IP_Masking_and_changes_to_workflows">
: 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)