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)

Bah, un peu quand même en tant que contributeurs et membres de la communauté qui fait vivre Wikipédia en français. Disons que je suis assez méfiant des directives venant d'en haut par courriel confidentiel du jour au lendemain et poussent à changer, sans consultation préalable de la communauté, nos procédures en place depuis longtemps. Une politique du fait accompli qui me gêne, voilà, c'est dit. Un peu plus de transparence et un temps alloué à des débats larges, avec un peu plus de clés en main pour comprendre les enjeux, serait la moindre des choses. DarkVador ^{[Hello there !]} 17 mai 2024 à 00:34 (CEST)

@DarkVador79-UA, dans la version précédente à la mise à jour, la phrase était formulée ainsi :

• « Toutefois, pour suivre les ajustements de politique de la fondation Wikimedia, il peut arriver qu'afin de ne pas dévoiler des informations personnelles, un CU, après avoir lui-même traité une RCU liée (ou sur sollicitation d'un autre CU non administrateur), bloque un compte à titre de « sanction » d'un comportement abusif, sans préciser de lien avec une RCU, ce qui permet de protéger la vie privée de la personne ayant un compte enregistré. »

J'imagine que cela faisait déjà suite à la résolution de 2013 puisqu'elle a été introduite en 2014. Néanmoins, cette nouvelle phrase me semble plus explicite, même si cela fait au moins 10 ans que c'est le cas. LD (d) 17 mai 2024 à 00:38 (CEST)

L'outil CU n'a jamais vraiment relevé de la communauté, il est soumis depuis toujours aux politiques globales de la fondation. --Mathis B ^discuter, le 17 mai 2024 à 00:40 (CEST)

Bonjour @DarkVador79-UA,

• La politique CU n'a jamais relevé de la communauté et pour cause. Elle relève de la CU Policy et donc de la WMF. Cela a toujours été ainsi. La WMF n'a pas à solliciter une communauté locale pour définir ses politiques de sécurité en matière de gestion des données privées.
• J'ai expliqué plus haut que penser que cette mise à jour va gêner la lute contre les pénibles est faux. Une IP peut être bloquée au test du canard. Les admin n'ont pas besoin d'un RCU pour bloquer une IP si le canard est concluant.
• En.wikipedia applique ce que nous avons mis à jour depuis très longtemps et je ne sache pas qu'ils ont des problème de lutte contre les pénibles.

Le chat perché (discuter) 17 mai 2024 à 10:05 (CEST)

@DarkVador79-UA,

