Community health initiative/Blocking tools and improvements/de

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

🗣   We invite you to join the discussion!
🛠   Track in Phabricator at T120734.

Das Team „Werkzeuge gegen Belästigung“ (Anti Harassment Tools) der Wikimedia Foundation lädt alle Wikimedianer ein, im Dezember 2017 neue Sperrinstrumente und Verbesserungen der vorhandenen Sperrinstrumente zu diskutieren, um sie Anfang 2018 zu entwickeln.

Aktualisierungen

11. September 2019

Teilweise Sperren wurden für alle Wikivoyage-, Wikisource- und Wiktionary-Wikis aktiviert. Wir glauben, dass sich die Funktion für Teilblöcke in einem guten, stabilen Stadium befindet, da in den letzten Monaten nach der Bereitstellung der Funktion in verschiedenen Projekten immer weniger Fehler aufgetreten sind. Das Team hat viel Zeit in die Verbesserung der Backend-Infrastruktur des Sourcecodes investiert und sichergestellt, dass der Code zuverlässig ist, um zukünftige Funktionen zu berücksichtigen, die möglicherweise hinzugefügt werden müssen.

There continues to be requests from more wikis for partial blocks. We also presented about partial blocks at Wikimania and it was very well-received, with several attendees asking for partial blocks to be enabled on their home wikis. In light of the general positive reception to partial blocks on wikis where it is deployed, we are planning to do a wider deployment to more Wikimedia projects in the next few weeks.

We will continue to collect feedback about partial blocks as we launch the feature on more wikis, alongside data collection on usage of the feature. We are also around to do maintenance work on the features, as and when needed.

1. März 2019

Today I officially share the Wikimedia Foundation's Anti-Harassment Tools team's recommendations for tools to combat long-term abuse that occurs on our wikis. This 9-page document roughly defines the types of long-term abuse that occurs, outlines the existing tools and tactics used to mitigate and tolerate this behavior, investigates potential new softwares to combat this abuse (namely device blocking) and makes recommendations for next steps.

In brief, our recommendations are to avoid device blocking, as it would be an expensive endeavour with very low likelihood for successful impact. Instead, our team recommends alternate tactics including a user reporting system, improvements to CheckUser, additional muting features, and more.

An immediate byproduct of this research is that our team will work on extending cookie block functionality to the Visual and mobile editors. — phab:T196575

15. Februar 2019

Initial feature development on partial blocks is complete! Admins can now set blocks that only prohibit editing on certain page(s) and/or namespace(s). The rollout will be slow and staged to ensure we didn't forget any important functionality.

18. Januar 2019

I've compiled some data about how often the "you are blocked" messages appear to our users on Community health initiative/Blocking tools and improvements/Block notices. There are some graphs and a table of raw data as well as some synthesized findings. Here are the main takeaways:

• Block notices appear very often on the largest Wikimedia projects, sometimes outnumbering actual edits. (6.2 million blocked edits occured on English Wikipedia over a 30-day period.)
• The desktop wikitext editor sees the vast majority of impressions by a wide margin. (98% on English Wikipedia, 89.5% on Spanish, and 98.7% on Russian.)
• The VisualEditor and mobile block notices may occur less frequently, but still display to thousands of people every month. There are hurdles to optimizing their displays, given the legacy of desktop-first design.

16. Januar 2019

Partial Blocks have been enabled on Italian Wikipedia! 🎉 We're looking for more Wikipedias to test, please leave us a talk page message if your community is willing to test! More information can be found at the project page.

Also of note is that our team is currently looking into potential software solutions to mitigate Long-Term Abuse on Wikimedia. We are exploring some ideas listed in § Problem 1. Username or IP address blocks are easy to evade by sophisticated users above. We are aiming for our preliminary investigation to be complete by the end of February and will publish all notes and findings here on Meta Wiki.

20 Dezember

Partial blocks are still in development. They are enabled on Test Wikipedia and will be enabled on Italian Wikipedia in January.

Data on the "you are blocked" messages is visible on this graph for seven wikis (more to be added soon.) I'll be spending this afternoon digging into some correlated block data to see if there are any interesting insights. For now, the most insightful things are: 1) far-and-away most people learn they are blocked on desktop via the wikitext editor 2) except on German Wikipedia, which has an incredibly high count of API blocks and 3) rough back-of-napkin calculations show that mobile block notices appear relative to desktop site notices the same as general edit trends (~95% of edits are from desktop editors.) Depending on what I have by the end of today I may post an addendum here.

