Gemeenschappelijk gezondheidsinitiatief/Blokkeringshulpmiddelen en verbeteringen

This page documents a feature the former Wikimedia Foundation's Anti-Harassment Tools team committed to build.

To learn more about the current team and its projects, see Product Safety and Integrity.

Het team "Anti-Harassment Tools" van de Wikimedia Foundation nodigde Wikimedianen uit om in december 2017 nieuwe blokkeerhulpmiddelen en verbeteringen van bestaande blokkeringshulpmiddelen te bespreken voor ontwikkelingswerk in 2018. Ons team identificeerde tekortkomingen in de huidige blokkeringsfunctionaliteit van MediaWiki om te bepalen welke hulpmidellen we kunnen bouwen voor wiki-gemeenschappen om verstoring te minimaliseren, kwaadwillenden van hun wiki's te houden en situaties te bemiddelen waarin volledige siteblokkades niet geschikt zijn.

Updates

11 september 2019

Deels blokkeren zijn ingeschakeld op alle wikivoyage, wikisource en wiktionary wiki's. We denken dat de functie partiële blokkeren nu in een goed, stabiel stadium is, we zien minder en minder bugs de laatste paar maanden voorbij komen, de functie wordt ingezet op verschillende projecten. Het team heeft veel tijd besteed aan het verbeteren van de backend-infrastructuur en ervoor gezorgd dat de code betrouwbaar is, in afwachting van toekomstige functies die moeten worden toegevoegd.

Er blijven verzoeken van meer wiki's komen voor gedeeltelijke blokkades. We hebben ook een presentatie gegeven over gedeeltelijk blokkeren op Wikimania en dat werd zeer goed ontvangen, waarbij verschillende deelnemers vroegen om gedeeltelijke blokkeren in hun thuiswiki's te laten inschakelen. Gezien de algemeen positieve ontvangst van gedeeltelijke blokkades op wiki's waar het wordt ingezet, zijn we van plan om de komende weken een bredere uitrol naar meer Wikimedia-projecten te doen.

We blijven feedback verzamelen over gedeeltelijke blokkeren terwijl we de functie lanceren op meer wiki's, samen met dataverzameling over het gebruik van de functie. We zijn er ook voor om onderhoudswerk aan de functies uit te voeren, wanneer dat nodig is.

1 maart 2019

Vandaag deel ik officieel de aanbevelingen van het team Anti-Harassment Tools voor hulpmiddelen om langdurig misbruik dat op onze wiki's plaatsvindt te bestrijden. Dit 9 pagina's tellende document definieert globaal de soorten langdurige misbruik die plaatsvinden, schetst de bestaande hulpmiddelen en tactieken die worden gebruikt om dit gedrag te beperken en te tolereren, onderzoekt mogelijke nieuwe software om dit misbruik tegen te gaan (namelijk device blokkeren) en doet aanbevelingen voor de volgende stappen.

Kort gezegd zijn onze aanbevelingen om device blokkeren te vermijden, omdat dit een dure onderneming zou zijn met zeer kleine kans op succesvolle impact. In plaats daarvan raadt ons team alternatieve tactieken aan, waaronder een user reporting system, verbeteringen aan CheckUser, extra dempingfuncties (mute) en meer.

Een bijproduct van dit onderzoek is dat ons team zal werken aan het uitbreiden van cookie-blokfunctionaliteit naar de visuele en mobiele editors. — phab:T196575

15 februari 2019

De eerste ontwikkeling van functies voor gedeeltelijk blokkeren is voltooid! Beheerders kunnen nu blokkades instellen die alleen bewerken op bepaalde pagina(s) en/of namespace(s) verbieden. De uitrol zal langzaam en gefaseerd zijn om ervoor te zorgen dat we geen belangrijke functionaliteit zijn vergeten.

18 januari 2019

Ik heb wat gegevens verzameld over hoe vaak de berichten "je bent geblokkeerd" aan onze gebruikers verschijnen op deze pagina. Er zijn enkele grafieken en een tabel met ruwe gegevens, evenals enkele gesynthetiseerde bevindingen. De belangrijkste conclusies:

• Blokkeringsmeldingen verschijnen heel vaak op de grootste Wikimedia-projecten, soms meer dan de werkelijke bewerkingen. (op de Engelse Wikipedia vonden in een periode van 30 dagen 6,2 miljoen geblokkeerde bewerkingen plaats .)
• De wikitext-editor voor desktop ziet de overgrote meerderheid van de indrukken met een grote marge. De visuele editor en mobiele blokken kunnen minder vaak voorkomen, maar toch worden ze elke maand weergegeven aan duizenden mensen. Er zijn hindernissen om hun displays te optimaliseren, gezien de erfenis van eerste ontwerp voor desktop.

