Analyse der Changesets von OSM Newcomern

Eine Durchsatzratenbegrenzung wurde neu eingeführt

Auf dem OpenStreetMap (OSM)-API gibt es seit kurzem eine Durchsatzratenbegrenzung, die die Auswirkungen einer bestimmten Art von Kartenvandalismus begrenzen soll: neue Nutzer*Innen melden sich an und bearbeiten massenhaft OSM-Daten, indem sie z. B. tausende OSM-Objekte löschen oder bestimmte Tags für eine große Anzahl von OSM-Objekten entfernen. Die Durchsatzratenbegrenzung ist der erste Schritt, der dagegen unternommen wurde und begrenzt die Anzahl der Bearbeitungen, die mit neuen Konten vorgenommen werden können. Einzelheiten über Einführung findest Du im Pull Request, der diese Funktion durch eine Änderung der config/settings.yml eingeführt hat.

Kurz gesagt: Neue Benutzer*Innen dürfen am ersten Nutzungstag von OSM nur 1.000 Änderungen pro Stunde hochladen. Das Hinzufügen eines neuen Objekts zu OSM führt in der Datenbank oft zu mehreren Änderungen. So entsprechen 1.000 Änderungen in etwa dem Hinzufügen von 200 Gebäuden zu OSM. In der ersten Woche, nachdem ein Benutzer mit der Bearbeitung begonnen hat, steigt die Begrenzung nichtlinear auf 100.000 Änderungen pro Stunde an.

Wir haben die folgende Analyse durchgeführt, um die Auswirkungen dieser Maßnahme zu beleuchten. Wir wurden auf das Thema aufmerksam, als die Missing-Maps-Community anfing zu berichten, dass von ihnen organisierte humanitäre Kartierungsaktivitäten von der Durchsatzratenbegrenzung betroffen sind. Wir wollten herausfinden, ob es sich bei diesen Berichten nur um einige wenige Ausnahmefälle handelt oder ob eine größere Anzahl von Kartierenden betroffen ist.

OSM ist ein großartiges Projekt, dessen Community sich von Anfang an für Offenheit eingesetzt hat. Um bei OSM mitzuwirken, muss man sich nur anmelden und zustimmen, dass eigene Beiträge unter der OpenStreetMap-Lizenz freigegeben werden. Im Einklang mit den OSM-Guidelines ist es daher wichtig, jede Maßnahme, die diese Offenheit einschränkt, sorgfältig abzuwägen. Gleichzeitig ist klar, dass Vandalismus auch bei OSM eine ernsthafte Bedrohung darstellen kann.

Hauptziel der Analyse ist es, Antworten auf die folgenden Fragen zu finden:

• Wie viele neue Nutzer*Innen treten OSM täglich bei?
  

• Wie viele der neuen Nutzer*Innen sind möglicherweise von der Durchsatzratenbegrenzung betroffen?
  

• Gibt es eine Durchsatzratenbegrenzung, die Vandalismus verhindert aber gewöhnliche Mapping-Aktivitäten nicht beeinträchtigt?
  

Unsere Analyse beruht auf der OSM-Changeset-Database. In diesem GitHub-Repository ist eine Ansatz beschrieben, nach dem sich eine solche Database einrichten lässt. Die Database, die wir benutzt haben, enthält Daten bis zum 22.10.2023. Unsere Fragen betrachten wir unter folgendem Gesichtspunkt:

• Wäre die Durchastzratenbegrenzung am 01.01.2023 in kraft getreteb, wie viele Nutzer*Innen wären dann am 22.10.2023 davon betroffen gewesen?

Wir haben absichtlich einen Zeitraum gewählt, der nur die Zeit vor der Einführung der Durchastzratenbegrenzung abdeckt. Jedes Changeset, das durch die Ratenbegrenzung blockiert wird, könnte dennoch in die OSM-Datenbank hochgeladen werden. Das entsprechende Changeset enthält dann jedoch nicht die originalen Edits, sondern es wäre leer.  Im Wesentlichen fehlen uns also Daten darüber, wie viele Changesets derzeit betroffen sind. Anhand der historischen Daten von OSM können wir die Auswirkungen der Ratenbegrenzung jedoch abschätzen.