One final note about blocking to close our 2018: in the next year my team will begin looking into device blocking, which was outlined and discussed as Problem 1. Username or IP address blocks are easy to evade by sophisticated users. We aim to make a proposal to the Wikimedia Board of Trustees in early 2019.

5 Dezember

Our team is still working on addressing the final defects before we enable Partial Blocks on Italian Wikipedia. We're optimistic that we can hit this milestone next week! In the meantime testing is available on Test Wikipedia and Test Wikidata for users interested in taking a look at what's ready so far. We're also confident that we can get Namespace blocks to a near-ready state by the end of December, before we break for the winter holidays. That functionality should be ready on Test Wiki in January.

Yesterday we enabled tracking on the block notice messages that appear to users — a.k.a. the "You are blocked" messages. The data is visible on this graph. This data is currently only being measured on Italian Wikipedia but we plan to enable it on 19 more wikis next week. We will be able to compare this to the other known block data to better understand how often blocked users attempt to edit. This should inform our decisions on if or how to improve these messages and unblock workflows for users.

8 November

Partial blocks are live on Test Wikipedia and Test Wikidata! If you're an admin on another wiki and would like to test the functionality please write a message on our talk page.

This first feature set is limited: admins can block an user or IP from editing up to 10 specified pages. There are some known defects that we're currently working on (for example, if an admin is partially blocked from a page they can't delete any page.) and we'll get back to building namespace and upload blocks in later November.

If you're testing partial blocks we'd love to hear from you! Drop us a note about your experience with the tool. We're looking specifically for feedback about:

• What is an appropriate limit of the number of pages a user should be blocked from? In the first version limit is 10, but it can any number.
• Are you satisfied with how partial blocks are logged?
• Do we need to change anything that has already been built?
• Is the warning message in the VisualEditor too gentle?

Vielen Dank!

22 August 2018

As part of our work on Partial Blocks (phab:T2674) we've have determined that we also need to build a system that allows for multiple simultaneous blocks to be set against a single account (user or IP) to allow communities to set different sanctions of different expiration dates. (For example, a user could have an indefinite block from uploading files but a 24-hour sitewide block.) We are referring to this work as multi-blocks and this work can be tracked in phab:T194697. Another round of designs are underway and will be shared next week on the project page.

For those interested in the technical side of blocks, we're holding a technical RFC about database changes we plan to make. A summary of our changes can be found at phab:T199917.

28 Juni 2018

Over the past several months the Wikimedia Foundation's Anti-Harassment Tools team has been working on improvements to blocking tools. We recently added a datetime selector to the Special:Block tool to make it easier to set precise block expirations (phab:T132220). We also upgraded the notice that appears to inform users on mobile devices that they are blocked (phab:T165535). To make blocks stronger, we've expanded cookie blocking to IP blocks to make it more difficult for people to evade their block (phab:T152462).

We investigated building a way for administrators to block users by a hashed combination of browser information but decided it would not be effective without capturing more data during edit sessions (phab:T188160). Because of this we've decided to not pursue this feature at this time. Rather, we've prepared tickets to give CheckUsers the ability to block by IP address or IP range and browser user agent (phab:T100070). This work is prepared and ready to build, just awaiting prioritization.

Our team is currently working on building Partial Blocks, or the ability for administrators to block a user from just a specific page, all pages inside a namespace, or from uploading files. We believe this will allow more tactical sanctions to be set for troublesome users who are productive on other parts of the wiki. (phab:T2674) You can follow that project and see designs at Community health initiative/Per-user page, namespace, and upload blocking.

MediaWikis bestehende Sperrfunktionalität

Gegenwärtig können Benutzer und IPs auf Wikimedia-Wikis am Editieren von Artikeln gehindert werden. Sperren verhindern Edits in allen Namensräumen mit der möglichen Ausnahme der eigenen Diskussionsseite des gesperrten Benutzers. Standardmäßig werden Sperren von Administratoren verantwortet und öffentlich unter Spezial:Log, Spezial:BlockList und Spezial:Block geloggt.

Ähnlich den Sperren (blocks) hindern globale Anmeldesperren (locks) User an der Anmeldung an jedem Wikimedia-Wiki, globale Sperren hindern User an der Anmeldung an jedem Wikimedia-Wiki, und globale Sperren können gegen IP-Adressen eingesetzt werden.