16 januari 2019

Gedeeltelijke blokkeringen zijn ingeschakeld op de Italiaanse Wikipedia! 🎉 We zijn op zoek naar meer Wikipedia's om te testen, laat ons alsjeblieft een bericht op de overlegpagina achter als uw gemeenschap bereid is om te testen! Meer informatie.

Ook team kijkt nu ook naar mogelijke softwareoplossingen om langdurig misbruik op Wikimedia te beperken. We verkennen enkele ideeën die zijn opgesomd in § Probleem 1. Gebruikersnaam- of IP-adresblokkades zijn te omzeilen hierboven. We streven ernaar dat ons voorlopige onderzoek eind februari is afgerond en zullen alle notities en bevindingen hier publiceren.

20 december

Gedeeltelijk blokkeren is nog in ontwikkeling. Het is ingeschakeld op Test Wikipedia het zal in januari op de Italiaanse Wikipedia worden ingeschakeld.

Data over de berichten "je bent geblokkeerd" is zichtbaar in deze grafiek voor zeven wiki's (er worden er binnenkort meer toegevoegd). Ik ga vanmiddag wat gecorreleerde gegevens onderzoeken om te zien of er interessante inzichten zijn. Voor nu zijn de meest inzichtelijke dingen: 1) de meeste mensen zien dat ze op desktop geblokkeerd zijn via de wikitext-editor 2) behalve op de Duitse Wikipedia, die een ongelooflijk hoog aantal API-blokken heeft, en 3) ruwe overzichtelijke berekeningen tonen aan dat mobiele blokkademeldingen verschijnen ten opzichte van desktopsites hetzelfde als algemene bewerkingstrends (~95% van de bewerkingen komt van desktop-editors). Afhankelijk van wat ik vandaag gezien heb, plaats ik hier een aanvulling.

Een laatste opmerking over blokkeren om 2018 af te sluiten: in het komende jaar zal mijn team beginnen met het onderzoeken naar blokkeren van apparaten, die beschreven en besproken werd als probleem 1. Gebruikersnaam- of IP-adresblokken zijn gemakkelijk te ontwijken. We willen begin 2019 een voorstel doen aan de Wikimedia Raad van Bestuur.

5 december

Ons team werkt nog aan het aanpakken van de laatste gebreken voordat we het op Italiaanse Wikipedia inzetten. We zijn optimistisch dat we volgende week deze mijlpaal kunnen bereiken! In de tussentijd is het testen beschikbaar op Test Wikipedia en Test Wikidata voor gebruikers die geïnteresseerd zijn in het bekijken van wat er tot nu toe klaar is. We zijn ook ervan overtuigd dat we de Namespace blokken bijna klaar kunnen krijgen tegen het einde van december, voordat we stoppen voor de wintervakantie. Die functionaliteit zou in januari klaar moeten zijn op Test Wiki.

Gisteren hebben we de opsporing van de blokkerenmeldingen die aan gebruikers verschijnen geactiveerd - de "Je bent geblokkeerd" berichten. De gegevens zijn zichtbaar in deze grafiek. Deze gegevens worden nu alleen gemeten op de Italiaanse Wikipedia, maar we willen deze volgende week hier nog 19 wiki's aan toevoegen. We kunnen dit vergelijken met de andere bekende blokkerengegevens om beter te begrijpen hoe vaak geblokkeerde gebruikers proberen te bewerken. Dit moet onze beslissingen inlichten over of of of hoe deze berichten kunnen worden verbeterd en werkstromen voor gebruikers kunnen worden ontsloten.

8 november

Gedeeltelijk blokkeren is nu in productie op Test Wikipedia en Test Wikidata! Als u een beheerder bent van een andere wiki en de functionaliteit wilt testen, schrijf dan een bericht op onze overlegpagina.

Deze eerste set functies is beperkt: beheerders kunnen een gebruiker of IP blokkeren om tot 10 gespecificeerde pagina's te bewerken. Er zijn enkele bekende fouten waar we nu aan werken (bijvoorbeeld, als een beheerder gedeeltelijk wordt geblokkeerd van een pagina, kan hij geen geen pagina verwijderen) en we gaan later november weer verder met het bouwen van namespace- en uploadblokkeren.

Als u gedeeltelijk blokkeren test, horen we graag van u. Geef ons een briefje over uw ervaring met het hulpmiddelent. We zoeken specifiek feedback over:

