Discussion Wikipédia:Vérificateur d'utilisateurs

Archives

/Archives 2006 - 2018
/Archives 2019 - 2023

Vérificateur d'utilisateurs

Données clés

Requêtes

Journal

Page de discussion

Liste vérificateurs

Renouvellement

Coordination

Accès au statut

Bonjour , je n'ai pas trop compris comment pouvoir accédé au statut . Quelqu'un pour m'aider ? UnePetiteFraise (discuter) 24 juillet 2023 à 19:09 (CEST)

Bonjour @Project sekai, la nomination des CU est réalisée par le comité de nomination à intervalle plus ou moins régulier (environ tous les 6/8 mois). Si besoin le comité lance des appels à candidatures (comme ce fut le cas en début juillet) et se concerte pour nommer ou non ces personnes. Il n'y a pas de candidatures spontannées possibles. Cela répond à votre question ? Goombiis •~Δ~• 24 juillet 2023 à 19:16 (CEST)

Oui merci bcp :) UnePetiteFraise (discuter) 24 juillet 2023 à 19:36 (CEST)

Interface

Bonjour,

@Durifon, @Hyméros, @Le chat perché, @Lewisiscrazy, @Linedwell et @Mathis B

Puisque nous avons commencé une discussion privée au sujet de IPQualityScore, je vous propose de la poursuivre ici (publiquement).

En préambule, il apparaît que IPQualityScore ne soit pas l'outil le plus complet ou fiable par rapport à d'autres, ni pour les CU, ni pour la communauté.

Ainsi, je propose de faire un bilan des outils puis de modifier l'interface en conséquence, notamment :

• MediaWiki:Checkuser-toollinks
• MediaWiki:Sp-contributions-footer-anon

Proposition quasi-exhaustive pour MediaWiki:Checkuser-toollinks :

<span class="plainlinks" style="font-size: 9pt;">&#91;[[Special:Contributions/$1|contribs]] <sup>([//tools.wmflabs.org/guc?user=$1 globales] - [[Spécial:Contributions supprimées/$1|supprimées]] - [{{fullurl:Special:Journal_du_filtre_antiabus|wpSearchUser=$1}} filtrées])</sup> – [https://whois-referral.toolforge.org/gateway.py?lookup=true&ip=$1 Whois] – [https://meta3.toolforge.org/stalktoy/{{remplace|$1|%3A|:}} Stalktoy] – [https://ipcheck.toolforge.org/index.php?ip={{remplace|$1|%3A|:}} IPCheck] <sup>([https://spur.us/context/{{remplace|$1|%3A|:}} Spur] - [https://ipinfo.io/{{remplace|$1|%3A|:}} IPInfo] - [https://db-ip.com/{{remplace|$1|%3A|:}} DB-IP] - [https://ipcost.com/fr IPcost] - [https://stopforumspam.com/search/{{remplace|$1|%3A|:}} StopForumSpam])</sup> – [https://whatismyipaddress.com/ip/{{remplace|$1|%3A|:}} geolocate] <sup>([https://bullseye.toolforge.org/ip/{{remplace|$1|%3A|:}} Bullseye] - [https://www.ip2location.com/{{remplace|$1|%3A|:}} IP2Loc] - [https://www.ipalyzer.com/$1 IPv4] - [https://ip-lookup.net/?ip=$1 IPv6])</sup> –  WEB <sup>([https://www.google.com/search?safe=off&num=50&hl=en&q=$1 Google] - 
[http://{{remplace|$1|%3A|:}} http] – 
[https://{{remplace|$1|%3A|:}} https])</sup> – [[:mw:Help:Range_blocks/fr|Range blocks]] – [https://ftools.toolforge.org/general/ip-range-calc.html Calc]&#93;</span>

rendu :

[contribs (globales - supprimées - filtrées) – Whois – Stalktoy – IPCheck (Spur - IPInfo - DB-IP - IPcost - StopForumSpam) – geolocate (Bullseye - IP2Loc - IPv4 - IPv6) – WEB (Google - http - https) – Range blocks – Calc]

Par rapport à l'actuel, j'ajoute des ressources listées sur Wikipédia:Proxy ouvert ainsi que d'autres qui s'avèrent (parfois) utiles, tout en retirant IPQS. Reste à voir si on veut retirer certains liens ou en ajouter (notamment rangeblockfinder). Pas sûr que Special:CheckUserLog soit pertinent, on vérifie généralement avant mais c'est une possibilité. Je ne trouve pas le lien Google hyper utile.

Pour MediaWiki:Sp-contributions-footer-anon, j'aurais tendance à faire plus court mais je n'ai pas de proposition, si ce n'est que de retirer Aliveproxy et IPQualityScore ; sinon d'avoir les RIR comme sur en:MediaWiki:Sp-contributions-footer-anon.

D'ailleurs, je pourrais aussi modifier Utilisateur:LD/PV.js et {{u+}} auxquels j'avais ajouté IPQS car il me semble qu'il y ait des alternatives plus complètes. LD (d) 20 mars 2024 à 16:45 (CET)

La liste d'outils que tu proposes me semble utile, tant pour les profils techniques (comme les CU) que pour les autres. Pour IPQualityScore, je suis d'accord quand à son manque de fiabilité. Linedwell ^[discuter] 20 mars 2024 à 17:15 (CET)

Même remarques. D'ailleurs, je n'utilise jamais IPQS --Hyméros ^{--}-≽ ♥} 20 mars 2024 à 17:32 (CET)

Ça me semble bien aussi. --Mathis B ^discuter, le 20 mars 2024 à 17:55 (CET)

OK ça a l'air bien. On trouve des IPs sur google des fois? --Lewisiscrazy (discuter) 20 mars 2024 à 18:35 (CET)

Oui, @Lewisiscrazy, mais ça dépend de l'indexation ; par exemple 1.1.1.1 (u · d · b) (Cloudflare) renvoie des infos dans Google. C'est davantage utile pour identifier un domaine (DNS), sinon les autres outils renvoient des données plus rapidement. LD (d) 20 mars 2024 à 20:34 (CET)

Pas d'objection non plus @LD, au contraire. Même si ce serait bien préférable que la WMF améliore nos outils de CU afin de disposer directement de ce type d'information... Le chat perché (discuter) 20 mars 2024 à 21:30 (CET)

@LD, au passage tu ne croyais pas si bien dire car l'IP 1.1.1.1 est globalement bloquée plusieurs années comme proxy alors qu'IPQS donne un score de 0. Le chat perché (discuter) 20 mars 2024 à 21:33 (CET)

@Le chat perché : 1.1.1.1 est un DNS et non un VPN/proxy ouvert, donc le score de zéro me paraît normal.

Le blocage global de 1.1.1.1 est un dommage collatéral dû au blocage de toutes les plages qui appartiennent à Cloudflare depuis qu’ils proposent un VPN gratuit (WARP) et un service de relais privé avec Apple. — Thibaut (discuter) 4 avril 2024 à 19:54 (CEST)

┌─────────────────────────────────────────────────┘
Re @Durifon, @Hyméros, @Le chat perché, @Lewisiscrazy, @Linedwell et @Mathis B

Vu ci-dessus, j'ai appliqué la proposition. Je regarde (j'espère) ce weekend pour le reste des propositions. LD (d) 4 avril 2024 à 19:02 (CEST)