Wie viele neue Nutzer*Innen treten OSM täglich bei?

Zunächst gilt es herauszufinden, wie viele neue Nutzer*Innen 2023 bei OSM mitgewirkt haben. Diese Anzahl wird dann mit der gesamten Menge von Nutzer*Innen im Jahr 2023 verglichen. Schauen wir uns die Verteilung der Werte über Zeit an:

Auf Abbildung 1 sieht man, dass täglich ungefähr 450 neue Benutzer*Innen OSM beitreten. Die Abbildung zeigt auch, dass es im Februar 2023 und im August 2023 einige Ausreißer gab. Dennoch sieht man selten mehr als 1.000 neue Nutzer*Innen, die OSM an einem Tag beitreten. Insgesamt haben mehr als 130.000 OSM-Nutzer*Innen im Jahr 2023 ihre ersten Bearbeitungen vorgenommen und mehr als 6.000 Nutzer pro Tag tragen im Durchschnitt aktiv zu OSM bei. Dieser Wert schwankt jedoch im Laufe der Zeit.

Fassen wir diese Ergebnisse zusammen und versuchen wir, eine grobe Antwort auf unsere erste Frage zu geben:

• Von den durchschnittlich 5.906 aktiven Mapper*Innen pro Tag sind etwa 449 neue Nutzer*Innen

• 7,6 % der täglichen OSM-Nutzer*Innen sind Neulinge, die möglicherweise von der neuen Ratenbegrenzung betroffen sein könnten, je nachdem, wie viel sie an ihrem ersten Tag kartieren.
  

Wie viele neue Nutzer*Innen sind möglicherweise von der Durchsatzratenbegrenzung betroffen?

Ein simpler Ansatz: Änderungen pro Tag

Hier werfen wir einen Blick auf die neuen Nutzer*Innen. Unsere „Verdächtigen“  sind diejenigen, die im zeitraum ab dem 01.01.2023 mehr als 1000 Änderungen an ihrem ersten Tag vorgenommen haben. Diese Nutzer*Innen hätten die Ratenbegrenzung erreicht, wenn diese schon in Betrieb gewesen wäre. Dies ist nur eine ungefähre Messung, da wir Änderungen pro Tag anstatt Änderungen pro Stunde betrachten haben. Der Vorteil hierbei ist, dass man mit einfachen SQL Queries relativ schnell Ergebnisse produzieren kann. Wir haben die Analyse mit unterschiedlichen Werten (1000 / 1500 / 2000 / 2500 / 5000) durchgeführt, um zu sehen, welche Auswirkungen die Anpassung der Ratenbegrenzung hat.

Wir wissen, dass es insgesamt 5.095 (von 132.423) neuen Nutzer*Innen geben könnte, die möglicherweise von einer Ratenbegrenzung von 1000 Änderungen pro Tag betroffen wären: Wie erwartet werden diese Werte kleiner, je höher die Ratenbegrenzung ist.

Fortgeschrittener Ansatz: Änderungen pro Stunde mit beweglichem Zeitfenster

Von den oben genannten „Verdächtigen“ haben wir die Bearbeitungen überprüft, die innerhalb eines Zeitfensters von einer Stunde vorgenommen wurden. Wenn Nutzende oder deren Changesets innerhalb dieser Stunde das Limit erreichen, handelt es sich um betroffene Changesets. Dies kommt dem sehr nahe, wie das OSM-API die Ratenbegrenzung implementiert.

Darüber hinaus haben wir die Nutzer*Innen überprüft, die von der OSM-Data-Arbeitsgruppe gesperrt wurden. Im gegebenen Zeitraum dieser Analyse sperrte die OSM-API 895 Nutzer*Innen wegen Vandalismusfällen, die von der DWG* bestätigt wurden. Diese Nutzer*Innen haben 63 285 Changesets erstellt.

