Contribution d'IP : Amélioration de la confidentialité et limitation des abus

This page is a translated version of the page IP Editing: Privacy Enhancement and Abuse Mitigation and the translation is 36% complete.

About IP Editing (discuss)
About IP Addresses (discuss)  · IP Editing Restriction Study (formerly Login Required Experiment) (discuss)

Aperçu

Ces dernières années, les internautes sont devenus plus informés de l'importance de comprendre la collecte et l'utilisation de leurs données personnelles. Les gouvernements de divers pays ont créé de nouvelles lois afin de mieux protéger la vie privée des utilisateurs. Les équipes juridique et « public policy » de la fondation Wikimedia suivent continuellement l'évolution des lois dans le monde, elles s'intéressent aux moyens de mieux protéger la vie privée des utilisateurs, de respecter leurs attentes et de défendre les valeurs du mouvement Wikimedia. Avec cette toile de fond, elles nous ont demandé d'enquêter et d'entreprendre une amélioration technique des projets. Nous devons le faire avec vous.

MediaWiki stocke et publie les adresses IP des contributeurs non enregistrés (dans leur signature, l'historique des pages et les journaux), et les rend visibles à quiconque visite nos sites. La publication de ces adresses IP compromet la sûreté et l'anonymat de ces utilisateurs. Dans certains cas, cela peut même exposer les gens au risque d'être persécutés par le gouvernement. Bien que nous informions les utilisateurs que leur adresse IP sera visible, peu comprennent les ramifications de cette information. Nous travaillons à une meilleure protection de la vie privée pour les contributeurs non enregistrés en cachant leur adresse IP quand ils contribuent aux projets, de la même manière que les lecteurs lambdas ne peuvent pas voir l'IP des utilisateurs enregistrés. Cela implique de créer un nom d'utilisateur « IP masquée », qui sera généré automatiquement, mais lisible humainement. Nous avons différentes idées sur comment implémenter cela. Vous pouvez commenter pour nous faire savoir ce dont vous avez besoin.

Les projets Wikimedia ont une très bonne raison de stocker et de publier des adresses IP : elles jouent un rôle essentiel pour empêcher le vandalisme et le harcèlement sur nos wikis. Il est très important que les patrouilleurs, les administrateurs et les fonctionnaires disposent d'outils capables d'identifier et de bloquer les vandales, les faux-nez, les éditeurs en conflit d'intérêts et autres acteurs néfastes. En travaillant avec vous, nous voulons trouver des moyens de protéger la vie privée de nos utilisateurs tout en maintenant nos outils anti-vandalisme au même niveau que leur fonctionnement actuel. La partie la plus importante de ceci est le développement de nouveaux outils pour aider à lutter contre le vandalisme. Une fois cela fait, nous espérons travailler sur la protection des adresses IP de nos wikis, notamment en limitant le nombre de personnes pouvant voir les adresses IP des autres utilisateurs et en réduisant la durée de stockage des adresses IP dans nos bases de données et journaux. Il est important de noter qu'une partie essentielle de ce travail sera de s'assurer que nos wikis ont toujours accès au même - ou meilleur - niveau d'outils anti-vandalisme et ne risquent pas d'être victimes d'abus.

L'objectif de la Wikimedia Foundation est de créer un ensemble d'outils de modération qui élimineront le besoin de chacun d'avoir un accès direct aux adresses IP. Avec cette évolution de nos outils de modération, nous pourrons masquer les IP des comptes non enregistrés. Nous sommes pleinement conscients que ce changement aura un impact sur les flux de travail de modération actuels, et nous voulons nous assurer que les nouveaux outils permettront une modération efficace, protégeront les projets du vandalisme et soutiendront la surveillance effectuée par la communauté.

Nous ne pouvons atteindre ce but qu'en travaillant en partenariat avec les vérificateurs d'adresses IP, stewards, administrateurs et autres combattants anti-vandales.

C'est un défi très difficile à relever, avec des risques pour notre capacité à protéger nos wikis si nous échouons, c'est pourquoi il a été repoussé au fil des ans. Mais à la lumière de l'évolution des normes de confidentialité des données sur Internet, des nouvelles lois et des attentes changeantes des utilisateurs, la fondation Wikimedia pense qu'il est maintenant temps de s'attaquer à ce défi.

Mises à jour

30 août 2021

Hello. This is a brief update about Portuguese Wikipedia’s metrics since they started requiring registration to edit. We have a comprehensive report on the Impact report page. This report includes metrics captured through data as well as a survey that was conducted among active Portuguese Wikipedia contributors. All in all, the report presents the change in a positive light. We have not seen any significant disruption over the time period these metrics have been captured. In light of this, we are now encouraged to run an experiment on two more projects to see if we observe similar impact. All projects are unique in their own ways and what holds true for Portuguese Wikipedia might not hold true for another project. We want to run a limited-time experiment on two projects where registration will be required in order to edit. We estimate that it will take approximately 8 months for us to collect enough data to see significant changes. After that time period, we will return to not requiring registration to edit while we analyse the data. Once the data is published, the community will be able to decide for themselves whether or not they want to continue to disallow unregistered editing on the project.

We are calling this the Login Required Experiment. You will find more detail as well as a timeline on that page. Please use that page and its talk page to discuss this further.

10 juin 2021

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 ».

Proposition pour partager les adresses IP avec ceux qui ont besoin d'accès

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 ?

Mise à jour sur le développement de l'outil

Comme vous le savez peut-être déjà, nous travaillons à la création de nouveaux outils, en partie pour atténuer l'impact du masquage IP, mais aussi simplement pour créer de meilleurs outils anti-vandalisme pour tout le monde. Ce n'est un secret pour personne que l'état des outils de modération sur nos projets ne donne pas aux communautés les outils qu'elles méritent. Il y a beaucoup de possibilités d'amélioration. Nous voulons créer des outils qui facilitent le travail efficace des combattants anti-vandalisme. Nous voulons également réduire la barrière à l'entrée dans ces rôles pour les contributeurs non techniques.

Nous avons déjà parlé d'idées pour ces outils et je vais vous fournir une brève mise à jour ci-dessous. Notez que les progrès sur ces outils ont été lents au cours des derniers mois, car notre équipe travaille sur la refonte de SecurePoll pour répondre aux besoins des prochaines élections du conseil d'administration du WMF.

Fonction d'informations IP

 
Maquette pour les informations IP.

Nous construisons un outil qui affichera des informations importantes sur une adresse IP qui est couramment recherchée dans les enquêtes. Généralement, les patrouilleurs, les administrateurs et les checkusers s'appuient sur des sites Web externes pour fournir ces informations. Nous espérons leur faciliter ce processus en intégrant des informations provenant de fournisseurs IP fiables sur nos sites Web. Nous avons récemment construit un prototype et mené une série de tests utilisateurs pour valider notre approche. Nous avons constaté que la majorité des rédacteurs interrogés ont trouvé l'outil utile et ont indiqué qu'ils aimeraient l'utiliser à l'avenir. Il y a une mise à jour sur la page du projet sur laquelle j'aimerais attirer votre attention. Questions clés sur lesquelles nous aimerions avoir vos commentaires sur la page de discussion du projet :

  • Lorsque vous enquêtez sur une IP, quels types d'informations recherchez-vous ? Sur quelle page êtes-vous probablement lorsque vous recherchez ces informations ?
  • Quels types d'informations IP trouvez-vous les plus utiles ?
  • Quels types d'informations IP, lorsqu'elles sont partagées, pourraient selon vous mettre nos éditeurs anonymes en danger ?

Fonctionnalité de correspondance de l'éditeur

Ce projet a également été appelé « Éditeurs à proximité » et « Détection de faux-nez » dans des conversations antérieures. Nous essayons de lui trouver un nom approprié qui soit compréhensible même pour les personnes qui ne comprennent pas le mot sockpuppetry (faux-nez).

Nous sommes aux premiers stades du projet de détection des faux-nez dans les projets Wikimédia qui pourrait aider à détecter quand deux éditeurs présentent des comportements d'édition similaires. Cela aidera à connecter différents éditeurs non enregistrés lorsqu'ils éditent sous différents noms d'utilisateur de compte générés automatiquement. Nous avons eu beaucoup de soutien pour ce projet lorsque nous avons commencé à en parler il y a un an, et également des risques à développer une telle fonctionnalité. Nous prévoyons de construire un prototype à court terme et de le partager avec la communauté. Il y a une page du projet peu développée pour ce projet pour laquelle nous espérons avoir bientôt de nouveaux éléments. Vos réflexions sur ce projet sont les bienvenues sur la page de discussion du projet.

Données sur Wikipédia portugais désactivant les modifications IP

Wikipédia en portugais a interdit aux éditeurs non enregistrés d'apporter des modifications au projet l'année dernière. Au cours des derniers mois, notre équipe a collecté des données sur les répercussions de ce bouleversement sur la santé générale du projet. Nous avons également parlé à plusieurs membres de la communauté sur leur expérience. Nous travaillons sur les derniers détails pour compiler toutes les données qui présentent une image précise de l'état du projet. Nous espérons avoir une mise à jour à ce sujet dans un proche avenir.

Mises à jour précédentes

30 octobre 2020

Nous avons mis à jour la FAQ avec plus de questions que celles posées sur la page de discussion. Le service juridique de la fondation Wikimedia a ajouté une déclaration sur demande à la discussion de la page de discussion, et nous l'avons ajoutée ici aussi sur la page principale. Sur la page de discussion, nous avons essayé d'expliquer à peu près comment nous envisageons de donner aux combattants anti-vandales l'accès aux données dont ils ont besoin sans qu'ils deviennent des CheckUsers ou des administrateurs.

15 octobre 2020

Cette page était devenue en grande partie obsolète et nous avons décidé de la réécrire en partie pour refléter où nous en sommes dans le processus. Voici à quoi cela ressemblait. Nous l'avons mis à jour avec les dernières informations sur les outils sur lesquels nous travaillons, la recherche, étoffé les motivations et ajouté quelques éléments à la FAQ. Particulièrement les points pertinents sont probablement notre travail sur la fonctionnalité d'information IP, le nouvel outil CheckUser qui est maintenant en ligne sur quatre wikis et nos recherches sur la meilleure façon de gérer l'identification IP : faites-nous savoir ce dont vous avez besoin, les problèmes potentiels que vous voyez et si la combinaison d'une adresse IP avec un cookie peut être utile pour vos flux de travail.

Outils

Comme nous l'avons mentionné précédemment, notre objectif premier est de fournir de meilleurs outils anti-vandalisme à nos communautés, ce qui permettra une meilleure expérience de modération pour nos combattants du vandalisme tout en s'efforçant de rendre la chaîne d'adresses IP moins précieuse pour eux. Une autre raison importante de procéder ainsi est que les adresses IP sont difficiles à comprendre et ne sont vraiment utiles qu'aux utilisateurs avertis. Cela crée un obstacle pour les nouveaux utilisateurs qui n'ont pas de connaissances techniques pour entrer dans des rôles fonctionnels, car il y a une courbe d'apprentissage plus élevée pour eux de travailler avec des adresses IP. Nous espérons arriver à un point où nous pourrons disposer d'outils de modération que tout le monde pourra utiliser sans grandes connaissances préalables.

La première des choses auxquelles nous nous sommes attachés a été de rendre l'outil des check-users (CheckUser tool) plus flexible, puissant et facile à utiliser. C'est un outil important qui répond au besoin de détecter et bloquer des utilisateurs indésirables (en particulier ceux responsables d'abus de longue durée) sur nombre de nos projets. L'outil CU n'est plus correctement maintenu depuis de nombreuses années, et par conséquent, il est atteint d'obsolescence et manque des fonctionnalités nécessaires.

We also anticipated an uptick in the number of users who opt-in to the role of becoming a CheckUser on our projects once IP Masking goes into effect. This reinforced the need for a better, easier CheckUser experience for our users. With that in mind, the Anti-Harassment Tools team spent the past year working on improving the CheckUser tool – making it much more efficient and user-friendly. This work has also taken into account a lot of outstanding feature requests by the community. We have continually consulted with CheckUsers and stewards over the course of this project and have tried our best to deliver on their expectations. The new feature is set to go live on all projects in October 2020.

The next feature that we are working on is IP info. We decided on this project after a round of consultation on six wikis which helped us narrow down the use cases for IP addresses on our projects. It became apparent early on that there are some critical pieces of information that IP addresses provide which need to be made available for patrollers to be able to do their roles effectively. The goal for IP Info, thus, is to quickly and easily surface significant information about an IP address. IP addresses provide important information such as location, organization, possibility of being a Tor/VPN node, rDNS, listed range, to mention a few examples. By being able to show this, quickly and easily without the need for external tools everyone can’t use, we hope to be able to make it easier for patrollers to do their job. The information provided is high-level enough that we can show it without endangering the anonymous user. At the same time, it is enough information for patrollers to be able to make quality judgements about an IP address.

After IP Info we will be focusing on a finding similar editors feature. We’ll be using a machine learning model, built in collaboration with CheckUsers and trained on historical CheckUser data to compare user behavior and flag when two or more users appear to be behaving very similarly. The model will take into account which pages users are active on, their writing styles, editing times etc to make predictions about how similar two users are. We are doing our due diligence in making sure the model is as accurate as possible.

Once it’s ready, there is a lot of scope for what such a model can do. As a first step we will be launching it to help CheckUsers detect socks easily without having to perform a lot of manual labor. In the future, we can think about how we can expose this tool to more people and apply it to detect malicious sockpuppeting rings and disinformation campaigns.

You can read more and leave comments on our project page for tools.

Motivation

We who are working on this are doing this because the legal and public policy teams advised us that we should evolve the projects’ handling of IP addresses in order to keep up with current privacy standards, laws, and user expectations. That’s really the main reason.

We also think there are other compelling reasons to work on this. If someone wants to help out and don’t understand the ramifications of their IP address being publicly stored, their desire to make the world and the wiki a better place results in inadvertently sharing their personal data with the public. This is not a new discussion: we’ve had it for about as long as the Wikimedia wikis have been around. An IP address can be used to find out a user’s geographical location and institution and other personally identifiable information, depending on how the IP address was assigned and by whom. This can sometimes mean that an IP address can be used to pinpoint exactly who made an edit and from where, especially when the editor pool is small in a geographic area. Concerns around exposing IP addresses on our projects have been brought repeatedly by our communities and the Wikimedia movement as a whole has been talking about how to solve this problem for at least fifteen years. Here’s a (non-exhaustive) list of some of the previous discussions that have happened around this topic.

We acknowledge that this is a thorny issue, with the potential for causing disruptions in workflows we greatly respect and really don’t want to disrupt. We would only undertake this work, and spend so much time and energy on it, for very good reason. These are important issues independently, and together they have inspired this project: there’s both our own need and desire to protect those who want to contribute to the wikis, and developments in the world we live in, and the online environment in which the projects exist.

Recherche

 
Rapport soutenu par la Wikimedia Foundation sur l’impact du masquage IP sur notre communauté.

Impact du masquage IP

Les adresses IP constituent un identifiant partiel semi-fiable, que son utilisateur ne manipule pas facilement. Selon le fournisseur et la configuration de l'appareil, les informations d'adresse IP ne sont pas toujours exactes ni précises. De plus, une connaissance technique approfondie et une certaine aisance sont nécessaires pour utiliser au mieux les informations d'adresse IP, bien que les administrateurs ne soient pas obligés de démontrer ces aptitudes pour pouvoir y accéder. Ces informations techniques sont utilisées pour appréhender, dans la mesure du possible, des informations supplémentaires (appelées « connaissances comportementales ») et ces données extraites des adresses IP ont un impact significatif sur le cours des décisions administratives.

Sur le volet social, la question de savoir s'il fallait autoriser les utilisateurs non enregistrés à publier a fait l'objet de débats approfondis. Jusqu'ici, le débat a porté sur la possibilité de modifier pour les utilisateurs non enregistrés. Le débat oppose généralement volonté de limiter le vandalisme et désir de réduire les barrières à la contribution en laissant les utilisateurs non enregistrés modifier. Il existe un biais de perception à l'égard des utilisateurs non enregistrés en raison de leur association au vandalisme, laquelle fait également l'objet d'un biais algorithmique dans les outils tels qu'ORES. En outre, des problèmes majeurs en matière de communication sont observés lorsque l'on essaie de s'adresser à un utilisateur non enregistré, essentiellement en raison de l'absence de notifications et parce qu'il n'y a aucune assurance que c'est bien la personne visée qui lira le message déposé sur la page de discussion de l'IP.

Concernant l'impact potentiel du masquage des adresses IP, il se fera ressentir de manière significative sur le travail des administrateurs et pourrait accroître la charge de travail des vérificateurs d'adresses IP à court terme. Si/quand les adresses IP étaient/seront masquées, nous devons nous attendre à ce que la capacité des administrateurs à lutter contre le vandalisme soit fortement entravée. Cela peut être atténué en fournissant des outils avec des fonctionnalités équivalentes voire meilleures, mais nous devons anticiper une période de transition caractérisée par une moindre efficacité des administrateurs. Dans l'objectif de fournir des outils appropriés au travail des administrateurs, nous devons nous attacher à préserver ou à fournir des alternatives pour les fonctions suivantes, actuellement assurées par la publication des adresses IP :

  • Efficacité des blocages et estimation des effets collatéraux ;
  • Une manière de faire ressortir des similitudes ou des motifs (pattern) parmi les utilisateurs non enregistrés, tels que des similitudes géographiques ou l'appartenance à des institutions (par exemple si les modifications proviennent d'un établissement scolaire ou du supérieur) ;
  • La possibilité de viser certains groupes spécifiques d'utilisateurs non enregistrés tels que des vandales utilisant plusieurs IP au sein d'une plage d'adresses IP déterminée ;
  • La faculté d'opérer des actions (pas nécessairement des blocages) liées à la localisation géographique ou l'institution rattachée à l'adresse IP, par exemple la capacité à déterminer si des modifications sont effectuées par un proxy ouvert, ou bien à identifier qu'il s'agit d'un lieu public tel qu'une école ou une bibliothèque.

Selon la manière dont nous traitons les comptes temporaires ou identifiants dédiés aux utilisateurs non enregistrés, nous pourrions être en mesure d'améliorer la communication avec ces derniers. Il est peu probable que les débats et inquiétudes relatifs aux modifications par des utilisateurs non enregistrés, au vandalisme sous adresse IP et aux préjugés sur les utilisateurs non enregistrés changent significativement si nous masquons les adresses IP et que nous maintenons la capacité de modifier les projets sans être connecté.

CheckUser workflow

We interviewed CheckUsers on multiple projects throughout our process for designing the new Special:Investigate tool. Based on interviews and walkthroughs of real-life cases, we broke down the general CheckUser workflow into five sections:

  • Triaging: assessing cases for feasibility and complexity.
  • Profiling: creating a pattern of behaviour which will identify the user behind multiple accounts.
  • Checking: examining IPs and useragents using the CheckUser tool.
  • Judgement: matching this technical information against the behavioural information established in the Profiling step, in order to make a final decision about what kind of administrative action to take.
  • Closing: reporting the outcome of the investigation on public and private platforms where necessary, and appropriately archiving information for future use.

We also worked with staff from Trust and Safety to get a sense for how the CheckUser tool factors into Wikimedia Foundation investigations and cases that are escalated to T&S.

The most common and obvious pain points all revolved around the CheckUser tool's unintuitive information presentation, and the need to open up every single link in a new tab. This cause massive confusion as tab proliferation quickly got out of hand. To make matters worse, the information that CheckUser surfaces is highly technical and not easy to understand at first glance, making the tabs difficult to track. All of our interviewees said that they resorted to separate software or physical pen and paper in order to keep track of information.

We also ran some basic analyses of English Wikipedia's Sockpuppet Investigations page to get some baseline metrics on how many cases they process, how many are rejected, and how many sockpuppets a given report contains.

Utilisation des adresses IP par les patrouilleurs

Previous research on patrolling on our projects has generally focused on the workload or workflow of patrollers. Most recently, the Patrolling on Wikipedia study focuses on the workflows of patrollers and identifying potential threats to current anti-vandal practices. Older studies, such as the New Page Patrol survey and the Patroller work load study, focused on English Wikipedia. They also look solely at the workload of patrollers, and more specifically on how bot patrolling tools have affected patroller workloads.

Notre étude a tenté de recruter à partir de cinq wikis cibles, qui étaient :

  • Wikipédia en japonais
  • Wikipédia en hollandais
  • Wikipédia en allemand
  • Wikipédia en chinois
  • Wikiquote en anglais

Ils ont été sélectionnés pour leurs attitudes connues à l'égard des modifications IP, le pourcentage de modifications mensuelles effectuées par les IP et toute autre circonstance unique ou inhabituelle rencontrée par les éditeurs IP (à savoir, l'utilisation de la fonction Modifications en attente et l'utilisation répandue des proxys). Les participants ont été recrutés via des appels ouverts sur les bistrots ou l'équivalent local. Dans la mesure du possible, nous avons également publié sur les pages ambassadrices Wiki. Malheureusement, alors que nous disposions du support d'interpréteurs pour les entretiens eux-mêmes, nous n'avons pas étendu le support de traduction aux messages, ce qui peut expliquer les faibles taux de réponse. Tous les entretiens ont été menés via Zoom, en présence d'un preneur de notes.

Supporting the findings from previous studies, we did not find a systematic or unified use of IP information. Additionally, this information was only sought out after a certain threshold of suspicion. Most further investigation of suspicious user activity begins with publicly available on-wiki information, such as checking previous local edits, Global Contributions, or looking for previous bans.

Precision and accuracy were less important qualities for IP information: upon seeing that one chosen IP information site returned three different results for the geographical location of the same IP address, one of our interviewees mentioned that precision in location was not as important as consistency. That is to say, so long as an IP address was consistently exposed as being from one country, it mattered less if it was correct or precise. This fits with our understanding of how IP address information is used: as a semi-unique piece of information associated with a single device or person, that is relatively hard to spoof for the average person. The accuracy or precision of the information attached to the user is less important than the fact that it is attached and difficult to change.

Our findings highlight a few key design aspects for the IP info tool:

  • Provide at-a-glance conclusions over raw data
  • Cover key aspects of IP information:
    • Geolocation (to a city or district level where possible)
    • Registered organization
    • Connection type (high-traffic, such as data center or mobile network versus low-traffic, such as residential broadband)
    • Proxy status as binary yes or no

D'un point de vue éthique, il sera important de pouvoir expliquer comment les conclusions sont tirées et les inexactitudes ou les imprécisions inhérentes à l'extraction des informations IP. Bien que ce n'était pas une préoccupation majeure pour les patrouilleurs à qui nous avons parlé, si nous voulons créer un outil qui servira à justifier une action administrative, nous devons prendre soin de préciser quelles sont les limites de nos outils.

IP Masking Implementation Approaches (FAQ)

October 2021

This FAQ helps answer some likely questions the community will have about the various implementation approaches we can take for IP Masking and how each of them will impact the community.

Q: Following implementation of IP Masking, who will be able to see IP addresses?

A: Checkusers, stewards and admins will be able to see complete IP addresses by opting-in to a preference where they agree not to share it with others who don't have access to this information.

Editors who partake in anti-vandalism activities, as vetted by the community, can be granted a right to see IP addresses to continue their work. This user right would be handled like other user rights by the community, and require a minimum number of edits and days spent editing.

All users with accounts over a certain age and with a minimum number of edits (to be determined) will be able to access partially unmasked IPs without permission. This means an IP address will appear with its tail octet(s) – the last parts – hidden. This will be accessible via a preference where they agree not to share it with others who don't have access to this information.

All other users will not be able to access IP addresses for unregistered users.

Q: What are the potential technical implementation options?

A: Over the last few weeks we have been engaged in multiple discussions about the technical possibilities to accomplish our goal for IP Masking while minimizing impact to our editors and readers. We gathered feedback from across different teams and gained varying perspectives. Below are the two key paths.

  • IP based identity: In this approach, we keep everything as is but replace existing IP addresses with a hashed version of IPs. This preserves a lot of our existing workflows but does not offer any new benefits.
  • Session based identity: In this approach, we create an identity for the unregistered editors based on a browser cookie which identifies their device browser. The cookie persists even when their IP address changes hence their session does not end.

Q: How does IP based identity path work?

A: At present, unregistered editors are identified by their IP addresses. This model has worked for our projects for many years. Users well-versed with IP addresses understand that a single IP address can be used by multiple different users based on how dynamic that IP address is. This is more true for IPv6 IP addresses than IPv4.

An unregistered user may also change IP addresses if they are commuting or editing from a different location. If we pursue the IP-based identity solution for IP Masking, we would be preserving the way IP addresses function today by simply masking them with an encrypted identifier. This solution will keep the IPs distinct while maintaining user privacy. For example, an unregistered user such as User:192.168.1.2 may appear as User:ca1f46.

Benefits of this approach: Preserves existing workflows and models with minimal disruption

Drawbacks of this approach: Does not offer any advantages in a world moving rapidly towards more dynamic/less useful IP addresses

Q: How does session-based identity path work?

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.

In this approach, the user’s session will persist as long as they have the cookie, even when they change IP addresses.

Benefits of this approach:

  • Ties the user-identity to a device browser, offering a more persistent way to communicate with them.
  • User identity does not change with changing IP addresses
  • 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

Drawbacks of this approach:

  • Significant change in the current model of what an unregistered editor represents
  • The identity for the unregistered editor only persists as long as the browser cookie does
  • Vandals in privacy mode or who delete their cookies would get a new identity without changing their IP
  • May require rethinking of some community workflows and tools

Q: Does the Foundation have a preferred path or approach?

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.

You can talk to us about these approaches, on the talk page.

Déclaration du service juridique de la fondation Wikimedia

July 2021

First of all, we’d like to thank everyone for participating in these discussions. We appreciate the attention to detail, the careful consideration, and the time that has gone into engaging in this conversation, raising questions and concerns, and suggesting ways that the introduction of masked IPs can be successful. Today, we’d like to explain in a bit more detail how this project came about and the risks that inspired this work, answer some of the questions that have been raised so far, and briefly talk about next steps.

Background

To explain how we arrived here, we’d like to briefly look backwards. Wikipedia and its sibling projects were built to last. Sharing the sum of all knowledge isn’t something that can be done in a year, or ten years, or any of our lifetimes. But while the mission of the communities and Foundation was created for the long term, the technical and governance structures that enable that mission were very much of the time they were designed. Many of these features have endured, and thrived, as the context in which they operate has changed. Over the last 20 years, a lot has evolved: the way societies use and relate to the internet, the regulations and policies that impact how online platforms run as well as the expectations that users have for how a website will handle their data.

In the past five years in particular, users and governments have become more and more concerned about online privacy and the collection, storage, handling, and sharing of personal data. In many ways, the projects were ahead of the rest of the internet: privacy and anonymity are key to users’ ability to share and consume free knowledge. The Foundation has long collected little information about users, not required an email address for registration, and recognized that IP addresses are personal data (see, for example, the 2014–2018 version of our Privacy policy). More recently, the conversation about privacy has begun to shift, inspiring new laws and best practices: the European Union’s General Data Protection Regulation, which went into effect in May 2018, has set the tone for a global dialogue about personal data and what rights individuals should have to understand and control its use. In the last few years, data protection laws around the world have been changing—look at the range of conversations, draft bills, and new laws in, for example, Brazil, India, Japan, or the United States.

Legal risks

The Foundation’s Privacy team is consistently monitoring this conversation, assessing our practices, and planning for the future. It is our job to look at the projects of today, and evaluate how we can help prepare them to operate within the legal and societal frameworks of tomorrow. A few years ago, as part of this work, we assessed that the current system of publishing IP addresses of non-logged-in contributors should change. We believe it creates risk to users whose information is published in this way. Many do not expect it—even with the notices explaining how attribution works on the projects, the Privacy team often hears from users who have made an edit and are surprised to see their IP address on the history page. Some of them are in locations where the projects are controversial, and they worry that the exposure of their IP address may allow their government to target them. The legal frameworks that we foresaw are in operation, and the publication of these IP addresses pose real risks to the projects and users today.

We’ve heard from several of you that you want to understand more deeply what the legal risks are that inspired this project, whether the Foundation is currently facing legal action, what consequences we think might result if we do not mask IP addresses, etc. (many of these questions have been collected in the expanded list at the end of this section). We’re sorry that we can’t provide more information, since we need to keep some details of the risks privileged. “Privileged” means that a lawyer must keep something confidential, because revealing it could cause harm to their client. That’s why privilege is rarely waived; it’s a formal concept in the legal systems of multiple countries, and it exists for very practical reasons—to protect the client. Here, waiving the privilege and revealing this information could harm the projects and the Foundation. Generally, the Legal Affairs team works to be as transparent as possible; however, an important part of our legal strategy is to approach each problem on a case by case basis. If we publicly discuss privileged information about what specific arguments might be made, or what risks we think are most likely to result in litigation, that could create a road map by which someone could seek to harm the projects and the communities.

That said, we have examined this risk from several angles, taking into account the legal and policy situation in various countries around the world, as well as concerns and oversight requests from users whose IP addresses have been published, and we concluded that IP addresses of non-logged-in users should no longer be publicly visible, largely because they can be associated with a single user or device, and therefore could be used to identify and locate non-logged-in users and link them with their on-wiki activity.

Despite these concerns, we also understood that IP addresses play a major part in the protection of the projects, allowing users to fight vandalism and abuse. We knew that this was a question we’d need to tackle holistically. That’s why a working group from different parts of the Wikimedia Foundation was assembled to examine this question and make a recommendation to senior leadership. When the decision was taken to proceed with IP masking, we all understood that we needed to do this with the communities—that only by taking your observations and ideas into account would we be able to successfully move through this transition.

I want to emphasize that even when IP addresses are masked and new tools are in place to support your anti-vandalism work, this project will not simply end. It’s going to be an iterative process—we will want feedback from you as to what works and what doesn’t, so that the new tools can be improved and adapted to fit your needs.

Questions

Over the past months, you’ve had questions, and often, we’ve been unable to provide the level of detail you’re hoping for in our answers, particularly around legal issues.

What specific legal risks are you worried about?

We cannot provide details about the individual legal risks that we are evaluating. We realize it’s frustrating to ask why and simply get, “that’s privileged” as an answer. And we’re sorry that we cannot provide more specifics, but as explained above, we do need to keep the details of our risk assessment, and the potential legal issues we see on the horizon, confidential, because providing those details could help someone figure out how to harm the projects, communities, and Foundation.

There are settled answers to some questions.

Is this project proceeding?

Yes, we are moving forward with finding and executing on the best way to hide IP addresses of non-logged-in contributors, while preserving the communities’ ability to protect the projects.

Can this change be rolled out differently by location?

No. We strive to protect the privacy of all users to the same standard; this will change across the Wikimedia projects.

If other information about non-logged-in contributors is revealed (such as location, or ISP), then it doesn’t matter if the IP address is also published, right?

That’s not quite the case. In the new system, the information we make available will be general information that is not linked to an individual person or device—for example, providing a city-level location, or noting that an edit was made by someone at a particular university. While this is still information about the user, it’s less specific and individual than an IP address. So even though we are making some information available in order to assist with abuse prevention, we are doing a better job of protecting the privacy of that specific contributor.

If we tell someone their IP address will be published, isn’t that enough?

No. As mentioned above, many people have been confused to see their IP address published. Additionally, even when someone does see the notice, the Foundation has legal responsibilities to properly handle their personal data. We have concluded that we should not publish the IP addresses of non-logged-in contributors because it falls short of current privacy best practices, and because of the risks it creates, including risks to those users.

How will masking impact CC-BY-SA attribution?

IP masking will not affect CC license attribution on Wikipedia. The 3.0 license for text on the Wikimedia projects already states that attribution should include “​​the name of the Original Author (or pseudonym, if applicable)” (see the license at section 4c) and use of an IP masking structure rather than an IP address functions equally well as a pseudonym. IP addresses already may vary or be assigned to different people over time, so using that as a proxy for un-registered editors is not different in quality from an IP masking structure and both satisfy the license pseudonym structure. In addition, our Terms of use section 7 specify that as part of contributing to Wikipedia, editors agree that links to articles (which include article history) are a sufficient method of attribution.

And sometimes, we don’t know the answer to a question yet, because we’d like to work with you to find the solution.

What should the specific qualifications be for someone to apply for this new user right?

There will be an age limit; we have not made a definitive decision about the limit yet, but it’s likely they will need to be at least 16 years old. Additionally, they should be active, established community members in good standing. We’d like to work through what that means with you.

I see that the team preparing these changes is proposing to create a new userright for users to have access to the IP addresses behind a mask. Does Legal have an opinion on whether access to the full IP address associated with a particular username mask constitutes nonpublic personal information as defined by the Confidentiality agreement for nonpublic information, and will users seeking this new userright be required to sign the Access to nonpublic personal data policy or some version of it?
1 If yes, then will I as a checkuser be able to discuss relationships between registered accounts and their IP addresses with holders of this new userright, as I currently do with other signatories?
2 If no, then could someone try to explain why we are going to all this trouble for information that we don't consider nonpublic?
3 In either case, will a checkuser be permitted to disclose connections between registered accounts and unregistered username masks?

This is a great question. The answer is partially yes. First, yes, anyone who has access to the right will need to acknowledge in some way that they are accessing this information for the purposes of fighting vandalism and abuse on the projects. We are working on how this acknowledgement will be made; the process to gain access is likely to be something less complex than signing the access to non-public personal data agreement.

As to how this would impact CUs, right now, the access to non-public personal data policy allows users with access to non-public personal data to share that data with other users who are also able to view it. So a CU can share data with other CUs in order to carry out their work. Here, we are maintaining a distinction between logged-in and logged-out users, so a CU would not be able to share IP addresses of logged-in users with users who have this new right, because users with the new right would not have access to such information.

Presuming that the CU also opts in to see IP addresses of non-logged-in users, under the current scheme, that CU would be able to share IP address information demonstrating connections between logged-in users and non-logged-in users who had been masked with other CUs who had also opted in. They could also indicate to users with the new right that they detected connections between logged-in and non-logged-in users. However, the CU could not directly the share IP addresses of the logged-in users with non-CU users who only have the new right.

Please let us know if this sounds unworkable. As mentioned above, we are figuring out the details, and want to get your feedback to make sure it works.

Next steps

Over the next few months, we will be rolling out more detailed plans and prototypes for the tools we are building or planning to build. We’ll want to get your feedback on these new tools that will help protect the projects. We’ll continue to try to answer your questions when we can, and seek your thoughts when we should arrive at the answer together. With your feedback, we can create a plan that will allow us to better protect non-logged-in editors’ personal data, while not sacrificing the protection of Wikimedia users or sites. We appreciate your ideas, your questions, and your engagement with this project.

October 2020

Cette déclaration du département juridique de la fondation Wikimedia a été écrite à la demande de la page de discussion et vient de ce contexte. Pour plus de visibilité, nous voulions que vous puissiez le lire ici aussi.

Hello All. This is a note from the Legal Affairs team. First, we’d like to thank everyone for their thoughtful comments. Please understand that sometimes, as lawyers, we can’t publicly share all of the details of our thinking; but we read your comments and perspectives, and they’re very helpful for us in advising the Foundation.

On some occasions, we need to keep specifics of our work or our advice to the organization confidential, due to the rules of legal ethics and legal privilege that control how lawyers must handle information about the work they do. We realize that our inability to spell out precisely what we’re thinking and why we might or might not do something can be frustrating in some instances, including this one. Although we can’t always disclose the details, we can confirm that our overall goals are to do the best we can to protect the projects and the communities at the same time as we ensure that the Foundation follows applicable law.

Within the Legal Affairs team, the privacy group focuses on ensuring that the Foundation-hosted sites and our data collection and handling practices are in line with relevant law, with our own privacy-related policies, and with our privacy values. We believe that individual privacy for contributors and readers is necessary to enable the creation, sharing, and consumption of free knowledge worldwide. As part of that work, we look first at applicable law, further informed by a mosaic of user questions, concerns, and requests, public policy concerns, organizational policies, and industry best practices to help steer privacy-related work at the Foundation. We take these inputs, and we design a legal strategy for the Foundation that guides our approach to privacy and related issues. In this particular case, careful consideration of these factors has led us to this effort to mask IPs of non-logged-in editors from exposure to all visitors to the Wikimedia projects. We can’t spell out the precise details of our deliberations, or the internal discussions and analyses that lay behind this decision, for the reasons discussed above regarding legal ethics and privilege.

We want to emphasize that the specifics of how we do this are flexible; we are looking for the best way to achieve this goal in line with supporting community needs. There are several potential options on the table, and we want to make sure that we find the implementation in partnership with you. We realize that you may have more questions, and we want to be clear upfront that in this dialogue we may not be able to answer the ones that have legal aspects. Thank you to everyone who has taken the time to consider this work and provide your opinions, concerns, and ideas.