Bonjour !

Si IPQS est retiré de MediaWiki:Sp-contributions-footer-anon, j’ai quelques questions :

1. J’utilise régulièrement IPQS et si j’ai pu observer quelques faux positifs (VPN d’entreprise), l’outil me paraît généralement fiable, quels sont les problèmes qui ont pu être observés par les CU ?
2. Est-ce qu’un outil similaire va être proposé à la place ? Et si oui, lequel ?

Proposition : le site https://abuseipdb.com où les adresses IP malveillantes sont automatiquement signalées par les outils de détection installés sur les serveurs qui sont exposés à Internet (dont celui de Wikiwix) est également un bon outil à ajouter à votre panoplie : MediaWiki:Checkuser-toollinks. — Thibaut (discuter) 4 avril 2024 à 19:47 (CEST)

Cf. aussi MediaWiki:Sp-contributions-footer-anon. — Jules* ^discuter 4 avril 2024 à 19:59 (CEST)

Il semble qu'IPQS note en fonction de critères qui ne sont pas spécifiquement que des identifications de proxy mais aussi des signalements de spam par exemple. Bullseye est une solution qu'on s'est préconnisé côté CU. Certes c'est moins visuel mais c'est plus précis. En comparant les faux positifs d'IPQS on a vu la différence. Le chat perché (discuter) 4 avril 2024 à 20:04 (CEST)

Bonjour, même si cette discussion ne concerne que les CU, j'en profite pour faire part de mes réflexions commencées ici et développées plus amplement sur Discussion MediaWiki:Sp-contributions-footer-anon#Erreur de libellé pour Bullseye / autres outils (qui peut-être vous donnera d'autres idées). En bref et a minima, la suppression d'IPQualityScore de MediaWiki:Sp-contributions-footer-anon, Utilisateur:LD/PV.js et {{u+}} paraît plus que souhaitable pour éviter les faux positifs concernant la détection des proxies. Cordialement. --Ciseleur (d) 4 avril 2024 à 22:25 (CEST) / 4 avril 2024 à 22:32 (CEST)

Bonjour @Thibaut120094,

Pardonne-moi si c'est (trop) long, technique et ancré sur mon expérience. Il me semble utile de résumer les principaux points et je tâcherai de répondre aux questions qui subsistent. A prendre comme mes deux sous.

De manière générale, IPQS évalue la confiance attribuée à une IP via une base déclarative (~webmasters) ou des bases de données (point n°1), et, semble-t-il, via un modèle prédictif (point n°2) :

1. Une base déclarative est généralement fiable, à condition que les données soient à jour et que la déclaration soit fidèle à ce qu'on cherche :
   • Être à jour est important car l'attribution et réattribution des plages d'IP ou des IP est fréquente ; ce n'est pas parce que l'IP X.X.X.X cachait LD en 2022 que c'est encore valable en 2024 ;
   • Fidèle à ce qu'on cherche est important car sur Wikipédia, par exemple, on n'a pas besoin de savoir que LD utilise son IP pour indexer des pages web ou faire du web scraping (ce qui est un critère de suspicion...).