Wir haben auch die Beiträge von OSM-Nutzer*Innen analysiert, deren Konten gelöscht wurden, nachdem sie Bearbeitungen vorgenommen haben. Einige dieser Benutzer*Innen könnten ihre Konten nach dem Bearbeiten selbst gelöscht haben, um ihren Vandalismus zu verschleiern. Andere Benutzer*Innen wurden von OSM-Systemadmins als Reaktion auf ihr destruktives Mapping-Verhalten gelöscht. Eine Liste aller gelöschten OSM-Benutzer*Innenkonten ist auf dem Planet OSM Download Server verfügbar. Leider enthält diese Liste außer den Benutzer*Innen-IDs selbst keine weiteren Informationen. Es ist also nicht möglich, das Datum oder den Grund einer Löschung einfach zu rekonstruieren.

Schließlich können wir vergleichen, ob sich die Bearbeitungen, die von den durch die OSM-Data-Arbeitsgruppe gesperrten Nutzern*Innen vorgenommen wurden, mit den von der OSM-Ratenbegrenzung betroffenen Changesets überschneiden.

Aus der obigen Tabelle und der Abbildung erfahren wir zwei Dinge:

• 3.304 Nutzer*Innen hätten die Begrenzung erreicht. Wir schätzen, dass eine Begrenzung der Bearbeitungsrate auf 1000 pro Stunde etwa 2,5 % der neuen OSM-Nutzer*Innen betreffen würde.

• Von den betroffenen Nutzer*Innen wurde nur eine geringe Anzahl (294 von 3.304) tatsächlich von dere OSM-Data-Arbeitsgruppe gesperrt.

• Bei einer kleinen Anzahl von 134 Nutzer*Innen wurden die OSM-Konten gelöscht (entweder von ihnen selbst oder von OSM-Systemadmins). Diese Nutzer*Innen haben jedoch die meisten Changesets beigesteuert (39 978 von 58 193), die die Begrenzung erreicht hätten.

Es gibt 601 Nutzer*Innen, die durch die OSM-Data-Arbeitsgruppe gesperrt wurden, die aber nicht von der Ratenbegrenzung betroffen gewesen wären. Da die DWG in der Regel auf Zuruf handelt, ist dies zu erwarten. Auch Nicht-Neueinsteiger*Innen können aus verschiedenen Gründen gesperrt werden. Es ist wichtig, darauf hinzuweisen, dass der Zweck der Ratenbegrenzung niemals war, alle Nutzer*Innen zu erwischen, sondern vielmehr, den Schaden zu begrenzen, den eine bestimmte Art von Vandalismus anrichten kann.

Einblicke pro OSM-Changeset-Hashtag

Hier prüfen wir, inwieweit sich die Ratenbegrenzung auf organisierte Kartierungsaktivitäten auswirkt, wie sie von humanitären Organisationen mit dem HOT Tasking Manager durchgeführt werden. Bei Mapathons kommen Menschen zusammen um zu kartieren. Viele davon sind neu bei OSM sind und besitzen keinen Account. Ziel dieser Mapathons ist es, während der Veranstaltung, die in der Regel 1-3 Stunden dauert, eine Vielzahl von Gebäuden und Straßen zu kartieren. Viele Teilnehmer*Innen eines Mapathons erstellen ihr Konto auf der Veranstaltung und beginnen mit der Kartierung, nachdem sie eine kurze Schulung von 15-60 Minuten erhalten haben. Als die Ratenbegrenzung eingeführt wurde, berichteten mehrere Kartiereende, die an Mapathons teilgenommen haben, dass sie oder einige ihrer Mitkartierenden aufgrund der Ratenbegrenzung keine Daten auf OSM hochladen konnten.

Wir haben die Anzahl der Nutzer und die Anzahl der Changesets analysiert, die die Begrenzung erreicht hätten, und nach den verwendeten Hashtags gefiltert. Der Hashtag hotosm-project-* wird verwendet, um alle Änderungen zu kennzeichnen, die zu einem HOT Tasking Manager Projekt gehören. Wir haben auch den Hashtag missingmapsverwendet, der von vielen humanitären Organisationen genutzt wird.

Auf der obigen Tabelle erkennt man, dass organisiertes humanitäres Mapping sehr wahrscheinlich von der neuen ratenbegrenzung betroffen sein kann:

