user:lustiger_seth/editfilter-vortrag

vortrag ueber das edit-filter auf der WP:AdminConvention 2022.

filter vs. regel

im folgenden unterscheidung:

• filter: das tool an sich
• regel: eine einzelne massnahme im edit-filter (werden normalerweise ebenfalls "filter" genannt)

motivation

szenario: massenhafte schaedliche, aber irgendwie aehnliche aenderungen durch person(en) mit wechselnder ip-adresse, z.b. eintraege von "deine mudda".

was soll man als admin dagegen tun?

• ansprache? fehlanzeige, ip-adresse aendert sich staendig
• sperre der ip-adresse (oder von accounts)? dito
• artikel-sperre? fehlanzeige, weil viele artikel betroffen
• ip-ranges: doof, weil kollateralschaeden, ausserdem unwirksam bei proxies
• loesung (manchmal): edit filter

motivation: beispiel

special:abusefilter/84

page_namespace == 0 
& user_age < 3600
& added_lines irlike "\bdein{1,2}e[mr]? mudd+(a+|er|\b)"

die regel greift, wenn alle folgenden eigenschaften erfuellt sind:

• aenderung im artikel-namensraum
• aendernde person ist entweder ip-adresse oder account, der vor weniger als einer stunde angelegt wurde
• in den hinzugefuegten oder veraenderten zeilen befindet sich "deine mudda" (oder eine aehnliche schreibung davon)

geschichte

• eingefuehrt in dewiki 2009 februar/maerz
• erste regeln: 1. vergessene signatur in diskussionen, 2. hartnaeckiger wort-ersetzer, 3. "fetter Text"
  • nicht von anfang an primaer fuer vandalismus eingesetzt,
  • sondern auch fuer versehentliche fehler oder auch als wartungsliste
• meinungsbild 2009 juli: "keine 'privaten' (also nur fuer admins einsehbaren) regeln" -> MB als ganzes abgelehnt
• meinungsbild 2009--2011: akzeptanz des filters -> eingeschlafen
• meinungsbild 2011 oktober: regel #36 "edit-war schutz: maximal 3 edits pro nase innerhalb von 30h zugelassen" wurde abgeschafft

statistik

• 343 regeln seit 2009 erstellt (zum vergleich: enwiki: 1181)
• 60--65% versteckt (nur fuer admins einsehbar)
• 101 aktiv (enwiki: 292)
• davon:
  • 24 logging-only (also keine massnahme, ausser log-eintrag und ggf. tag)
  • 71 disallow (edit wird verhindert)
  • 6 warn (nach speicher-versuch erscheint hinweis; danach normale speicherung moeglich)
• anzahl unterschiedlicher admins, die die 343 regeln zuletzt editierten:
  • 29, wobei nur 6 admins 10-mal oder haeufiger vorkommen
• 778k geloggte edits, viele davon verhindert

(stand: 2022-01-09)

funktionsweise

• auf "speichern" druecken -> ueberpruefung mit allen aktivierten regeln
• getriggerte regel verhindert speicherung (oder loggt zumindest mit)
• regel enthaelt bedingung, die aus teilbedingungen besteht
• teilbedingungen sind verknupeft ueber aussagenlogische operatoren & (UND) oder | (ODER), z.b.

"wenn bedingung A und bedingung B oder bedingung C erfuellt, dann verhindere edit (oder logge mit)"

• viele funktionen: arithmetische/boolsche/vergleichs-operatoren, string-funktionen
• viele variable des edits: z.b. timestamp, seitenname, alter text, neuer text, summary, eigenschaften der aendernden (name, alter, ...), letzte 10 aendernde, edit count, ...
• regulaere ausdruecke: schwierig, eigener vortrag noetig (ansonsten, siehe internet)

syntax: beispiele