2. Une base prédictive est généralement peu fiable, sauf si le propriétaire du réseau pratique un faible réattribution et/ou que le modèle est robuste sur l'estimation des actions humaines (sachant que les Humanités [économie, démographie, ...] se trompent souvent à long terme [cf. entropie], permettez-moi de douter de la robutesse des prédictions humaines : déménager, prendre un vol, ... qui peut prédire cet aléatoire ? ). Faible réattribution veut dire : que le fournisseur te permette d'emprunter moins de routes que celles disponibles, ce qui est aujourd'hui contraire aux politiques de vie privée (US, UE, ...).
   • Par expérience, on peut remarquer que IPSQ extrapole : une IP proche d'une autre IP problématique sera traîtée avec plus de suspicion, mais sachant que les grands fournisseurs (US, UE, etc.) t'attribue régulièrement une IP parmi un grand échantillon, on obtient vite un tas d'IP qui sont douteuses ; bien plus que nécessaire / plausible / raisonnable. Exemple : n'importe quel réseau d'Orange en Afrique, à quelques exceptions près.
   • Plus technique / précis (mes hypothèses) : on remarque des données aberrantes (=erreurs d'estimation) car l'évaluation ressemble à du clustering, c'est-à-dire une tentative de rapprocher une donnée connue (souvent déclarée) avec une donnée inconnue. (Je pense que c'est un choix marketing car la base varie de ~400 à 2.000$/mois selon l'offre : vaut mieux renvoyer une estimation, même moins fiable, que ne rien renvoyer.). Concrètement, si X.X.X.1 est douteuse, probablement car déclarée comme telle, je remarque souvent que X.X.X.2 l'est aussi, même si les deux IPs sont fixes (non réattribuées sur un long laps de temps) et possédées par deux personnes différentes. La raison la plus probable de cette erreur est qu'IPQS analyse ses données en pratiquant de la prédiction (ce qui est une pratique courrante en sciences des données). Personnellement, je préfère un outil qui me dise "je n'en sais rien".

Pour rebondir sur la notion de confiance, elle est relative :

• Envoyer des emails publiciaires est douteux selon IPQS, sauf que Wikipédia n'est pas un serveur de messagerie (cf. Le chat perché) ;
• Des entreprises respectables offrent des services d'anonymisation ou d'hébergement, sauf que ce sont des accès incompatibles avec Wikipédia : de notre point de vue, IPQS accorde une trop grande confiance à ces entreprises (=IP non cataloguées comme douteuses) : c'est l'exemple donnée ci-dessus avec Cloudflare.

Ainsi, les outils proposés côté CU se recentrent sur les couches et le type d'IP, c'est-à-dire ce qu'on cherche à savoir : est-ce que l'IP est une passerelle entre Wikipédia et un utilisateur ?, est-ce que cela anonymise / cache sa véritable IP ?, etc. Il n'est pas utile d'avoir des suppositions sur les actions ; l'analyse humaine des CU à partir des données dont les contributions suffisent à dire s'il a une bonne ou mauvaise utilisation du réseau ou de Wikipédia, même s'il y a toujours une marge d'erreur (que le CU communique).

Pour MediaWiki:Sp-contributions-footer-anon, je pensais faire une proposition ce weekend (si j'ai le temps). Le but est d'avoir des outils simples à appréhender et en adéquation avec ce que nous cherchons à éviter (anonymisation grosso modo). Beaucoup de considérations d'IPQS sont hors-sujet (bot, emails, appels téléphoniques, ...). LD (d) 4 avril 2024 à 23:18 (CEST)

@LD,

Merci pour cette longue mais instructive analyse. Dans mon contexte pro IRL, qui n'est certes pas lié au IP, j'ai travaillé avec un presta d'un type approchant de IPQS. Voici quelques éléments :

• La note donnée est un scoring et non une affirmation. Ce scoring se base en partie sur du prédictif et en partie sur les remontées des clients de la société qui score. Ce qui est en partie circulaire car le modèle prédictif est en partie basé sur les remontées des clients. Ce en quoi dans le contexte que j'ai connu on a commencé à se dire qu'on pourrait faire mieux (et donc plus économique) nous même sans intermédiaire.
• Le modèle de scoring ne donne pas strictement une réponse mais une note de risque. Note qui doit être appréciée à la lumière de ce qui est noté et de l'intérêt du "noteur". Pour IPQS la note étant plutôt une appréciation des risque possibles pondérés par les avérés (via des déclaratifs tierces) des IP. Le risque n'ayant pas une définition similaire à ce qui est délimité par la WMF. En l'occurence bloquer les IP qui anonymisent, qui permettent à autrui de masquer sa véritable IP.

Et dans les faits on voit que IPSQ donne comme proxys, ou plus exactement donne des notes de risques élevées, à des IP qui ne sont pas du tout des proxys ouverts. Par exemple des IP d'entreprises ou des IP ouvertes de bâtiments publique. J'ai eu des exemples parlants avec des IP d'Orange et aussi avec des IP d'un fournisseur québécois respectable.

@Thibaut120094, j'espère que nous avons répondu à tes interrogations ? Le chat perché (discuter) 4 avril 2024 à 23:56 (CEST)

Merci pour vos réponses détaillées, je vois en effet qu’IPQS utilise de l’apprentissage automatique, ce qui peut donner des faux positifs.

Cela dit, IPQS reste une source réactive pour détecter les proxies résidentiels (aussi appelés P2P ou Spider).

« Wikipédia n'est pas un serveur de messagerie (cf. Le chat perché) »

Non, mais une adresse IP résidentielle qui envoie du spam, il y a de grandes chances que ce soit un proxy P2P.

« […] c'est l'exemple donnée ci-dessus avec Cloudflare »

Comme je l’ai expliqué plus haut, 1.1.1.1 est un mauvais exemple, je viens de tester avec une adresse IP de Cloudflare WARP et elle est bien indiquée comme étant un VPN avec un score de 99 (en plus elle n’était pas bloquée).

— Thibaut (discuter) 7 avril 2024 à 16:48 (CEST)

@Thibaut120094 Tout n'est pas à jeter chez IPQS, mais ça reste l'outil le moins utile que nous ayons ou dans lequel nous avons le moins une confiance aveugle.

Les proxies résidentiels sont relativement faciles à identifier par l'outil CU lui-même : quand un utilisateur se téléporte d'une ville à une autre ou change de FAI, c'est un peu évident. Néanmoins, Spur est un peu plus précis sur cela car il compte combien de fois une IP a été trouvée à des localisations différentes.

« 1.1.1.1 est un DNS et non un VPN/proxy ouvert, donc le score de zéro me paraît normal. »

Oui et non : si tu utilises un DNS pour te connecter à Wikipédia, alors c'est un proxy qui t'anonymise. Selon notre point de vue, ils devraient alors être considérés comme non fiables. C'est l'utilisation anonymisatrice qui pose problème car généralement c'est pour échapper à un blocage (e.g. blocage automatique). Ce pourquoi ces IP sont bloquées pour empêcher les contournements.

On pourrait probablement faire des statistiques détaillées sur chaque IP de Cloudflare voire les comparer avec d'autres outils, mais ce n'est pas franchement nécessaire ; ce qui importe c'est l'utilité relative et le fait de ne pas être guidé sur un mauvais chemin.

A décharge, IPQS n'est pas le seul outil concerné par un manque d'infos. Par exemple, 162.158.38.193 (u · d · b) n'est pas identifiée par Spur comme non fiable malgré le fait qu'elle fasse partie du Data center de Dublin (DC qui n'est pas un secret). De même, on utilise d'autres outils non listés (isprangefinder ou les bases de DNS, par exemple). LD (d) 7 avril 2024 à 19:22 (CEST)

 LD : il faudrait ajouter {{remplace|$1|%3A|:}} quand l'IP n'est pas passée en paramètre, pour éviter les problèmes avec les IPv6. --Mathis B ^discuter, le 10 avril 2024 à 11:17 (CEST)

merci @Mathis B, fait avec d'autres corrections mineures : diff. LD (d) 10 avril 2024 à 12:56 (CEST)

Bonjour, je me permets de réintervenir pour demander de ne pas trop attendre pour supprimer IPQualityScore de MediaWiki:Sp-contributions-footer-anon (discussion) et {{u+}}. Exemples de derniers faux-positifs : demandes de blocage de 77.205.22.234 et 77.205.22.142 (web mobile SFR) ; blocage de 41.221.181.123 (demande), ISP Orange Mali (cf. Proxy API Checker, IPinfo)  Go-goldorak, Laurent Jerry, Do not follow et Harrieta171.

Concernant la suppression ou le maintien d'IPQualityScore dans Utilisateur:LD/PV.js, je n'ai en fait aucune idée de son influence sur les blocages en tant que proxy. Cordialement. --Ciseleur (d) 13 avril 2024 à 15:45 (CEST)

Bonjour,

perso, je ne comprends rien aux noms spécifiques relatifs aux IPs, Proxy, etc... Mais pour info, les IPs que j'ai signalées (77.205.22.xxx), ce ne sont pas les premières dans ce cas : la semaine dernière, j'ai dû en signaler 8 ou 9... Les pages vandalisées sont souvent les mêmes (manga, animation, K-Pop, pays/villes asiatiques), et les modifs relativement identiques à chaque fois (ajout de portails inutiles, changement de pays, d'auteurs...).

Je ne sais pas ce que ça apporte de faire tout le temps ça, et ne comprends pas le plaisir pris à vandaliser les pages, et j'avoue que c'était hyper relou de révoquer sans cesse les vandalismes (6 IPs le même jour), en attendant qu'un modo soit disponible pour les bloquer. Si seulement un système pouvait bloquer ces IPs automatiquement... Go-goldorak (discuter) 13 avril 2024 à 16:46 (CEST)

Bonjour Go-goldorak, loin de moi l'idée de remettre en cause vos signalements, mais seulement le motif « Proxy ouvert » dans deux des exemples cités ci-dessus — très probablement basé sur IPQualityScore (à ma connaissance, c'est cet outil qui mène trop souvent à ce genre d'information erronée) —, alors que les contributions ont comme balises « Modification par mobile, Modification par le web mobile ». Dans ce cas, je suggère d'utiliser plutôt les motifs « Vandalisme » ou « Modifications non constructives », voire « Vandalisme d'IP partagée » (un autre cas de faux-positifs avec IPQualityScore, cf. ref-3). Cordialement. --Ciseleur (d) 13 avril 2024 à 17:11 (CEST). Retouche le 13 avril 2024 à 17:14 (CEST)

Voyage aux origines des CUs

Bonjour. J'ai retrouvé une vidéo de votre ancêtre Bon visionnage. Bien à vous, — Arcyon ^{[Causons z'en]} 19 avril 2024 à 19:40 (CEST)

Nom d'un petit 🦆 ! Hyméros ^{--}-≽ ♥} 21 avril 2024 à 19:27 (CEST)

Mise à jour de WP:CU

Chère communauté, chers membres du Comité du nomination (@Goombiis, @Laurent Jerry, @Myloufa, @Girart de Roussillon et @Cbyd) et chers vérificateurs (@Durifon, @Hyméros, @Le chat perché, @Lewisiscrazy, @Linedwell et @Mathis B).

Tout d'abord, pour remettre dans le contexte, le 28 avril 2024, nous [CU] avons reçu un email de la Commission de médiation – un organe qui agit au nom du conseil d'administration la Wikimédia Foundation – qui a précisé et/ou nous a fait part de (nouvelles) procédures.

Cette « résolution » fait suite à celle de 2013 (discussion locale) et celle de 2019 (courriel sur méta).

Afin de mieux comprendre ces procédures, nous avons envoyé un courriel de réponse, le 28 avril 2024, et obtenu une réponse, le 12 mai 2024. Pendant tout ce processus, nous avons avons échangé en privé sur divers points et sans savoir quelles informations nous pouvions ou pourrions communiquer.

En conséquence de ces échanges, nous proposons une mise à jour de la page WP:CU afin qu'elle permette à l'ensemble de la communauté de comprendre les obligations et droits des vérificateurs, tout en veillant à lever les ambiguïtés et éviter toute méprise (d'où la révision entière).

Cette version proposée n'est pas définitive et non substituable aux Politiques qui régissent ce statut.

• Non définitive car il est possible que des passages soient à reformuler ou préciser — pour plus de compréhension, pour mieux refléter les Politiques.
• Non substituable car la communauté peut choisir de soumettre de nouvelles règles aux vérificateurs, mais les vérificateurs ne pourront pas les appliquer si elles viennent contredire l'une des Politiques – qui sont applicables à tous les projets et ce sans aucune exception.

Par transparence et en adéquation avec crédits d'auteur, je précise :

• La révision proposée « d'origine », que j'introduis, ne peut être consultée que par les « pairs » (dont la version originale est consultable à ce lien permanent).
• Je ne suis pas le seul auteur de la révision proposée, que j'introduis. Il y a eu 65 versions intermédiaires entre la première version et la dernière ; la paternité est partagée entre, directement (edit) Lewisiscrazy et LD (moi-même) et indirectement Le chat perché et Mathis B qui ont suggéré des modifications dans la discussion attenante (il serait déconseillé de fournir un lien ancré vers ce wiki, donc je m'en dispose). À ces auteurs peuvent s'ajouter les membres de la Commission de médiation ou les rédacteurs des Politiques car certaines formulations sont proches de celles insérées (le plus souvent, il y a des citations). Nous pouvons vous renvoyer vers les historiques des Politiques pour la liste des auteurs complets. Ainsi, aux auteurs de la version actuelle, s'ajoutent 4 auteurs directement nommables et attribuables pour une soixante de révisions entre le 13 mai 2024 à 15:47 et le 15 mai 2024 à 09:40 UTC.
• Nous n'avons eu qu'un temps très court pour revoir la version actuelle, ce pourquoi, en partie, elle n'est pas définitive.

Résumé par rapport à la version actuelle :

• Nous proposons un renommage du statut, par exemple : « Vérificateur d'adresses IP » vers « Vérificateur(s) d'utilisateurs » ou simplement « vérificateur(s) » pour éviter les confusions avec les changements en matière de confidentialité des adresses / plages d'IP ;
• Les sections « Conditions d'utilisation » et « Dévoilement des informations » sont renommées en « Politiques – Conditions d'utilisation » et « Confidentialité » et sont revues ;
• Les sections « Demander une vérification » et « Journal des vérifications » sont mutualisées dans « Vérifications » et sont revues ;
• Les sections « Liste des vérificateurs d'adresses IP », « Accès au statut » et « Retrait du statut » ne changent pas (ou peu) ;
• La section « Recours » a été modifiée afin d'être compatible avec les Politiques en matière de confidentialité ;
• La section « Présentation » est entièrement revue : de multiples passages ont été transférés ou supprimés (car peu utiles et/ou redondants) ;
• La section « Pour en savoir plus » est alégée (liens déplacés ou non pertinents) ;

Résumé des ajouts et/ou changements :

• Section « Confidentialité » définit les droits et obligations ;
  • Elle précise brièvement comment une information devient publique et quelles sont celles qu'un vérificateur peut transmettre (nuance proposée entre divulguer/partager/communiquer) et dans quelles circonstances.
• Une section « Conséquences » fournit des « Cas concrets » et reformule le cas du « Blocage » (changements mineurs)
• Pour faciliter la lecture, des définitions (#Définitions) sont proposées ;

Considérations ou changements importants :

• La transmission d'informations confidentielles est restreinte aux personnes dites « accréditées », à savoir les vérificateurs, stewards et les membres de la Commission de médiation – et personne d'autre et ce quels qu'en soient les moyens.
  • Cela concerne notamment : les adresses IP, plages CIDR et proxies ouverts (se référer à « Informations confidentielles » et « Données collectées » dans « #Définitions »).
  • À ce titre, les Requêtes ne traiteront désormais plus que des liens entre les comptes (se référer à #Requêtes).
  • À ce titre, afin d'éviter toute méprise, la section « Blocages » explicite davantage ce que veut dire « Cette divulgation accidentelle et consécutive à lutte contre les abus doit rester « implicite ». » et transfère l'information qui était autrement placée dans « Conditions d'utilisation » (« ou au public, lorsque cela représente une conséquence nécessaire du blocage d’un faux-nez ou d'un autre compte utilisé pour des abus. »).

Ainsi, après ce long message, j'invite la communauté à lire attentivement la nouvelle version, à commenter les passages ou sections qui seraient insuffisamment clairs et à poser des questions.

Enfin, comme sus-rappelé, la communauté est libre d'ajouter de nouvelles règles (sauf si cela contrevient à la Politique de confidentialité). Ainsi, soyez libre de soumettre des idées.

Bien à vous, LD (d) 15 mai 2024 à 12:33 (CEST)

Bonjour,

Pour dissiper certaines inquiétudes potentielles il me semble bon de rappeler que les RCU sont des vérifications techniques destinées à aider à la protection de l'encyclopédies. Elles ne se substituent pas au test du canard ni à l'appréciation des admin. Un admin peut bloquer une IP sans RCU si le canard est éloquent ou l'abus caractérisé, un admin peut ne pas bloquer malgré une RCU positive s'il estime par ailleurs ne pas avoir raison de le faire ou ne pas souhaiter le faire, à contrario il peut s'il l'estime légitime bloquer malgré une RCU négative. Par exemple en considérant la possibilité de recourt à un pantin. Ce paragraphe ayant pour but d'illustrer que les règles précisées/ ajoutées ce jour n'ajoutent pas en elle même de problèmes à la communauté, et qu'au contraire elles visent à sécuriser strictement le droit à la vie privée et la confidentailité des données privées.

Rappelons ausi que tous les vérificateurs ont signé un accord de confidentialité qui implique leur responsabilité légale en cas de non respect. Le chat perché (discuter) 15 mai 2024 à 13:16 (CEST)

Bonjour,

Merci pour le travail ! Peut-être retoucher la formulation de la note a : Le statut a aussi été désigné en tant que « vérificateur d'adresses IP » ? — 🦊 jilucorg ^(d.), le 15 mai 2024 à 17:22 (CEST)

Bonjour @Jilucorg, . Le chat perché (discuter) 15 mai 2024 à 17:30 (CEST)

Au sujet du renommage, @Linedwell pourra probablement le faire sans problème ; il y a tellement de sous-pages que j'obtiens "Our servers are currently under maintenance or experiencing a technical problem." .

Sinon je mettrai mon bot sur le coup et/ou je le ferais avec l'API, un à un. LD (d) 15 mai 2024 à 18:09 (CEST)

@LD, tu penses à son bot LinedBot ? Le chat perché (discuter) 15 mai 2024 à 18:12 (CEST)

@Le chat perché, je fais référence au fait qu'un Steward a le droit bigdelete - que les admins n'ont pas. Il est possible que ce renommage massif me soit refusé car je n'ai pas ce droit.

J'ai toujours la possibilité de le faire 1 à 1 (avec ou sans script / bot), mais s'il peut le faire autant qu'il m'en épargne la peine LD (d) 15 mai 2024 à 18:18 (CEST)

@LD Ca aurait été avec joie si j'étais encore steward, mais je me suis retiré. Linedwell ^[discuter] 15 mai 2024 à 18:31 (CEST)

@LD, je pensais bien que tu faisais référence à ça mais Linedwell, il vient de le confirmer au dessus d'ailleurs, a démissioné de son mandat de steward l'an dernier, raison de ma question car je pensais que tu le savais. Il n'y a plus de steward francophone. Le chat perché (discuter) 15 mai 2024 à 18:36 (CEST)

Ajoutons qu'il est de toutes façons déconseillé à un steward d'intervenir sur son projet d'origine, même si c'est un principe qui n'est pas toujours appliqué. --Mathis B ^discuter, le 15 mai 2024 à 18:43 (CEST)

Autant pour moi, je pensais que tu l'étais toujours. Désolé, @Linedwell.

Je regarde un peu plus tard alors. LD (d) 15 mai 2024 à 18:45 (CEST)

Question

Bonjour. J'ai du mal à comprendre la phrase « requêtes visant à établir des liens non connus publiquement, explicitement et antérieurement à la requête, notamment entre [...] » ? Une requête ne sert que sur des liens non connus avant la requête sinon il n'y aurait pas besoin de requête ? (Mais je suis peut-être à côté de la plaque sur la compréhension) 'toff ^[discut.] 15 mai 2024 à 20:17 (CEST)

Bonjour @Supertoff,

Il est toujours préférable de préciser ce qui est implicite . Ce qui est évident pour toi qui contribue et dépose des RCU depuis longtemps peut ne pas l'être pour tout le monde. On a souhaité faire le plus accessible possible pour tout contributeur.

Cela dit il y a aussi une subtilité qui en effet t'échappe peut être, il y a un cas de figure au moins ou une RCU peut être recevable s'agissant d'un lien déjà connu : un contributeur enregistré affirmant (hors d'une RCU) être aussi derière une IP peut ouvrir une RCU si cette affirmation est contestée et qu'il y a un problème suffisant au milieux pour demander à ce que son affirmation soit confirmée ou infirmée techniquement. Bien entendu la recevabilité d'une telle requête est l'appréciation des vérificateurs. Et il y a également un second cas similaire : imagine que quelqu'un t'accuse de façon un peu étayée d'être derrière une IP problématique, tu es en droit d'ouvrir une requête pour clamer ton innocence. Auquel cas le vérificateur se contentera de confirmer que tu n'es pas l'IP. On a donc deux situation ou un lien potentiel est "connu" avant. Bon c'est du détail. Le chat perché (discuter) 15 mai 2024 à 20:52 (CEST)

Ok : et dans ma compréhension globale, il manquait le début : "automatiquement refusées". Ce qui sous-entend que les 2 cas que tu cites ne le seront pas automatiquement (et donc pourront être acceptées) 'toff ^[discut.] 15 mai 2024 à 21:30 (CEST) j'ai peut-être un peu coupé en travers

Salut @Supertoff. J'ai ajouté deux notes mais on pourrait trouver une formulation qui soit moins jargoneuse, peut-être. Dis-moi ce que tu en penses. LD (d) 15 mai 2024 à 22:10 (CEST)

@Supertoff Je crois avoir trouvé une formulation satisfaisante (cf. WP:DVIP). LD (d) 15 mai 2024 à 22:39 (CEST)

 LD : salut. C'est plus explicite. Si je chipote, je dirais que, plutôt que :

« requêtes qui peuvent conduire à divulguer une information confidentielle, qui par sa nature, a vocation à le rester »

je préférerais

« requêtes qui peuvent conduire à divulguer une information, qui par sa nature, a vocation à rester confidentielle »

c'est un poil moins lourd (et la première formulation, si tu lis un peu trop rapide comme je le fais parfois, pourrais amener à penser que « l'information [...] a vocation à [...] restée divulguée » : en gros que « rester » s'applique à « divulguer »)

'toff ^[discut.] 16 mai 2024 à 06:07 (CEST)

En-tête

Bonjour LD tu as écrit Diff #215131874 que

« Toute requête ne respectant pas ces règles sera rejetée. En particulier :
* ...
* Si celle-ci ne vise pas uniquement des comptes utilisateur : si elle vise ou comprend une adresse IP, elle sera rejetée ; »

Mais je ne crois pas. Si une requête concerne des comptes et une ou plusieurs IPs, la partie "comptes" peut-être traitée. Je propose, plus simplement:

« Toute requête ne respectant pas ces règles sera rejetée. En particulier :
* ...
* Si celle-ci ne vise que des adresses IP, ou un seul compte et une ou plusieurs adresses IP ; »

Ou bien :

« * Si elle ne vise pas au moins deux comptes enregistrés, les IPs éventuellement mentionnées ne pouvant pas être vérifiées. »

Mais la double négation "rejetée si ne vise pas..." ne facilite pas la compréhension. Et il faudrait un pluriel dans le premier item:

« * Si les utilisateurs n'ont pas contribué sur Wikipédia en français dans les 90 derniers jours »

("contribué sur", plus simple que "interagi avec", même si c'est moins rigoureux). Ou bien « Si au moins N-1 des N comptés visés n'ont pas contribué depuis plus de 90 jours. » .

--Lewisiscrazy (discuter) 16 mai 2024 à 11:04 (CEST)

@Lewisiscrazy, sur ton dernier point je ne suis pas favorable car nous voyons autre chose que des contributions dans nos logs. Je reste volontairement vague. Le chat perché (discuter) 16 mai 2024 à 12:07 (CEST)

C'est pour ça que je disais "moins rigoureux". Mais c'est plus facile à comprendre pour les gens qui font les requêtes. Je pense pas que la formulation "interagir" parle a grand monde et je pense pas qu'il soit nécessaire de clarifier davantage, c'est du détail. --Lewisiscrazy (discuter) 16 mai 2024 à 12:11 (CEST)

Salut @Lewisiscrazy & @Le chat perché

Pour le premier point, je pense qu'il est préférable de partager l'idée que :

• Les requêtes doivent se limiter à un compte ou plusieurs, car de toute façon, les CU peuvent voir les abus de tous les utilisateurs et que partager une IP, c'est faire prendre le risque au CU d'établir un lien publiquement/explicitement entre une IP et un compte (divulguer une info confidentielle), soit au travers de la vérification elle-même, soit au travers du blocage succèdera (WP:DVIP et WP:CUBLOCK).
• Si un requérant dit simplement "le compte B intervient sur la page X avec le soutien d'autres utilisateurs, voir l'historique" et que les "autres" font référence à une ou plusieurs IPs ; on pourra tout de même la traiter car c'est suffisamment implicite pour tout le monde. C'est problématique s'il mentionne une IP car c'est manière publique, que le lien avec la RCU est explicite en cas de blocage.

Pour le second point, introduit en 2023, je préférerai une note ou s'appuyer sur Spécial:Contributions et Spécial:Journal pour l'expliciter.

Par exemple, « si les utilisateurs concernés n'ont pas contribué et/ou journalisé (i.e. renommer une page) sur Wikipédia en français dans les 90 derniers jours ». LD (d) 16 mai 2024 à 12:28 (CEST)

@LD,

Je te cite : « Si un requérant dit simplement "le compte B intervient sur la page X avec le soutien d'autres utilisateurs, voir l'historique" et que les "autres" font référence à une ou plusieurs IPs ; on pourra tout de même la traiter car c'est suffisamment implicite pour tout le monde » : Contre et pas du tout d'accord avec cette phrase. D'une part nous n'avons pas à partir à la pèche, un requérant doit clairement inscrire dans sa requête les comptes qu'il soupçonne. Par ailleurs je ne suis pas convaincu que ce soit implicite justement. Au contraire ce sera tellement explicite que le requerrant ira ensuite demander aux admin le blocage des IP. Et cela permettra à tout contributeur de contourner justement le fait qu'une requête avec "compte + IP" ne soit pas recevable. Le chat perché (discuter) 16 mai 2024 à 13:24 (CEST)

@Le chat perché :

• En quoi la phrase serait-elle incompatible avec m:CheckUser Policy (« There must be a valid reason to use the CheckUser tools to investigate a user. »), WP:DVIP (le requérant apporte des éléments raisonnables et tangibles de l'abus ; la vérification permettra de prévenir cet abus ; le vérificateur se contente de « vérifier » car il ne part pas à la pêche aux informations.) ? Ne penses-tu pas que dire « le compte B intervient sur la page X avec le soutien d'autres utilisateurs, voir l'historique » apporte une preuve abus ? Qu'elle soit suffisante ou non, c'est une autre question, c'est à la discrétion du CU.
• S'il faut définir « partir à la pêche » dans WP:DVIP, je n'ai rien contre : la définition anglophone n'est pas mauvaise.
• J'entends ce que tu veux dire par "contourner justement le fait qu'une requête avec "compte + IP" ne soit pas recevable" ; et globalement, je suis d'accord, ce pourquoi j'avais d'abord formulé « Si celle-ci ne vise pas uniquement des comptes utilisateur : si elle vise ou comprend une adresse IP, elle sera rejetée » puis explicité que « Les requêtes doivent se limiter à un compte ou plusieurs » car, en revanche, je ne suis pas tout à fait d'accord avec le pluriel.

LD (d) 16 mai 2024 à 16:48 (CEST)

Pour préciser :

• Le fait qu'une RCU contienne une adresse IP n'est pas problématique en soi. Le problème réside dans le fait que si l'IP a été mentionnée, elle ne pourra plus être bloquée car cela contreviendrait à WP:CUEXC & WP:CUBLOCK : il sera facile de faire le lien entre le blocage et la RCU.

Ainsi, je pense qu'on devrait se limiter à dire qu'on n'accepte pas les requêtes qui comprennent des IP / plages, pour dissuader que cela arrive et pour éviter que cela conduise à une divulgation explicite - publique.

Je suis convaincu que les requérants sauront ou apprendront à faire des requêtes à l'encontre d'un à plusieurs comptes qui respectent WP:CUP et WP:DVIP, notamment en matière de charge de la preuve (éviter la pêche). LD (d) 16 mai 2024 à 17:10 (CEST)

@LD, personnellement je considère n'avoir pas à choisir les comptes ou accès que je vérifie (hors requête non publiques ou autosaisines qui sont des cas particuliers). C'est au requérant de me dire quels sont les comptes suspectés d'infraction et de justifier sa requête à leur endroit. Je ne vois aucune raison qui empêcherait le requérant de le faire. Sur une RCU que je traite je suis vérificateur et rien d'autre. Je considère qu'aller analyser un historique pour trouver un compte éventuellement ciblé mais non précisé par le requérant c'est partir à la pèche (sauf si je trouve par ailleurs ce compte via ma vérification naturellement).

S'agissant des cas ou une IP suspectée, ouvrir une requête avec juste un compte et dire "au fait les gars y a peut être bien abus d'IP pour faire nombre sur tel article", est un contournement explicite de ce que nous ne devons plus faire.

Si toujours dans cette réflexion on exclu les IP, je ne trouve pas acceptable une requête ou on affiche un compte (mettons le mien) et on dit aux CU "tien y a peut être bien un faux nez de Le chat perché^{[réf. nécessaire]} sur l'article XYZ mais je ne vous dit pas lequel". Cela ressemble à jeter en pature Le chat perché d'une part, et surtout en tant que CU je n'ai ni à me transformer en requérant bis en regardant l'histo de l'article pour voir quel serait le faux nez en question, ni à vérifier juste le compte de Le chat perché pour voir si dés fois il a un faux nez. Ce serait exactement partir à la pèche.

La seule exception concerne pour moi les créateurs connus de faux nez, en pratique les pénibles récurents. Pour lesquels effectivement nous donner un seul compte et nous demander si ce ne serait pas un faux nez de XYZ et d'aller chercher les éventuels comptes dormants est normal.

Cela devrait être évident que si je suspecte LD d'avoir un faux nez c'est que j'ai moi requérant identifié au moins un autre compte qui pourrait lui appartenir et donc je dois le noter dans ma requête.

Cela te parait peut être tatillon mais il me semble nécessaire de demander un peu de rigueur, pas tant que ça finalement, dans la rédaction des RCU (comptes suspectés (au moins 2) + motif de suspicion). Le chat perché (discuter) 16 mai 2024 à 17:22 (CEST)

Il y a manifestement méprise puisque je dis que le requérant se réfèrer à l'historique pour justifier de vérifier le compte B, pas que le CU doit déterminer le nombre d'utilisateurs à vérifier.

Par ailleurs, l'abus de faux-nez n'est qu'un motif parmi tant d'autres. Vérifier un seul compte peut s'y justifier, tout comme s'il s'agit d'un cas de vandalisme, de spam ou de désorganisation. Ceci dit, un abus de faux nez est généralement est caractérisé par la tentative de faire du poids, en faisant croire que plusieurs soutiennent l'argument Y, mais comme tu le dis, il y a des exceptions (contournement, bannissement). Il n'y a donc aucune raison légitime d'en faire une règle au pluriel (2 comptes suspectés + motif de suspicion), dès lors que l'abus FN n'est pas le seul motif accepté, et surtout lorsque la politique globale utilise le singulier (check if a user (...) to investigate a user (...) to the account). LD (d) 16 mai 2024 à 18:18 (CEST)

@LD, cela ne sert pas à grand chose : soit ce sont des comptes enregistrés et donc il n'y a pas de raison de ne pas mes citer tous, soit il y a en plus une IP et se référer pour ne pas citer revient à demander de vérifier le lien ce que nous ne devons pas faire.

Une RCU pour vandalisme ou spam ç'est la même chose que l'usage de faux nez pour faire poids, ce qui nous est demandé c'est de verifier si le vandale ou spammeur a utilisé plus d'un compte. Et donc proposer un seul compte spammeur en nous demandant s'il y en a un autre revient aussi à partir à la pèche.

Bon c'est du détail, n'y passons pas plus de temps. Le chat perché (discuter) 16 mai 2024 à 18:34 (CEST)

@Le chat perché, ce n'est pas du détail justement car si le compte enregistré n'a pas d'autres comptes (ça personne ne le sait sauf le CU d'ailleurs) mais qu'il peut revenir dégrader l'encyclopédie (avec un nouveau compte, avec une IP) alors le CU peut faire en sorte que cela n'arrive pas en le bloquant. Le CU étant donc là pour "limiter" une nuisance, "prévenir d'une dégradation" (citations tirées de CUP). Si le requérant ne cite pas l'IP, il n'oblige pas le CU à prendre le risque de révéler que c'est bien la même personne (donc de divulguer), elle pourra être bloquée plus facilement. LD (d) 16 mai 2024 à 18:58 (CEST)

@LD, si j'exerce ma mémoire je ne me souviens pas de tels RCU. Et encore moins acceptée (et j'ai lu des années de RCU). Je puis me tromper Le chat perché (discuter) 16 mai 2024 à 19:13 (CEST)

Point 2: alors « si les utilisateurs n'ont ni contribué ni "journalisé" (par exemple renommé une page) sur wp:fr dans les 90 derniers jours ». --Lewisiscrazy (discuter) 16 mai 2024 à 14:05 (CEST)

Après c'est sur que notre limite est d'en dire à la foi assez mais pas trop, et sur cette phrase c'est de la contorsion. Il y a des choses que nous CU pouvons voir et qu'un péon ne peut pas voir , et même certaines qu'un admin ne peut pas voir (non jounalisées) dans le délai de 90 jours. On ne va évidemment pas tout détailler. Le chat perché (discuter) 16 mai 2024 à 14:36 (CEST)

Dans ce cas : « si les utilisateurs n'ont pas participé à Wikipédia en français dans les 90 derniers jours ». C'est plus clair que "interagir" et plus souple, pas besoin de rentrer dans les détails car WP:DVIP peut le préciser. LD (d) 16 mai 2024 à 16:50 (CEST)

OK. --Lewisiscrazy (discuter) 16 mai 2024 à 17:09 (CEST)

Suis-je le seul à être choqué par « Ainsi, la communauté doit garder à l'esprit que le vérificateur est légalement responsable de ses actions, qu'il doit protéger la confidentialité et qu'il sera parfois contraint d'invoquer de « fausses justifications » ou un motif générique de blocage tel que « vandalisme ». » ? Alors qu'on a toujours érigé la transparence en valeur fondamentale, on encourage sur une page d'aide un contributeur à cacher la vérité ? Je suis profondément préoccupé par les nouvelles procédures mises en place, que ce soit cette réforme impromptue du fonctionnement des RCU ou les comptes temporaires, j'ai peur qu'elles ne fassent que repousser les contributeurs volontaires et éloigner l'encyclopédisme en rendant la patrouille et la lutte contre les modifications problématiques plus dififcile. Bref, priver d'armes les patrouilleurs alors que les menaces s'intensifient (ingérences étrangères, POV-pushing...). DarkVador ^{[Hello there !]} 17 mai 2024 à 00:05 (CEST)

Bonjour  DarkVador79-UA : cette phrase a toujours été vraie, même si elle n'était pas explicitée aussi clairement. Les adresses IP sont des données à caractère personnel et ont toujours été traitées comme tel. --Mathis B ^discuter, le 17 mai 2024 à 00:12 (CEST)

Bien évidemment, mais à force de priver de tous les outils les patrouilleurs, on va finir par se retrouver avec des pénibles contournant continuellement leurs blocages sous IP... DarkVador ^{[Hello there !]} 17 mai 2024 à 00:15 (CEST)

Ça, ce n'est pas de notre ressort… --Mathis B ^discuter, le 17 mai 2024 à 00:22 (CEST)