• Ungefähr 1.900 Nutzer*Innen, die das Changeset-Hashtag hotosm-project-*benutzt haben, hätten die Begrenzung erreicht. Das ist die Mehrheit (58%) aller Betroffenen (1.904 von 3.304 Nutzer*Innen. 790 Nutzer*Innen hätten den Grenzwert um mehr als 500 Bearbeitungen überschritten.

• Die am humanitären Mapping beteiligten Nutzer*Innen sind für einen relativ kleinen Teil der Changesets verantwortlich, die durch die Ratenbegrenzung blockiert worden wären (9.462 von 58.193).

• Die Auswirkung der Ratenbegrenzung auf das organisierte humanitäre Mapping über den HOT Tasking Manager ist stärker als die Auswirkung der Ratenbegrenzung auf Nutzer, die von der OSM Data Working Group gesperrt wurden.
  

Welche Strategie können wir wählen, um eine Ratenbegrenzung zu wählen, die Vandalismus verhindert, aber keine Auswirkungen auf das reguläre Mapping hat?

Höhere Begrenzung

Unsere Ergebnisse zeigen, dass sich eine Anpassung der Ratenbegrenzung positiv auf ihre Effektivität auswirken könnte. Die Anzahl der Benutzer und die Anzahl der Änderungssätze, die unbeabsichtigt durch die Ratenbegrenzung blockiert wurden, könnten durch Festlegen einer höheren Ratenbegrenzung als die Derzeitige reduziert werden. Beispielsweise würde eine Ratenbegrenzung von 2.000 Bearbeitungen pro Stunde die Anzahl der betroffenen HOT Tasking Manager-Benutzer von 1.904 auf 312 reduzieren. Gleichzeitig hätte ein Ratenbegrenzung von 2.000 Bearbeitungen einen hohen Anteil der Changesets von Nutzern*Innen, deren Konten gelöscht wurden, erfasst.

Bei einer Begrenzung auf 5.000 Bearbeitungen pro Stunde würde sich die Gesamtzahl der betroffenen Benutzer drastisch von 3.304 auf 352 verringern. Gleichzeitig würden immer noch etwa 50 % aller Änderungen blockiert werden. Eine relativ hohe Anzahl an Changesets von Nutzer*Innen gelöschter Konten würde jedoch unentdeckt bleiben.

Globale und regionale Begrenzungen

Um alternative Optionen zur Verhinderung von Vandalismus in OSM zu untersuchen, wollten wir sehen, wie sich die betroffenen Changesetz global verteilen. Unsere beiden Karten zeigen jeweils die betroffenen Changesets bei einem Limit 1000 und 5000 Bearbeitungen pro Stunde.

Abb. 4: Heat Map der potenziell blockierten Changesets (1000 Änderungen/Stunde)

Abb. 5: Heat Map der potenziell blockierten Changesets (5000 Änderungen/Stunde)

Abb 6: Anzahl der betroffenen Changesets pro Land (Ratenbegrenzung 1000 & 5000)

Interessanterweise befinden sich die meisten betroffenen Änderungssätze in nur sehr wenigen Ländern (Abb. 6). Unabhängig davon, welchen Grenzwert man wählt, sticht die Ukraine auf der Karte hervor. Dies könnte darauf hindeuten, dass eine Ratenbegrenzung, die nur auf bestimmte vordefinierte Regionen angewendet wird, sinvoller sein könnte als eine globale Ratenbegrenzung, die alle Änderungssätze gleich behandelt, unabhängig davon, wo sie sich befinden.

Fazit

Alles in allem können wir feststellen, dass eine große Anzahl von Nutzer*Innen sehr wahrscheinlich von der Einführung der OSM-API-Ratenbegrenzung betroffen ist. Die Ergebnisse zeigen, dass etwa 2,5 % aller neuen OSM-Mapper*Innen von der Ratenbegrenzung betroffen sind. Die meisten dieser betroffenen Mapper*Innen führen ihre ersten Bearbeitungen während eines Mapathons oder mit dem HOT Tasking Manager durch.

Es ist eine sehr schwierige Aufgabe, die Ratengrenze richtig festzulegen. Das Ziel der Ratenbegrenzung war es, großflächigen Vandalismus zu erschweren und es den Freiwilligen zu ermöglichen, den Überblick zu behalten und hinter den Vandalen aufzuräumen. Hier argumentieren wir, dass das derzeitige Limit geändert werden sollte, um die Anzahl der betroffenen Nutzer*Innen zu reduzieren und gleichzeitig das Ziel, das Ausmaß des Vandalismus in OSM zu begrenzen, beizubehalten.

Durch eine Anpassung des Ratenlimits könnte man die Anzahl der betroffenen Mapper reduzieren, aber immer noch die meisten der betroffenen Changesets „erwischen“, die OSM schaden. Wir empfehlen, das Ratenlimit auf 2500 oder 2500 Bearbeitungen pro Stunde zu setzen. Die Einführung einer ortsabhängigen Ratenbegrenzung könnte die Zahl der Fehlalarme weiter minimieren.

Wir sind uns jedoch darüber im Klaren, dass es kein perfektes Ratenlimit oder einen perfekten Ansatz gibt, um das Ausmaß des Vandalismus in OSM zu begrenzen. Dennoch ist es wichtig, das richtige Gleichgewicht zwischen Maßnahmen zu finden, die Vandalismus entgegenwirken, aber auch Neulinge davon abhalten, OSM beizutreten und ihre ersten Bearbeitungen vorzunehmen.

In der OSM-Community werden derzeit viele weitere Ideen diskutiert, wie man auf die in den letzten Monaten aufgetretene Bedrohung durch Vandalismus reagieren kann. Aus unserer Sicht ist es wichtig, dass jede vorgeschlagene Maßnahme und ihre Auswirkungen vor ihrer Umsetzung evaluiert werden sollten. Aus unserer Perspektive als Forschende ziehen wir die Sperrung von Nutzer*Innen durch die DWG der Löschung von Nutzerkonten durch die OSM-Systemadmins vor. Die Liste der gesperrten Nutzer*Innen wäre ein guter Ausgangspunkt für andere Forschende, um den Vandalismus in OSM zu analysieren und zu überwachen. Die Arbeit mit der Liste der gelöschten Konten macht dies komplizierter, da zusätzliche Metadaten nicht verfügbar sind.

Hier konnten wir einige der unerwünschten Nebeneffekte der aktuellen Ratenbegrenzung aufzeigen, auch wenn uns derzeit noch Erkenntnisse und Daten darüber fehlen, wie effektiv die aktuelle Ratenbegrenzung das Ausmaß des Vandalismus eindämmt. Die in diesem Blogbeitrag vorgestellten Erkenntnisse werden benötigt, um den derzeitigen Ansatz mit allen anderen diskutierten Ideen und Maßnahmen vergleichen zu können. Künftige Forschungsarbeiten müssen insbesondere Aufschluss darüber geben, wie die Genauigkeit und Empfindlichkeit der vorgeschlagenen Ansätze in Bezug auf (a) die Anzahl der betroffenen OSM-Nutzer*Innen und (b) die Anzahl der blockierten Changesets einzuschätzen ist

Kontaktiere uns unter ohsome@heigit.org, wenn Du weitere Fragen zu unserer Analyse und ihren Ergebnissen haben. Ein Jupyter-Notebook mit dem Workflow der Datenanalyse findest Du auf GitHub.

*In einer früheren Version dieses Blogbeitrags hieß es, dass „die OSM-API 895 Nutzer*Innen blockiert hat, die mutmaßlich Vandalismus in OSM betrieben haben“. Wir wollten nicht andeuten, dass es unklar ist, ob diese Nutzer OSM Vandalisums betrieben haben und haben diesen Teil des Textes angepasst.

**Update 2024-02-16: Wir haben eine Analyse der gelöschten Benutzerkonten hinzugefügt. Während dadurch nur sehr wenige Nutzer*Innen in die Liste aufgenommen werden, ist die Auswirkung auf die Gesamtzahl der betroffenen Changesets erheblich. Wir haben die Schlussfolgerung aktualisiert und schlagen vor, die Ratenbegrenzung auf 2000 oder 2500 Edits pro Stunde anzupassen.