user:lustiger_seth/editfilter-vortrag

filter vs. regel Bearbeiten

im folgenden unterscheidung:

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

motivation Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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

gefahren/risiken Bearbeiten

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 Bearbeiten

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

fragen Bearbeiten

fragen?

backup-folien Bearbeiten

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

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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 Bearbeiten

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