Sur la transparence je souhaiterais t'apporter quelques éléments. Evidemment que la transparence est fondamentale mais elle ne peut s'exercer dans certains cas légitimes. Certains statuts wikipediens exigent pour des raisons évidentes que certaines choses ne soient pas publiques. A savoir les CU, les OS, les agents VTRS et dans une moindre mesure les abuse-filter (qui eux ne signent pas d'accord avec la WMF).

Pour ce qui est des CU par essence nous sommes tenus à la plus stricte confidentialité. Pour des raisons évidentes certaines de nos actions et décisions doivent rester privées, et peuvent le cas échéant nous conduire à invoquer de fausses justifications ou de faux motifs. Ce n'est par gaité de coeur mais de part la CU Policy et pour ne pas s'exposer pénalement on y est parfois obligé. De la même manière qu'il peut parfois y avoir des RCU non publiques, là encore selon des conditions strictement encadrées par la CU Policy (mais tracées sur le Wiki privé). Et puisqu'on en parle justement le Wiki privé n'est par essence par transparent. Il n'est accessible qu'aux CU des difrérentes versions locales et aux stewards. Nous nous en servons pour échanger sur des éléments non publiques, par exemple sur des requêtes et pour stocker des informations techniques là aussi non publiques sur des pénibles.

Tout ça pour dire qu'il ne faut pas avoir l'impression que des choses sont faites dans le dos de la communauté. Les outils de CU sont strictement utilisés dans le but de protéger l'encyclopédie et supposent un respect ferme de la confidentialité et de la protection des données privées.

Accessoirement les CU ne sont pas autorisés à communiquer des informations privées à des non CU, même aux OS et aux agents VTRS dont l'accord de confidentialité ne couvre pas les données accessibles aux CU. Et donc encore moins à des admin non CU.

J'espère t'avoir rassuré. Le chat perché (discuter) 17 mai 2024 à 19:19 (CEST)

Je n'avais aucune crainte que des informations confidentielles soient diffusées par des CU. Je suis juste inquiet de voir que ce projet fondé sur l'ouverture soit contraint de prendre des décisions qui ne nous correspondraient pas et même nous handicaperaient (dans la protection de la neutralité notamment), parce que le cadre juridique, encore mal défini je trouve, l'impose. DarkVador ^{[Hello there !]} 17 mai 2024 à 22:21 (CEST)

Rassurez-moi :

1. dites moi que cette version ne s'appliquera qu'à compter de la mise en place des comptes temporaires masquant les IP  ;
2. et qu'il restera possible de faire des rapprochements entre des comptes temporaires, ou entre des comptes temporaires et des comptes enregistrés ?

Si la réponse à l'une de ces deux questions est "non", c'est un magnifique boulevard qu'on (la fondation) offre aux vandales, pov-pushers et comptes rémunérés. Ou alors il me manque un morceau que j'aimerais bien voir expliqué en termes clairs. Cdlt, --Pa2chant.bis (discuter) 17 mai 2024 à 04:23 (CEST)

Et concernant le recours à des proxies, pouvez-vous m'indiquer où il est possible de contester cette décision que cela serait une info privée ? Car la réponse "A n'a pas le même fournisseur/adresse IP/origine géographique que B" se lit tout différemment si l'on ajoute "mais B utilise des proxies". Or si vous n'avez plus le droit de nous le dire, cela ne peut que nous induire en erreur. Et rendre les RCU inutiles pour les professionnels, car EUX sauront bien s'engouffrer dans la brèche.--Pa2chant.bis (discuter) 17 mai 2024 à 04:33 (CEST)

La version s'applique immédiatement.

Nous n'avons pas d'informations concernant les comptes temporaires pour le moment, mais comme les admins auront accès aux IPs, je pense que ça ne permettra pas des rapprochements non plus.

Nous avons toujours le droit de dire qu'un utilisateur utilise des proxies, juste pas de donner les proxies en question (en tous cas, c'est ma compréhension). Par exemple, on peut dire "résultat indéterminé parce que B passe par des proxies ouverts", mais pas dire lesquels.

--Mathis B ^discuter, le 17 mai 2024 à 04:37 (CEST)

Merci. C'est n'importe quoi, ou au minimum une belle claque à tous ceux qui se sont mobilisés jusqu'à présent pour éviter les comptes rémunérés, les abus de faux-nez, etc.--Pa2chant.bis (discuter) 17 mai 2024 à 04:44 (CEST)

Bonjour Mathis B tu dis « Nous n'avons pas d'informations concernant les comptes temporaires pour le moment, mais comme les admins auront accès aux IPs, je pense que ça ne permettra pas des rapprochements non plus », je ne comprends pas cette phrase. Il me semble que, évidemment, les CUs pourront « faire des rapprochements entre des comptes temporaires, ou entre des comptes temporaires et des comptes enregistrés », puisqu'on aura accès aux infos sur les comptes temp via les outils CU, et qu'en écrivant "compte enregistré A = compte temp B", on ne divulgue aucune info personnelle. Et par ailleurs, certains patrouilleurs (lesquels: à définir) pourront voir les IPs des comptes temp. J'ai mal compris ce que tu voulais dire? --Lewisiscrazy (discuter) 17 mai 2024 à 08:54 (CEST)

Bonjour @Pa2chant.bis,

Je pense que ton inquiétude est dispropotionnée et que cette mise à jour n' pas du tout l'impact que tu penses en matière de lutte contre les vandales :