Benutzersperren können mit Autoblocks versehen werden, um für volle 24 Stunden IP-Adressen der die Wp-Regeln verletzenden Person automatisch zu sperren.

Problem 1: Kenntnisreiche Benutzer können Konto- und IP-Sperren leicht umgehen

Sperren können gegen einen Benutzernamen, eine IP-Adresse, oder einen IP-Adressbereich gerichtet werden. IP-Adressen kann man leicht fälschen oder per Proxy ändern. Die Schwelle zum Anlegen eines neuen Kontos ist sehr niedrig und leicht zu überwinden. Die Wikimedia-Bewegung achtet Offenheit und Privatsphäre, darum müssen wir abwägen: einerseits Störenfriede auszusperren, andererseits unsere Plattform für gutwillige Neulinge leicht zugänglich zu halten.

Wir könnten neue Sperrtechniken implementieren, die weitere, aktuellere Erkennungstechnologien anwenden. Diese Funktionen werden notwendig unsere Regeln zur Privatsphäre und Nutzungsbedingungen einhalten müssen.

Vorgeschlagene mögliche Lösungen

• Sperren nach User-Agent (einschliesslich CheckUser-Suche)
• Nach der Geräte-ID sperren (einschliesslich CheckUser-Suche)
• Globale Sperren von bestimmten Benutzernamen
• Mit der globalen Sperre auch „Konto anlegen verbieten“
• Anonyme per Cookie sperren
• Einen Weg ergänzen, den Autoblock über 1 Tag hinaus zu verlängern
• Open proxies vorbeugend global sperren
• Hash personally identifiable data to surface as a percentage match to CheckUser
• AI that compares editing patterns and language to predict possible sockpuppets
• Identify sockpuppets by typing patterns (e.g. rhythm/speed), network speed, and editing patterns (e.g. time of day, edit session length, categories of pages edited)
• Display all contributions made within an IP range on one feed (aka 'Range Contributions')
• Erweitertes Massenlöschen für IP-Ränge

Problem 2. Aggressive Sperren können ungewollt unschuldige, gutwillige Unbeteiligte am Editieren hindern

Viele IPs und Adressbereiche werden von mehreren Usern benutzt (z. B. Bibliotheken, Schulen, Bürogebäude), und die meisten IPs können (und werden) von den Providern regelmäßig neuen Usern zugeteilt. Wenn einem Störenfried die IP oder der Netzbereich gesperrt wird, können andere Benutzer auch nicht mehr editieren. Einige IP-Sperren erlauben das Editieren als angemeldeter Benutzer. Von den IP-Sperren, die auch angemeldete Edits verhindern, können gute Benutzernamen durch Whitelisting ausgenommen werden.

Wir könnten neue Funktionen implementieren, die IPs daran hindern, zu editieren oder Wegwerfkonten einzurichten, andererseits aber gutwilligen Unbeteiligten neue Konten und produktives Editieren erlauben.

Vorgeschlagene mögliche Lösungen:

• Alle Konten, die in einem Netzbereich angelegt wurden, müssen vor dem Editieren ihre Email-Adresse bestätigen
• Verbieten (oder Markieren), dass Email-Adressen, die auf einer Blacklist stehen, mit einem neuen Benutzerkonto verbunden werden
• Kontenanlagen und Mails pro Browser und pro IP-Adresse verlangsamen
• Die E-Mail-Adresse muss für Änderungen in bestimmten IP-Bereichen eindeutig sein (möglicherweise sind E-Mail-Domains der Whitelist erforderlich).
• Ermöglichen Sie CheckUsers, gehashte E-Mail-Adressen zu vergleichen
• Build AI that automatically sets a block length and type based on UserAgent, IP and/or email
• Für Änderungen in bestimmten IP-Bereichen ist eine Zwei-Faktor-Authentifizierung erforderlich
• Twinkle und/oder Huggle von Gadgets in Erweiterungen umwandeln und deren Genauigkeit erhöhen

Problem 3. Sperrung für die gesamte Website ist in manchen Situationen nicht immer die angemessene Antwort

Kleinere, taktische Sperren könnten Situationen entschärfen und konstruktive Autoren erhalten. Auf manchen Wikis wie der englischen Wikipedia wird dieses Konzept mit Bannen (bans) ausgeübt. Allerdings sind gegenwärtig die technischen Mittel beschränkt, Banne durchzusetzen, und darum könnte ein Benutzer unnötig vom gesamten Wiki ausgesperrt werden.