• Wat is een passende limiet van het aantal pagina's waar een gebruiker van moet worden geblokkeerd? In de eerste versie is de limiet 10, maar het kan elk getal zijn.
• Bent u tevreden met de manier waarop gedeeltelijk blokkeren wordt geregistreerd?
• Moeten we iets veranderen wat al gebouwd is? Is het waarschuwingsbericht in de VisualEditor te vriendelijk?

Hartelijk dank!

22 augustus 2018

Als onderdeel van ons werk aan Gedeeltelijk blokkeren (phab:T2674) hebben we vastgesteld dat we ook een systeem moeten bouwen dat meerdere gelijktijdige blokkades op één account (gebruiker of IP) kan zetten, zodat gemeenschappen verschillende sancties met verschillende vervaldatums kunnen instellen. (Een gebruiker kan bijvoorbeeld een onbepaalde blokkade hebben om bestanden te uploaden, maar een 24-uurs sitebrede blokkade.) We noemen dit werk multi-blocks en dit werk kan in phab:T194697 worden bijgehouden. Er loopt een nieuwe ronde ontwerpen en dit zal volgende week worden gedeeld op de projectpagina.

Voor wie geïnteresseerd is in de technische kant van het blokkeren, houden we een technische RFC over databasewijzigingen die we van plan zijn door te voeren. Een samenvatting van onze veranderingen is te vinden op phab:T199917.

28 juni 2018

De afgelopen maanden heeft het team Anti-Harassment Tools van de Wikimedia Foundation gewerkt aan verbeteringen van blokkeerhulpmiddelen. We hebben onlangs een datum-tijdselector toegevoegd aan de Special:Block-tool om het makkelijker te maken om precieze blokverlooptijden in te stellen (phab:T132220). We hebben ook de melding geüpgraded die gebruikers op mobiele apparaten verschijnt te informeren dat ze geblokkeerd zijn (phab:T165535). Om blokkades sterker te maken, hebben we cookieblokkatingen uitgebreid naar IP-blokken om het voor mensen moeilijker te maken hun blokkade te omzeilen (phab:T152462).

We hebben het bouwen van een manier onderzocht waarop beheerders gebruikers kunnen blokkeren door een gehashte combinatie van browserinformatie, maar besloten dat dit niet effectief zou zijn zonder meer data tijdens bewerkingssessies te verzamelen (phab:T188160). Daarom hebben we besloten deze functie nu niet verder te ontwikkelen. In plaats daarvan hebben we tickets voorbereid om CheckUsers de mogelijkheid te geven te blokkeren op IP-adres of IP-bereik en browser user agent (phab:T100070). Dit werk is voorbereid en klaar om te bouwen, wacht alleen nog het toekennen van de prioriteit.

Ons team werkt aan het bouwen van Partial Blocks, oftewel de mogelijkheid voor beheerders om een gebruiker te blokkeren voor alleen een specifieke pagina, alle pagina's binnen een namespace of voor het uploaden van bestanden. Wij denken dat dit meer tactische sancties zal toestaan voor lastige gebruikers die op andere delen van de wiki productief zijn. (phab:T2674) U kunt dat project volgen en ontwerpen zien op deze pagina.

Huidige functionaliteit blokkeren

Gebruikers en IP's kunnen nu op Wikimedia-wiki's worden geblokkeerd om artikelen te bewerken. op MediaWiki.org Blokkades verbieden gebruikers om alle pagina's in alle namespaces op de wiki te bewerken, met als optionele uitzondering de overlegpagina van de geblokkeerde gebruiker. Blokkades zijn standaard toegestaan aan beheerders en worden publiekelijk geregistreerd op Special:Log, Special:BlockList en Special:Block.

Net als bij blokkades verbieden globale accountlocks gebruikers om in te loggen op een Wikimedia-wiki, globale blokken verbieden gebruikers om in te loggen op een Wikimedia-wiki, globale blokken kunnen worden ingesteld op IP-adressen.

Autoblocks kunnen worden toegewezen aan gebruikersnaamblokken, die automatisch gedurende 24 uur IP-adressen blokkeren die door de betreffende gebruiker worden gebruikt.

Probleem 1. Gebruikersnaam- of IP-adresblokkeringen zijn te omzeilen

Blokkades kunnen worden ingesteld op gebruikersnaam, IP-adres of IP-bereik. IP-adressen kunnen gemakkelijk worden vervalst of gewijzigd via proxies. De barrière voor het opzetten van een nieuw account is zeer laag en gemakkelijk te omzeilen. De Wikimedia beweging waardeert openheid en privacy, dus we moeten de afweging van slechte acteurs in evenwicht brengen met ons platform toegankelijk houden voor nieuwkomers van goede wil.

