Produit de confiance et de sécurité/Comptes temporaires/Actualisations

Aperçu

Mises à jour

Droit

FAQ

Mises à jour de base du projet · Mises à jour du département juridique de la Fondation Wikimedia · Mises à jour concernant les modifications de l'ajustement du logiciel aux comptes temporaires

septembre 2023 : 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.

Anciennes mises à jour

avril 2023: 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 :

• Accent circonflexe (^) – User:^12345
• Tiret (-) – User:-12345
• Tilde (~) – User:~12345
• Point d'exclamation (!) – User:!12345
• Point d'interrogation (?) – User:?12345
• Année – User:2023-12345

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.

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.

Outils disponibles pour la patrouille

Comme les utilisateurs sous IP, les utilisateurs temporaires peuvent être vérifiés et patrouillés grâce à Spécial:Bloquer, Spécial:Vérificateur d'utilisateur et Spécial:Investigate. En outre, la fonctionnalité d'information IP peut être utilisée pour accéder aux informations sur l'adresse IP du compte temporaire.

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="16 février 2023:_Refocusing_work_on_IP_Masking">

16 février 2023: 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.

<span id="25 février 2022:_Implementation_Strategy_and_next_steps">

25 février 2022: 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.

<span id="9 décembre 2021:_IP_Masking_and_changes_to_workflows">

9 décembre 2021: 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. <span id="octobre 2021:_IP_Masking_Implementation_Approaches_FAQ">

octobre 2021: 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.

<span id="10 juin 2021:_Proposal_for_sharing_IP_addresses_with_those_who_need_access">

10 juin 2021: 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.

• Selon vous, qu'est-ce qui fonctionnera ?
• À votre avis, qu'est-ce qui ne fonctionnera pas ?
• Quelles autres idées peuvent améliorer cela ?