Site-weite Sperren ähneln einem Vorschlaghammer. Wie können wir Fliegenklatschen bauen, die den User an einer begrenzten Schädigung hindern, ihn aber als Teil des Wikis behalten?

Vorgeschlagene mögliche Lösungen:

• Benutzersperren für …
  • … einzelne Seiten
  • … alle Seiten in einer bestimmten Kategorie
  • … bestimmte Namensräume
  • … Seiten neu anzulegen
  • … Dateien hochzuladen
  • … alle Seiten außer Diskussionsseiten
  • … alle Seiten außer einer Whitelist
  • … Spezial:Beiträge einzusehen
  • … Mails oder Pings an andere Benutzer
• Admins ermöglichen, genau festzulegen, welche Rechte gesperrt werden.
• Admins ermöglichen, jemandem den Status als bestätigter Benutzer vorübergehend zu entziehen.
• Festlegen, dass alle Edits eines Benutzers als deferred changes (zurückgestellte Änderungen) behandelt werden.
• Sperre, die erst abläuft, wenn der Benutzer eine festgelegte Seite gelesen hat (Übungsmodul, Benutzerdiskussion, etc.)
• Administratoren ermöglichen, die Änderungen eines Benutzers auf eine maximale Anzahl pro Tag/Stunde/etc. Zu drosseln
• Build a version AbuseFilter that runs on all edits of specified users to create custom, complex blocks
• Tool um Benutzer daran zu hindern über sich selbst zu schreiben.
• User masking systems to obfuscate or ‘hide’ users from each other on wiki

Problem 4. Die Tools zum Setzen, Überwachen und Steuern der Sperren haben Verbesserungspotential, die Produktivität betreffend

Die vorhandenen Sperrwerkzeuge (Spezial:Block, die API, Twinkle, Spezial:BlockList, etc.) werden täglich von zahlreichen Usern in allen Wikimedia-Wikis verwendet. Sie anzuwenden kann zeitaufwendig sein, deshalb würden wir gerne Ideen untersuchen, wie wir die Abläufe beim Sperren, Sperränderungen, Sperrlogüberwachung, und Prüfen von Sperrstatus und -details vereinfachen können.

Vorgeschlagene mögliche Lösungen

• Beim Hinterlassen einer Warnung anzeigen, wieviele andere Warnungen dieser User schon erhalten hat.
• Twinkle sollte die für den User geeignete Warnvorlage automatisch kennen.
• Banne ebenso wie Sperren zu loggen würde ermöglichen, diese Information auf der Benutzerseite oder mit den Benutzerbeiträgen anzuzeigen, oder eine Liste aller gebannten Benutzer automatisch zu erzeugen.
• CheckUsern erlauben, bestimmte IPs zu beobachten
• Admins ermöglichen, frühere Sperren als irrtümlich zu kennzeichnen
• Admins erlauben, eine Sperrdauer über ein Datum-Zeit-Auswahlfeld zu setzen
• Admins erlauben, für Editieren vs. Konto-Erstellen verschiedene Sperrdauern einzusetzen
• Admins erlauben, Benutzernamen bei der Sperre zu oversighten (wirksamer zu verstecken)
• Sperrablauf in den Logs anzeigen
• Im Sperrinterface warnen, wenn Admins dabei sind, eine heikle IP sperren.
• Special:Block could suggest block length for common policy infractions
• Verbesserte Methode zum Setzen von Massensperren
• Block appeal process could be improved to reduce the work required for admins
• Display if a user is currently blocked on another wiki on Special:Block
• Mobile Blockbenachrichtigungen sind miserabel
• Administratoren ermöglichen, einen Block zu pausieren, damit der Benutzer an Diskussionen teilnehmen kann

Siehe auch

• /Links – Eine Liste von Links auf das Meta-Wiki, MediaWiki.org und Phabricator zu bestehenden Sperrwerkzeugen oder Verbesserungsvorschlägen.
• /English Wikipedia policies – Eine Linkliste der englischsprachigen Wikipedia über Sperrregeln oder -werkzeuge, und Diskussionsseitenabschnitte über Verbesserungen.
• Community health initiative/Editing restrictions – Die Dokumentationsseite des WMF-Anti-Harassment-Tools-Teams beschreibt, wie neue Tools die gemeinschaftlich durchgesetzten Editbeschränkungen in der englischen Wikipedia unterstützen könnten.