• Ce n'est pas parce que nous ne communiquerons plus les proxys ouverts que rien ne sera fait à leur sujet. Il y a parfois des suites non publiques aux RCU.
• Je le redis mais une IP peut être bloquée au test du canard, et ça arrive souvent, sans RCU. Cela n'entrave donc en rien la lutte contre les contributions rémunérées non déclarées (qui sont très rarement faites sous IP de toute façon).
• Si tu tombes sur une contributions par une IP et que cette IP est un proxy tu n'as pas besoin d'une RCU pour le faire bloquer. Si tu as un doute sur le fait que ce soit un proxy tu peux demander l'avis d'un CU qui n'aura pas besoin de ses outils pour se prononcer.
• En quoi savoir qu'une personne ayant un faux nez utilise un proxy est il si pertinent en patrouille ? Il y a beaucoup de raison légitimes en réalité de contribuer sous VPN ou proxy indépendemment du fait d'abuser de faux nez. Moi la par exemple je suis sous proxy, pas de mon choix c'est le point d'accès qui le rend obligatoire. Réciproquement je peux te dire que ce n'est pas du tout une généralité que les pénibles récurents utilisent des proxys.
• Dis toi que quelqu'un déterminé à ne pas se faire reconnaitre et ayant un peu de connaissance arrivera de toute façon à contourner, nos outils CU n'étant pas non plus des engins de guère. Mais ce n'est pas non plus si fondamental car le test du canard encore une foi est suffisant.

Le chat perché (discuter) 17 mai 2024 à 10:19 (CEST)

 Lewisiscrazy : L'IP derrière un compte temporaire sera visible des admins, donc ça posera le même problème de lier un compte temporaire et un vrai compte qu'une IP et un compte aujourd'hui. --Mathis B ^discuter, le 19 mai 2024 à 12:49 (CEST)

Mince alors --Lewisiscrazy (discuter) 19 mai 2024 à 12:55 (CEST)

Mais alors @Mathis B comment tu comprends la réponse à cette question : #Peut-on documenter publiquement les adresses IP utilisées par les vandales suspects (mais non confirmés) qui utilisent des comptes temporaires ?. La réponse dit qu'il sera possible pour les PcW qui auront accès à l'outil d'affichage des IPs d'écrire publiquement compte temp A = même IP que compte temp B (je ne parle même pas de divulguer les IPs ici, même si ce sera possible "exceptionnellement"). Voir aussi la Politique de divulgation. Si les CUs traitent les comptes temporaires comme des IPs (comme tu dis qu'ils devront le faire), alors ils seront plus contraints en termes de divulgation que les PcW qui ont accès à l'outil d'affichage des IPs? (NB ces derniers ne signeront pas d'accord de confidentialité). --Lewisiscrazy (discuter) 19 mai 2024 à 16:22 (CEST)

 Lewisiscrazy : entre deux comptes temporaires, oui, mais entre un compte temporaire et un compte classique, j'en doute fortement. Mais attendons la politique officielle, on pourrait être surpris, ça ne serait pas le premier revirement… --Mathis B ^discuter, le 20 mai 2024 à 17:49 (CEST)

@Lewisiscrazy et @Mathis B, c'est une raison qui fait que je ne comprend pas la cohérence entre d'une part nous restreindre (à juste titre) énormément sur les IP + la mise en place des comptes temporaires, et d'autre part le fait que le droit de voir les IP soit accessibles pour les comptes temporaires à d'autres que les CU. C'est assez antinomique. Soit la donnée IP est très sensible et donc seuls ceux qui ont signé l'accord de confidentialité spécifique aux CU devraient pouvoir les voir, soit c'est moins sensible que ça et alors il faut être cohérent. Sachant qu'un compte temporaire pourra révéler plus d'une adresse IP, donc possiblement pour quelqu'un qui n'utile pas de procys tu pourras le suivre à la trace, ce qui me semble encore plus dangereux. Encore plus en fait soit dit en passant sit la communauté choisit que le droit doit aussi être donné aux révocateurs. Cela me semble inconcevable qu'admin et révocateurs puissent révéler des IP alors que ce serait interdit aux CU. Le chat perché (discuter) 21 mai 2024 à 10:22 (CEST)