vermutlich keine sinnvollen artikel (#276)

new_size < 65
& old_size == 0
& action=="edit"
& user_age < 3600
& page_namespace == 0
& !(new_wikitext irlike "^#(?:redirect|weiterleitung)|\{\{(?:delete|Falschschreibung|Löschen|SLA)\b")

alternative zu artikel-sperre (fiktive regel):

action == "edit"
& user_editcount < 40
& page_title = "Wikipedia"
& added_lines contains "alles voller Nazis"
& !(added_lines contains "<ref")

kontaktsperre (fiktive regel):

user_name = "Peppone"
& page_namespace = 0
& action = "edit" /* d.h. verschiebungen waeren noch erlaubt */
& page_first_contributor = "Don Camillo"

syntax-tuecken I

gewachsene, (fuer programmierer) nicht-intuitive syntax, siehe auch enwiki. beispiele:

operatoren-priorisierung

• A & B | C & D == (A & B) | (C & D) gilt nicht, sondern (im ggs. zu den meisten programmiersprachen)
• A & B | C & D == (((A & B) | C) & D)
• d.h. D muss true sein, damit die gesamte bedingung ueberhaupt als true evaluiert werden kann.

added_lines enthaelt auch nicht geaenderten text

• added_lines contains "moep" ist nicht, was man zunaechst denkt.

was meist gemeint ist:

• count("moep", added_lines) > count("moep", removed_lines)

in bezieht sich nur auf strings, nicht auf arrays

• nicht doof: "Deine Mudda" in user_name
• doof: page_namespace in [0, 1, 14] (denn das tut nicht, was man zunaechst denkt.[1])

was meist gemeint ist:

• equals_to_any(page_namespace, 0, 1, 14)

syntax-tuecken II

missverstaendlich variablennamen

• article_text ist nicht der text eines artikels, sondern der seitenname. besser page_title

regexp versuchen zu vermeiden

• nicht: old_wikitext rlike "Innungskrankenkasse|Ersatzkasse|Ehemalige Betriebskrankenkasse"
• auch nicht so gut lesbar/wartbar: old_wikitext rlike "(?:Innungskranken|Ersatz|Ehemalige Betriebskranken)kasse"
• besser:

contains_any(old_wikitext,
  "Innungskrankenkasse",
  "Ersatzkasse",
  "Ehemalige Betriebskrankenkasse")

einrueckung

• nicht:

contains_any(old_wikitext,
  "Innungskrankenkasse",
  "Ersatzkasse",
  "Ehemalige Betriebskrankenkasse") | added_line contains
  "Sonstwaskasse"
 & (page_namespace == 3
 | user_age < 42)

• besser:

contains_any(old_wikitext,
  "Innungskrankenkasse",
  "Ersatzkasse",
  "Ehemalige Betriebskrankenkasse") 
| added_line contains "Sonstwaskasse"
& (page_namespace == 3
  | user_age < 42)

fuehrung durch die spezial-seiten

• uebersicht WP:FILT -> special:abusefilter -> liste, sortiermoeglichkeiten
• einzelne regel, beispiel:
  • WP:bearbeitungsfilter/276, special:abusefilter/276 -> special:abuselog/783842
• examine: einzelnen edit untersuchen
  • variablen anschauen
  • andere regeln testweise anwenden
• batch testing:
  • regeln an vergangen edits ausprobieren (ohne log-eintraege zu erzeugen)
• debugging: bedingungen auswerten
  • z.b. stringfunktionen ausprobieren: 4 in [0, 1, 14]

vergleich mit anderen admin-tools

• vorteile:
  • praeziser und zugleich flexibler einsetzbar als andere tools (kollateralschaeden reduzierbar)
  • edits theoretisch nicht verloren
• nachteile:
  • hinweis erst beim speichern
  • komplizierter (fuer admins und betroffene)

grenzen

• unberechenbarer vandalismus
• sprachlich nicht-primitive aenderungen
• vandalierende, die herausforderungen moegen
• rollback immun gegen edit-filter

gefahren/risiken

• fehleranfaelligkeit, z.b. regexp
• viel zu wenig kontrolle
  • admins koennten praktisch weitgehend unbehelligt leute schikanieren
  • ideen gibt's, aber bisher immer eingeschlafen
• frust bei den leuten bei false positives (beispiel)
  • dunkelziffer der verlorenen leute

massnahmen:

• admins: testen, testen, testen
• admins: gegenseitige kontrolle
• alle: Wikipedia:Bearbeitungsfilter/latest topics auf die watchlist setzen und mithelfen (und sei es nur durch anpingen der zustaendigen admins)

fazit

• wichtiges, in teilen sehr hilfreiches tool
• aber auch mit respekt zu nutzen

fragen

fragen?

backup-folien

der oder das edit-filter / abuse-filter / missbrauchsfilter / bearbeitungsfilter?

• der oder das? geht beides. duden sagt: fachsprachlich neutrum
• seth nennt es "edit-filter"
  • verstehen in dewiki alle
  • verstehen in enwiki alle
  • treffender als "abuse filter"
• aber: "missbrauchsfilter" leider tief in der software verankert (stellenweise)

syntax-beispiel

keine artikelnamen mit emojis (#277)

user_age = 0
& page_namespace < 2
& page_title rlike "[☀-⛿✀-➿🀀-🧿]"
& new_size < 200
& !(new_wikitext irlike "^#(?:redirect|weiterleitung) \[\[Unicode")

syntax-tuecken

auch bei regulaeren ausdruecken sind zeilenumbrueche moeglich:

statt

old_wikitext rlike "Innungskrankenkasse|Ersatzkasse|Ehemalige Betriebskrankenkasse"

z.b.

old_wikitext rlike "(?x:
  Innungskrankenkasse              # siehe sonstwo
 |Ersatzkasse                      # kam auch mal vor
 |Ehemalige\sBetriebskrankenkasse  # so halt
)"

• kommentare (via #) moeglich
• wichtig: whitespace wird ignoriert und muss dann expliziert werden, z.b. durch \s

regel loeschen

• nicht mehr benoetigte regeln immer loeschen/deaktivieren
  • bessere uebersicht
  • weniger false positives
  • bessere performance
• unterschied zwischen loeschen und deaktivieren vernachlaessigbar
  • wird unterschiedlich angezeigt, sonst nix

sonstiges

• dieser vortrag wurde (hoffe ich zumindest) genderneutral geschrieben -- und zwar ohne die verwendung von sternchen, altmodischem binnen-i, obsoleter "beid-"nennung oder unterstrichen, ha!