We zouden nieuwe blokkeringstechnieken kunnen implementeren die gebruikmaken van andere, modernere identificatietechnologieën. Deze functies moeten voldoen aan ons Privacybeleid en de Gebruiksvoorwaarden.

Voorgestelde oplossingen:

• Blokkeren op user-agent (inclusief zoeken CheckUser)
• Blokkeren op ID van apparaat (inclusief zoeken CheckUser)
• Globaal blokkeren op gebruikersnaam
• Voeg "het voorkomen van het aanmaken van een account" toe aan het globaal blokkeren
• Cookie blokkering voor anonieme gebruikers
• Voeg een manier toe om een autoblock meer dan 1 dag te verlengen
• Proactief globaal blokkeren open proxies (of een systeem bouwen dat hun IP's cross-wiki deelt)
• Hash persoonlijk identificeerbare gegevens om als procentuele overeenkomst met CheckUser te tonen
• AI die bewerkingspatronen en taal vergelijkt om mogelijke sockpuppets te voorspellen
• Identificeren van sockpuppets door patronen van typen te herkennen (bijv. ritme/snelheid), netwerksnelheid en bewerkingspatronen (bijv., tijd van de dag, bewerkingstijd, categorieën bewerkte pagina's)
• Alle bijdragen weergeven die binnen een IP-interval zijn gedaan, op één feed (ook bekend als "Range Contributions")
• Uitgebreide Nuke tot IP-bereik

Probleem 2. Agressieve blokkeringen kunnen per ongeluk voorkomen dat onschuldige omstanders kunnen bewerken

Veel IP's en IP-bereiken worden gedeeld door meerdere gebruikers (bijv. bibliotheken, scholen, kantoren) en de meeste individuele IP's kunnen (en zullen) door ISP's worden toegewezen aan andere gebruikers. Als van een slechte bewerker de IP of IP-bereik wordt geblokkeerd, kunnen dus mogelijk andere gebruikers ook niet bewerken. Sommige IP-blokken maken het mogelijk om ingelogd bewerken te doen, en goede gebruikersnamen kunnen worden opgenomen in de bijbehorende witte lijst van ingelogde bewerkers die dan wel mogen bewerken bij het blokkeren op IP.

We kunnen nieuwe functies implementeren die IP's verbieden om een account te bewerken of te maken, maar goede bewerkers toestaan om nog steeds accounts te maken en productief te zijn met bewerken.

Voorgestelde oplossingen:

• Eis dat alle accounts die in een IP-bereik zijn aangemaakt hun e-mailadres bevestigen voordat ze gaan bewerken.
• Voorkom het gebruik (of zet een vlag) van op de zwarte lijst geplaatste e-mailadressen bij het maken van een gebruikersaccount
• Beperk het aanmaken van accounts en e-mailverzending per browser, evenals op IP-adres
• Eis dat een e-mailadres uniek is voor bewerkingen in bepaalde IP-bereiken (mogelijk vereist dit dat er voor domeinen een witte lijst is)
• Laat de CheckUsers gehashte e-mailadressen vergelijken
• AI bouwen die automatisch een bloklengte en -type instelt op basis van UserAgent, IP en/of e-mail
• Tweetrapsauthenticatie eisen voor bewerkingen in bepaalde IP-bereiken
• Twinkle en/of Huggle van gadgets omzetten in extensies, hun nauwkeurigheid verhogen

Probleem 3. Blokkeren voor de volledige site is niet altijd de juiste reactie op bepaalde situaties

Kleinere, meer tactische blokkeringen kunnen situaties ontmijnen terwijl ze constructieve bijdragers behouden. Op sommige wiki's, zoals de Engelstalige Wikipedia, wordt dit concept bepaald door een ban. Echter, de technische middelen om een ban af te dwingen zijn nu beperkt, en daardoor kan een gebruiker onnodig geheel worden geblokkeerd om de wiki te bewerken.

Het blokkeren op de hele site is een soort slaan met de hamer. Hoe kunnen we vliegenmeppers bouwen om te voorkomen dat een gebruiker beperkte schade veroorzaakt terwijl ze een deel van de wiki actief kunnen blijven.

Voorgestelde oplossingen:

• Een gebruiker blokkeren voor...
  • ...individuele pagina's
  • ...alle pagina's binnen een specifieke categorie
  • ...specifieke namespaces
  • ...het aanmaken van een pagina
  • ...uploaden van bestanden
  • ...alle pagina's behalve overlegpagina's
  • ...alle pagina's behalve van witte lijst
  • ...bekijken Speciale pagina Bijdragen
  • ...andere gebruikers e-mailen of pingen
• Toestaan dat beheerders precies specificeren welke rechten geblokkeerd moeten worden.
• Toestaan dat beheerders tijdelijk een autobevestigde status van een gebruiker herroepen.
• Eis dat alle bewerkingen door een gebruiker met uitgestelde wijzigingen (deferred changes) worden verwerkt.
• Een blokkade zetten die pas vervalt wanneer een gebruiker een bepaalde pagina heeft gelezen (trainingmodule, gebruikersoverlegpagina, enz.)
• Toestaan dat beheerders de bewerkingen door een gebruiker beperken tot een maximum per dag/uur/enz
• Een versie van AbuseFilter maken die wordt uitgevoerd op alle bewerkingen van gespecificeerde gebruikers om aangepaste, complexe blokkades te maken
• Hulpmiddel om te voorkomen dat gebruikers over zichzelf schrijven.
• Maskeringssystemen om gebruikers voor elkaar op wiki te verbergen

Probleem 4. De hulpmiddelen om blokkades te zetten, te monitoren en te beheren bieden mogelijkheden voor productiviteitsverbetering

De bestaande hulpmiddelen (Special:Block, de API, Twinkle, Special:BlockList, enz.) worden dagelijks gebruikt door talrijke gebruikers op alle Wikimedia-wiki's. Het gebruik van deze hulpmiddelen kan tijdrovend zijn, dus we willen ideeën onderzoeken hoe we de werkstromen kunnen vereenvoudigen om een blokkade in te stellen of te wijzigen, de logs te controleren en de status of details van een blokkade te controleren.

Voorgestelde oplossingen:

• Wanneer u een waarschuwing plaats op een gebruikersoverlegpagina, toon dan hoeveel andere waarschuwingen ooit aan die gebruiker zijn gegeven.
• Twinkle zou automatisch moeten weten welk waarschuwingssjabloon voor die gebruiker moet worden gebruikt.
• Log ban-achtige blokkeringen, wat kan resulteren in het tonen van de informatie op hun gebruikerspagina, bijdragen of automatisch een lijst van alle verbannen gebruikers genereren.
• Toestaan dat CheckUser's specifieke IP's bekijken
• Laat beheerders de vorige blokkeringen als toevallig aantekenen
• Sta toe dat beheerders een datumbereik te instellen voor een blokkade via de date-time selector
• Toestaan dat beheerders verschillende vervaltijden instellen voor het blokkeren van bewerken en het maken van een account
• Sta toe dat beheerders gebruikersnamen controleren als ze die willen blokkeren
• In logs de vervaltijden van de blokkades weergeven
• Een waarschuwing op de blokkadepagina tonen wanneer beheerders een gevoelig IP-adres blokkeren
• Special:Block kan een duur voor de blokkade normale beleidsovertredingen suggereren
• Verbeterde manier om massablokkades in te stellen
• Het proces van bezwaar maken tegen een blokkade kan worden verbeterd om het werk dat voor beheerders nodig is te verminderen
• Op Special:Block gaan weergeven als een gebruiker op dit moment geblokkeerd is op een andere wiki
• De mobiele blokkadeberichten zijn erbarmelijk
• Toestaan dat beheerders een blok kunnen 'pauzeren' zodat de gebruiker kan deelnemen aan discussies op de wiki

Zie ook

• Lijst links — Een lijst met links op Meta Wiki, MediaWiki.org en Phabricator over bestaande hulpmiddelen voor blokkering of suggesties voor verbeteringen.
• Engels Wikipedia-beleid — Een lijst met links op de Engelse Wikipedia over blokkeringsbeleid of hulpmiddelen, overlegpaginagesprekken over verbeteringen.
• Blokkeermeldingen — Gegevens over hoe vaak de "u bent geblokkeerd"-meldingen verschijnen bij mensen die proberen een wiki te bewerken.
• Bewerkingsbeperkingen — De documentatiepagina van het team Anti-Harassment Tools van de WMF over hoe nieuwe hulpmiddelen de sociaal opgelegde bewerkingsbeperkingen van de Engelstalige Wikipedia kunnen ondersteunen.
• Gedeeltelijk blokkeren — Projectpagina voor gedeeltelijke blokken, waarmee beheerders kunnen voorkomen dat een gebruiker specifieke pagina(s) of namespace(s) bewerkt.