La WMF n'a aucune obligation légale de masquer les IP comme elle le fait actuellement pour les comptes enregistrés. C'est un choix qu'elle fait que d'offrir cet avantage (et un argument pour encourager à créer un compte). Pour les comptes non-enregistrés, elle a décidé d'un autre arbitrage, à savoir que les IP seront un peu plus cachées qu'actuellement, mais pas autant que les comptes enregistrés, et elle en a encore une fois le droit tant que les CGU le précisent bien. Et j'imagine qu'on aura un avertissement du même genre que l'actuel MediaWiki:Anoneditwarning en plus des CGU. --Mathis B ^discuter, le 21 mai 2024 à 13:25 (CEST)

En France la cours de cassation a statué que l'adresse IP est une donnée personnelle. Premier point comme toute donnée personnelle un site internet n'a pas le droit de la révéler publiquement si l'utilisateur n'a pas choisi de le faire (compte enregistré). Second point l'usage, l'exploitation par une entreprise, ici la WMF, ne peut se faire que sous réserve de validation de la CNIL qui peut auditer à tout moment. A mon avis si la WMF a lancé la réforme des comptes temporaires c'est parce qu'elle a été retoqué pour non respect de la RGPD, l'avertissement que tu signales et les CGU pouvant être considérés comme insufisants. Surtout dans la mesure ou l'avertissement n'est pas franchement clair sur les finalités, ce qui est pourtant également une obligation RGPD. Il ne suffit pas d'avoir des CGU disant que tu vas afficher les IP, il faut encore que l'utilisateur puisse faire un choix libre et éclairé, lequel passe par une validation des finalités. Ainsi je ne suis pas sur que ce soit très défendable au regard d'afficher par défaut publiquement les IP. D'ou la réforme.

Dans le cadre de mon métier nous avions une clause sur l'activation d'une offre en particulier qui disait au prospect : si tu souscris tu nous autorises à...C'était logique techniquement car l'offre ne fonctionnait pas sans. Cela a été retoqué pour non respect de la RGPD, nous obligeant à soumettre aux clients une validation explicite finalité par finalité. Le chat perché (discuter) 21 mai 2024 à 13:58 (CEST)

Oui, l'adresse IP est une DCP, mais rien n'oblige une personne à modifier Wikipédia. Le fait que l'IP soit sauvegardée si elle le fait sans créer de compte est clairement indiqué et la personne donne bien son consentement éclairé (et il y a bien une alternative : créer un compte). --Mathis B ^discuter, le 21 mai 2024 à 15:14 (CEST)

Ancien vérificateur absent de la liste

Bonjour, il manque Poudou! dans la liste des vérificateurs anciens et actuels. Voir Historique des statuts/Vérificateur d'utilisateurs pour la chronologie. Cordialement. --Ciseleur (d) 6 juillet 2024 à 15:22 (CEST)

Bonjour @Ciseleur,

Techniquement il n'est plus CU, c'est vrai mais il est encore signataire de ANPDP et peut re-devenir CU sur simple demande. Bizzarerie donc. LD (d) 6 juillet 2024 à 15:35 (CEST)

Catégorie « Wikipédia:Vérificateur d'adresses IP » à renommer

Bonjour, à la suite du renommage de Wikipédia:Vérificateur d'adresses IP vers Wikipédia:Vérificateur d'utilisateurs, la catégorie « Wikipédia:Vérificateur d'adresses IP » devrait être renommée en « Wikipédia:Vérificateur d'utilisateurs », mais j'ignore — et n'ai pas l'envie, ni le temps, de chercher — la meilleure manière de procéder.

À noter, l'existence de la sous-catégorie « Wikipédia:Ancien vérificateur d'adresses IP », à conserver pour raison historique ? Cordialement. --Ciseleur (d) 6 juillet 2024 à 17:30 (CEST)

@Ciseleur je vais m'y coller ! je pense tout renommer, l'historique du nom n'est pas très intéressant. Goombiis •~Δ~• 6 juillet 2024 à 17:57 (CEST)