Bearbeiten als IP: Verbesserung der Privatsphäre und Verminderung des Missbrauchs/Updates

Übersicht

Updates

Legal

FAQ

Basic updates about the project · Updates from the Wikimedia Foundation Legal department · Updates about changes adjusting the software to temporary accounts

September 2023: New features, new names, and Wikimania

Wikimania slide deck

Project updates

• Temporary account names format. The format of the temporary account names will be ~YYYY-nnnnn-nnn. YYYY refers to the year when the temporary account was created. The n-sequence represents the unique identifier of the temporary username. For example, a temporary account created in 2023 may look like: ~2023-27459-041. The year prefix helps identify how old a temporary account may be. This provides information for patrollers or anyone looking to communicate with the editor. We took the decision after discussions on the wiki talk page and on Phabricator (T337103). Many thanks to everyone who took part in those conversations!
• Team changes and projected timeline for first deployments. The Anti-Harassment Tools team has been merged with the Trust and Safety Tools team. The newly formed team is called Trust and Safety Product. It will have an expanded scope. This change to the structure may have an effect on the timeline of this project. We will have more updates to share as we develop a roadmap for the new team. Our current projected timeline for this project is as follows:
  • Deployment to testwiki – January 2024
  • Deployment to first pilot wikis – beginning March 2024
• Frequently asked questions page. We have created the frequently asked questions (FAQ) page. We will expand and update it in the coming weeks and months.
• Wikimania update and the project name change. At Wikimania in Singapore, we presented an update on the project. You can access the slide deck for the presentation. There's also a recording of the full presentation available on YouTube. At Wikimania, we were using the former project name, IP Masking. After that, we decided to change it into Temporary accounts for unregistered editors, or simply Temporary accounts. It presents our changes in a plain language, without a technical metaphor.

New features

• Global blocking. We will work on global blocking for registered and temporary users. Currently, global blocking only works for IP addresses and ranges. There has been a long-standing request to expand this feature to allow blocking users, too. We will be defining this feature and developing it over the next couple of months. You may follow the Phabricator task (T17294) for updates.
• Global User Contributions. We will bring the Global User Contributions feature to MediaWiki. This feature currently exists through the GUC tool. Our change will make it easier for users to view contributions from accounts across projects. It will be possible via a special page. This will be particularly useful when temporary accounts go into effect. For technical details, see T337089.

Ältere Updates

April 2023: Der Plan zur IP-Maskierung

Wie versprochen, gibt es hier ein Update darüber, wie die IP-Maskierung funktionieren würde. Es wird die Änderungen für nicht registrierte und registrierte Autor/innen verbergen. Wir möchten gleich zu Beginn darauf hinweisen, dass wir noch viele offene Fragen und Dinge haben, über die wir noch nicht entschieden haben. Dies ist unser anfänglicher Plan und deckt nicht alles ab, was wir während des Projekts machen wollen. Während wir vorankommen, entdecken wir neue, bisher unvorhergesehene Arbeiten. Euer Feedback hilft uns zu verstehen, was wir noch tun können, um die IP-Maskierung für unsere Communities einfacher zu machen.

Dieses Update hat das Format einer FAQ, damit die anstehenden Änderungen klar und verständlich sind.

Was ändert sich durch die IP-Maskierung aus der Sicht eines/einer nicht eingeloggten Autors/in?

Derzeit werden nicht eingeloggte Nutzer/innen vor dem Abschluss einer Bearbeitung darüber informiert, dass ihre Änderungen ihrer IP-Adresse zugeordnet werden. In Zukunft werden nicht eingeloggte Nutzer/innen vor dem Abschluss einer Bearbeitung darüber informiert, dass ihre Änderungen einem temporären Konto zugeordnet werden. Der Name ist eine Zahl, die für jedes neue Konto hochgezählt wird. Das Konto wird mit einem Cookie verknüpft, das im Browser des Nutzers/der Nutzerin gespeichert wird. Solange dieses Cookie existiert, behält der/die Nutzer/in dasselbe temporäre Konto und alle seine/ihre Änderungen werden diesem Konto zugewiesen. Die IP-Adressen der Nutzer/innen können sich ändern, aber das temporäre Konto wird sich nicht ändern, solange das Cookie existiert. Ein temporäres Konto, das in einem Wiki erstellt wurde, funktioniert auch in anderen Wikis, zu denen der/die Nutzer/in beitragen kann.

Wie sehen die temporären Benutzernamen aus?

Das wissen wir noch nicht. Unsere ersten Entwürfe sahen die Verwendung eines Sternchens als Präfix vor, gefolgt von einer automatisch aufsteigenden Zahl. (Beispiel: *12345.) Du findest diese Mockups unten. Aber wie einige Freiwillige feststellten, ist das Sternchen wegen eines ausstehenden MediaWiki-Bugs keine gute Wahl.

Wir diskutieren verschiedene Präfix-Optionen und werden mit diesen Nutzertests durchführen. Unsere derzeitigen Top-Kandidat/innen (in keiner bestimmten Reihenfolge) sind:

• Caret (^) – User:^12345
• Bindestrich (-) – User:-12345
• Tilde (~) – User:~12345
• Ausrufezeichen (!) – User:!12345
• Fragezeichen (?) – User:?12345
• Jahrespräfix – User:2023-12345

Hältst du eine davon für eine großartige oder für eine furchtbare Wahl? Bitte füge deine Kommentare entweder auf der Diskussionsseite oder auf Phabricator hinzu.

Wie lange bleiben temporäre Benutzernamen bestehen?

Einige Zeit nach der ersten Bearbeitung (voraussichtlich ein Jahr) oder als Folge des Löschens des Caches läuft das Cookie automatisch ab. Bestehende Bearbeitungen werden aber weiterhin zugewiesen. Wenn der alte Accountname abläuft und der/die Nutzer/in in Zukunft wieder etwas bearbeitet, erhält er/sie einen neuen temporären Account.

Was ändert sich durch die IP-Maskierung aus Sicht eines Patrollers?

Eingeschränkte IP-Adressen-Aufdeckung

Die größte Änderung ist, dass IP-Adressen nicht mehr für die Allgemeinheit sichtbar sind. Wer keinen Account hat oder die erforderlichen Schwellenwerte für den Zugriff auf IP-Adressen nicht erfüllt (siehe Rechtsaktualisierung), kann keine IP-Adressen sehen. Um den Einfluss auf das Patrouillieren abzumildern, werden wir Verbesserungen am IP Info Feature herausbringen. Dazu gehören auch Daten aus dem Spur-Dienst.

Zugriff auf IP-Adressen erhalten

Gemeinsam mit der Rechtsabteilung der Stiftung haben wir neue Richtlinien entwickelt.

Diese legen fest, wer auf IP-Adressen zugreifen kann und wie. Nutzer/innen, die die Anforderungen erfüllen, können sich über Spezial:Einstellungen für die Offenlegung von IP-Adressen entscheiden. Sieh dir an, wie die Aufdeckungsfunktion im Detail funktionieren wird.

Dieser Zugang und die Offenlegung werden protokolliert und stehen einer begrenzten Gruppe von Nutzer/innen (CheckUsers, Stewards, Trust & Safety) zur Verfügung.

Bessere Kommunikationskanäle mit temporären Autor/innen

Temporäre Konten werden mit einem Browser-Cookie verknüpft. Solange das Cookie besteht, werden die Bearbeitungen der Nutzerin/des Nutzers demselben temporären Konto zugeordnet. Inhaber/innen von temporären Konten können genauso wie registrierte Nutzer/innen Benachrichtigungen über die Talk-Seite erhalten. Wir hoffen, dass dies eine bessere Kommunikation mit den temporären Nutzern ermöglicht. Sie kann auch einige seit langem bestehende Probleme lösen, die von den Communities aufgeworfen wurden (siehe T278838).

IP-Adressen der Vandalen dokumentieren

Es wird möglich sein, die IP-Adressen von bösen Akteuren öffentlich auf den Seiten für Langzeitmissbrauch zu dokumentieren, wie es derzeit der Fall ist. Es sollte jedoch darauf geachtet werden, dass keine IP-Adressen für andere temporäre Nutzer/innen preisgegeben werden. Bei der Diskussion über mögliche böse Akteure sollten Tools wie Unterdrückung verwendet werden, wenn sich der Nutzer nicht wie vermutet als Vandale erweist. Weitere Details dazu findest du in den Richtlinien.

Verfügbare Tools für Patrolling

Wie IP-Autoren/in können temporäre Benutzer/innen mit Special:Block, Special:Checkuser und Special:Investigate kontrolliert und überwacht werden.

Zusätzlich kann IP Info Feature verwendet werden, um Informationen über die zugrundeliegende IP-Adresse für die angegebene Revision zu erhalten.

Wir entwickeln Richtlinien für Cloud Tools und Bots, die für Patrolling auf IPs zugreifen. Wir werden in Kürze ein Update dazu haben.

Was passiert mit bestehenden IP-Adressen auf unseren Websites?

Bestehende IP-Adressen, die bereits in unseren Wikis erfasst sind, bleiben unangetastet. Bearbeitungen, die nach der IP-Maskierung erfolgen, werden temporären Benutzernamen zugewiesen. Da wir die IP-Maskierung schrittweise einführen werden, bedeutet dies, dass diese Änderung in verschiedenen Wikis zu unterschiedlichen Zeiten stattfinden wird.

Wie funktioniert die Funktion zum Aufdecken von IP-Adressen?

Nutzer/innen, die auf IP-Adressen zugreifen können, werden in der Lage sein, IP-Adressen für temporäre Konten aufzudecken. Mockups, wie diese Funktion funktionieren würde:

Was passiert mit Tools und Bots, die auf IP-Adressen angewiesen sind, um zu funktionieren?

Wir arbeiten daran, den Einfluss auf die von Freiwilligen gewarteten Tools zu verstehen. Das ist eine Aufgabe für unser Team sowie für die Forschungs- und Ingenieurteams. Als Nächstes werden wir mit der Rechtsabteilung zusammenarbeiten, um herauszufinden, welche Tools weiterhin auf IP-Adressen zugreifen dürfen und welche Richtlinien für ihre Nutzung gelten. Sobald wir einen Aktionsplan haben, werden wir auf dieser Seite ein Update veröffentlichen.

Ausrollplan

Wir planen, die IP-Maskierung langsam zu testen, um den Communities ausreichend Zeit für Feedback und Tests zu geben. Wir wollen, dass unsere Rollouts die Abläufe in den Communities nicht behindern. Eine weitere Priorität ist es, unerwünschte Auswirkungen auf die Gesundheit der Communities zu vermeiden. Wir haben Kennzahlen eingeführt, die wir bei der Einführung der Änderungen beobachten wollen.

Wir sind auf der Suche nach Communities, die Kandidat/in für die Testeinführung (Pilotierung) von IP Masking werden könnten. Wir berücksichtigen Kriterien wie die Anzahl der IP-Edits, die die Communities erhalten, die Dringlichkeit der Anti-Vandalismus-Arbeit, den Umfang des Projekts und das Störungspotenzial. Kurz vor dem Start von IP Masking werden wir auf dieser Seite ein weiteres Update zu unseren ausgewählten Kandidat/in geben.

Wenn du möchtest, dass deine Community den Start von IP Masking testet, triff bitte eine Entscheidung als Community und lass es uns auf der Diskussionsseite wissen.

<span id="16. Februar 2023:_Refocusing_work_on_IP_Masking">

16. Februar 2023: Neuausrichtung der Arbeit an der IP-Maskierung

Hallo zusammen! Nachdem wir die erste Phase von IP Info Feature und anderen damit zusammenhängenden Projekten abgeschlossen haben, konzentrieren wir uns nun offiziell wieder auf das Kernprojekt IP Masking. Wir machen mit der technischen Planung weiter, um zu verstehen, was sich ändern muss, wenn IP Masking in Kraft tritt. Wir werden unsere technischen Freiwilligen einbeziehen, damit sie uns bei der Bewertung der Änderungen und der Migration der Tools helfen können, falls dies erforderlich ist. Ein Teil dieser Planungsarbeit hat bereits auf Phabricator begonnen, und du kannst uns dort erreichen, wenn du Fragen zu bestimmten Aufgaben hast.

Ich werde in Kürze einen weiteren Beitrag veröffentlichen, in dem ich einen Überblick über das MVP (Minimum Viable Product, deutsch: minimal lebensfähiges Produkt) gebe, auf das wir uns geeinigt haben. Dieses MVP basiert auf den Gesprächen, die wir in der Vergangenheit mit der Community über diese Seite und andere Medien geführt haben. Du kannst dir diese Gespräche gerne ansehen und die vergangenen Updates auf dieser Seite durchlesen. Wenn du Fragen oder Bedenken hast, kannst du uns auf der Diskussionsseite erreichen.

<span id="25. Februar 2022:_Implementation_Strategy_and_next_steps">

25. Februar 2022: Implementierungsstrategie und die nächsten Schritte

Hallo zusammen. Wir haben ein Update zur Strategie der IP-Maskierung.

Zunächst einmal vielen Dank an alle, die auf dieser Seite angekommen sind und uns ihr Feedback gegeben haben. Wir haben von vielen von euch gehört, dass diese Seite nicht leicht zu lesen ist, und wir arbeiten daran, das zu ändern. Wir möchten euch wirklich dafür danken, dass ihr euch die Zeit genommen habt, die Informationen hier und auf der Diskussionsseite durchzugehen. Wir haben jeden Kommentar auf der Diskussionsseite berücksichtigt, bevor wir über den Umsetzungsplan entschieden haben.

Wir möchten auch vorausschicken, dass es noch viele offene Fragen gibt. Wir haben bei diesem Projekt noch einen langen Weg vor uns und würden uns freuen, wenn du dich an weiteren Diskussionen beteiligst, sobald sie aufkommen. Falls du es noch nicht getan hast, lies dir bitte diesen Beitrag über die Frage, wer weiterhin Zugang zu IP-Adressen haben wird durch, bevor du weiterliest.

Wir haben von der Community gemischte Rückmeldungen zu den beiden vorgeschlagenen Umsetzungsideen erhalten, ohne dass es einen klaren Konsens für eine der beiden Varianten gab. Hier sind einige Zitate aus der Diskussionsseite:

• Für kleine Wikis halte ich den IP-basierten Ansatz für besser, weil es unwahrscheinlich ist, dass zwei anonyme Nutzer dieselbe IP haben, und für einen Vandalen ist es schwieriger, seine IP zu ändern als Cookies zu löschen.

• Das Session-basierte System scheint besser zu sein und würde es einfacher machen, mit anonymen Autor/in zu kommunizieren. Ich bin Administrator in der englischen Wikipedia und meine Hauptinteraktion mit IP-Autoren/innen besteht darin, sie zurückzuweisen und vor Vandalismus zu warnen. In einigen Fällen habe ich mir in letzter Zeit nicht einmal die Mühe gemacht, eine Warnung zu schreiben, da es unwahrscheinlich ist, dass die richtige Person sie erhält. In einem Fall habe ich versucht, mit mehreren IP-Adressen über eine vorgeschlagene Änderung zu sprechen, und es war nicht klar, ob es sich um dieselbe Person handelte.

• Als Admin der deutschsprachigen Wikipedia bevorzuge ich von den beiden hier beschriebenen Wegen (IP-basierte Identität vs. Session-basierte Identität) eindeutig den IP-basierten Ansatz. Es ist einfach zu einfach, den Datenschutzmodus eines Browsers zu nutzen oder die Cookies zu löschen (ich mache das selbst ständig); das Ändern deiner IP-Adresse erfordert zumindest etwas mehr Aufwand, und wir haben bereits eine Richtlinie gegen die Nutzung offener Proxys. Ich stimme Beland zu, dass der Session-basierte Identitätsansatz die Kommunikation mit wohlmeinenden, nicht registrierten Autor/inn/en wahrscheinlich einfacher machen könnte, aber er scheint einfach nicht robust genug zu sein.

• Ich bevorzuge den Session-basierten Ansatz. Er bietet mehr Möglichkeiten, um legitime anonyme Autor/innen zu identifizieren und mit ihnen zu kommunizieren. Gleichzeitig brauchen wir aber auch Missbrauchsfilteroptionen, um mehrere neue Sessions von einer einzigen IP zu identifizieren. Diese könnten legitim sein (z. B. von einer Schule), repräsentieren aber höchstwahrscheinlich Missbrauch oder Bot-Aktivitäten. Eine Funktion, die ich noch nicht erwähnt habe. Wenn ein Session-Benutzer ein Konto erstellen möchte, sollte die bestehende Session-ID standardmäßig in den neuen Namen seiner Wahl umbenannt werden. Wir müssen in der Lage sein, den neu benannten Benutzer zu sehen und/oder mit seinen früheren Session-Aktivitäten in Verbindung zu bringen.

• Ich tendiere zu IP-basierten Identitäten, auch wenn sie verschlüsselt sind, da Cookies komplizierter zu handhaben sind und es sehr lästig ist, immer wieder ihre lästigen Pop-ups zu schließen (in Europa sehr üblich). Ich muss erwähnen, dass ich es vorziehe, dass man Wikipedia bis heute ohne Cookies nutzen kann, es sei denn, man will sich zum Bearbeiten mit seinem Accountnamen anmelden.

• Die Möglichkeit, zusätzlich zur bestehenden IP+Session-Sperre auch rein Session-basierte Sperren durchzuführen, wäre eine interessante Erweiterung. Auch die Möglichkeit, mit IPv6-Nutzern über ihre Session zu kommunizieren, anstatt über ihre sich ständig ändernde IP-Adresse, wäre ein Vorteil.

Zusammenfassend lässt sich sagen, dass das Hauptargument gegen den sitzungsbasierten Ansatz war, dass Cookies leicht loszuwerden sind und die Nutzer/innen ihre Identität sehr leicht ändern können.

Und die Hauptargumente gegen den IP-basierten Ansatz waren:

• Die Verschlüsselungsmethode kann kompromittiert werden, wodurch die IP-Adressen selbst kompromittiert werden.
• Dieser Ansatz bietet nicht den Vorteil einer verbesserten Kommunikation mit den nicht registrierten Autor/innen.
• Sie ermöglicht keine Session-basierte Sperrung (zusätzlich zur IP-basierten Sperrung).

In Anbetracht der obigen Ausführungen und der Diskussionen mit unserem technischen Team über die Machbarkeit und die weitreichenden Auswirkungen dieser Implementierung haben wir uns für den Session-basierten Ansatz entschieden, mit einigen wichtigen Ergänzungen, um das Problem zu lösen, dass Nutzer/innen ihre Cookies löschen und ihre Identität ändern. Wenn eine Nutzerin oder ein Nutzer wiederholt ihren oder seinen Accountnamen ändert, wird es möglich sein, ihre oder seine Identitäten anhand zusätzlicher Informationen in der Benutzeroberfläche zu verknüpfen. Wir arbeiten noch an den Details, wie das funktionieren wird - aber es wird ähnlich funktionieren wie die Erkennung von Sockenpuppen (mit einem gewissen Grad an Automatisierung).

Wir arbeiten noch an vielen technischen Details und werden in Kürze ein weiteres Update mit genaueren Angaben für euch haben. Dazu gehören die LTA-Dokumentation, die Kommunikation über IPs, AbuseFilters, Wikis von Drittanbietern, Gadgets, User-Skripte, WMF Cloud Tools, Einschränkungen für IP-Viewer-Rechte usw. Wir freuen uns über deinen Beitrag und begrüßen jedes Feedback, das du uns auf der Diskussionsseite geben kannst.

<span id="9. Dezember 2021:_IP_Masking_and_changes_to_workflows">

9. Dezember 2021: IP-Maskierung und Änderungen der Arbeitsweisen

Wir haben zwei verschiedenen Ansätze für die IP-Maskierung diskutiert, die wir in Betracht ziehen. In der Folge haben wir uns ein paar verschiedene Arbeitsweisen ausgedacht und wie sie sich mit den beiden unterschiedlichen Implementierungen verändern würden. Hinweis: In beiden Alternativen werden Admins, Stewards, Checkuser und IP-Viewer in der Lage sein, IPs zur Vandalismusbekämpfung auf Seiten wie "Letzte Änderungen" und "Historie" im Klartext zu lesen.

Bearbeitungserfahrung für nicht registrierte Autoren

Aktuelles Verhalten: Derzeit können nicht registrierte Autoren bearbeiten, ohne eingeloggt zu sein (in den meisten Wikis). Bevor sie die Bearbeitung vornehmen, sehen sie ein Banner, das ihnen mitteilt, dass ihre IP-Adresse öffentlich aufgezeichnet und auf Dauer veröffentlicht wird.

IP-basierte Identität: Nicht registrierte Autoren können wie bisher Inhalte bearbeiten. Bevor sie die Bearbeitung vornehmen, sehen sie eine Nachricht, die ihnen mitteilt, dass ihre Bearbeitungen einer verschlüsselten Version ihrer IP-Adresse zugeordnet werden. Die IP-Adresse selbst ist für Administratoren und Sichter sichtbar. Sie wird für einen begrenzten Zeitraum aufbewahrt.

Sitzungsbasierte Identität: Dies ist ähnlich wie oben, mit der Ausnahme, dass den Autoren mitgeteilt wird, dass ihre Bearbeitungen einem automatisch generierten Benutzernamen zugeordnet werden.

• 
  Screenshot einer IP-basierten Identität
• 
  Screenshot einer sitzungsbasierten Identität

Kommunikation über nicht registrierte Autoren

Aktuelles Verhalten: Nicht registrierte Autoren werden über ihre IP-Adresse angesprochen oder, wenn sie bekannte Vandalen sind, werden sie oft aufgrund ihres Verhaltens benannt.

IP-basierte Identität: Sichter und Administratoren können nicht öffentlich auf IP-Adressen verweisen, jedoch auf ihre verschlüsselte IP-Adresse oder den Namen des Langzeit-Vandalen. Sie können die IP mit anderen teilen, die Zugriff darauf haben.

Sitzungsbasierte Identität: Sichter und Administratoren können IP-Adressen nicht öffentlich nennen, wohl aber die automatisch generierten Benutzernamen. Sie können die IP-Adresse mit anderen teilen, die Zugriff darauf haben. Dies kann helfen, einen bestimmten Nutzer zu identifizieren, aber es kann auch verwirrend sein, wenn hinter dem Benutzernamen mehrere IPs stehen, ähnlich wie heute verschiedene Personen hinter einer IP stehen können. Um diese Bedenken auszuräumen, bauen wir ein Tool, das Informationen über all die verschiedenen IP-Adressen anzeigen kann, von denen aus ein Autor aktiv ist.

Diskussionsseitenerfahrung für nicht registrierte Autoren

Aktuelles Verhalten: Ein nicht-registrierter Autor kann Nachrichten auf der Diskussionsseite seiner IP erhalten. Sobald sich die IP-Adresse des Autors ändert, erhält er Nachrichten auf der Diskussionsseite der neuen IP-Adresse. Dies spaltet Gespräche und macht es schwierig, mit einem bestimmten nicht-registrierten Autor in Kontakt zu bleiben.

IP-basierte Identität: In dieser Implementierung bleibt das Verhalten gleich wie aktuell. Nicht-registrierte Autoren erhalten Nachrichten auf ihren verschlüsselten IP-Diskussionsseiten und sobald sich ihre IP ändert, ändert sich auch ihre zugehörige Diskussionsseite.

Sitzungsbasierte Identität: In dieser Implementierung erhalten nicht registrierte Autoren Nachrichten auf einer Diskussionsseite, die mit einem Cookie in ihrem Browser verknüpft ist. Auch wenn sich ihre IP-Adresse ändert, können sie weiterhin Nachrichten auf ihrer Diskussionsseite empfangen. Wenn ihr Browser-Cookie gelöscht wird, verlieren sie jedoch ihre Sitzungsidentität und erhalten ein neues Cookie und eine damit verbundene neue Diskussionsseite. Da sich IPs häufiger ändern als Cookies, ist es wahrscheinlich, dass viele Benutzer eine semipermanente Diskussionsseite erhalten, es sei denn, sie wollen es ausdrücklich. Ein weiterer zu beachtender Vorteil ist, dass Nachrichten auf der Diskussionsseite in keinem Fall mehr beim falschen Empfänger landen.

Benachrichtigung auf der Diskussionsseite

Sperren nicht registrierter Autoren

Aktuelle Handlungsweise: Ein Admin kann eine IP-Adresse oder einen IP-Bereich direkt sperren. Darüber hinaus kann er eine automatische Sperre anlegen, die ein Cookie im Browser des Benutzers speichert, das diesen an der Bearbeitung hindert, selbst wenn er die IP-Adresse ändert. Diese Funktionalität wurde vor einigen Jahren eingeführt.

IP-basierte Identität: Das Verhalten ändert sich nicht. IPs sind standardmäßig maskiert, aber Benutzer mit den entsprechenden Berechtigungen können darauf zugreifen.

Sitzungsbasierte Identität: Diese Implementierung ermöglicht es uns, das aktuelle Verhalten der Sperre von IP-Adressen beizubehalten. Es ermöglicht uns auch, nur Cookie-basierte Sperrungen durchzuführen. Dies kann dann hilfreich sein, wenn Personen Geräte gemeinsam nutzen (wie in einer Bibliothek oder einem Internetkaffee) und das Sperren der IP-Adresse oder des IP-Adressbereichs unnötige Kollateralschäden verursachen würde. Dies funktioniert allerdings nicht, wenn sich die Vandalen auskennen und wissen, wie sie Cookie-basierte Sperren umgehen können. <span id="Oktober 2021:_IP_Masking_Implementation_Approaches_FAQ">

Oktober 2021: IP-Maskierungs-Implementierungsansätze FAQ

Diese FAQs helfen bei der Beantwortung einiger möglicher Fragen, die die Community zu den verschiedenen Implementierungsansätzen haben wird, die wir für die IP-Maskierung verwenden können, und wie sich jeder von ihnen auf die Community auswirkt.

F: Wer kann nach der Implementierung der IP-Maskierung IP-Adressen sehen?

A: Checkuser, Stewards und Admins können die vollständigen IP-Adressen sehen, indem sie sich für eine Präferenz entscheiden, mit der sie erklären, die IP-Adresse insbesondere nicht an andere weiterzugeben, die keinen Zugriff auf diese Information haben.

Vandalismus bekämpfende Autoren, die von der Community überprüft worden sind, können das Recht erhalten, IP-Adressen einzusehen, um ihre Arbeit fortsetzen zu können. Dieses Benutzerrecht wird von der Community wie andere Benutzerrechte erteilt und erfordert eine Mindestanzahl von Bearbeitungen und Bearbeitungstagen.

Alle Benutzer deren Konten bereits mit einer Mindestdauer bestehen und eine (noch festzulegende) Mindestanzahl von Änderungen vorweisen können, können ohne Erlaubnis auf teilweise demaskierte IPs zugreifen. Dies bedeutet, dass eine IP-Adresse mit ihren End-Oktett(en) – den letzten Teilen der IP-Adresse – verborgen erscheint. Dies wird über eine Einstellung zugänglich sein, mit der sie erklären, sie nicht an andere weiterzugeben, die keinen Zugriff auf diese Information haben.

Alle anderen Benutzer können nicht auf IP-Adressen von nicht registrierten Benutzern zugreifen.

F: Welche Möglichkeiten der technischen Umsetzung existieren?

A: In den letzten Wochen haben wir mehrere Diskussionen über die technischen Möglichkeiten geführt, um unser Ziel der IP-Maskierung zu erreichen und gleichzeitig die Auswirkungen auf unsere Autoren und Leser zu minimieren. Wir haben Feedback von verschiedenen Teams eingeholt und unterschiedliche Perspektiven erhalten. Unten stehen die beiden wichtigsten Varianten.

• IP-basierte Identität: Bei diesem Ansatz behalten wir alles beim Alten, ersetzen jedoch vorhandene IP-Adressen durch eine gehashte Version von IPs. Dadurch bleiben viele unserer bestehenden Arbeitsabläufe erhalten, bieten aber keine neuen Vorteile.
• Sitzungsbasierte Identität: Bei diesem Ansatz erstellen wir eine Identität für die nicht registrierten Autoren, die auf einem Browser-Cookie basieren, das ihren Gerätebrowser identifiziert. Das Cookie bleibt auch dann bestehen, wenn sich ihre IP-Adresse ändert, sodass ihre Sitzung nicht beendet wird.

F: Wie funktioniert die Variante IP-basierte Identität?

A: Derzeit werden nicht registrierte Autoren anhand ihrer IP-Adressen identifiziert. Dieses Modell hat sich für unsere Projekte seit vielen Jahren bewährt. Benutzer, die sich mit IP-Adressen gut auskennen, wissen, dass eine einzelne IP-Adresse von mehreren verschiedenen Benutzern verwendet werden kann, je nachdem, wie dynamisch diese IP-Adresse ist. Dies gilt eher für IPv6-IP-Adressen als für IPv4.

Ein nicht registrierter Benutzer kann auch IP-Adressen ändern, wenn er von einem anderen Standort aus editiert oder Änderungen bearbeitet.

Wenn wir die IP-basierte Identitätslösung für eine IP-Maskierung verfolgen, würden wir die heutige Funktionsweise von IP-Adressen erhalten, indem wir sie einfach mit einer verschlüsselten Kennung maskieren. Diese Lösung speichert die IPs getrennt und wahrt die Privatsphäre der Benutzer. Beispielsweise kann ein nicht registrierter Benutzer wie Benutzer:192.168.1.2 als Benutzer:ca1f46 erscheinen.

Vorteile dieses Ansatzes: Bewahrt bestehende Workflows und Modelle mit minimaler Unterbrechung

Nachteile dieses Ansatzes: Bietet keine Vorteile in einer Welt, die sich schnell in Richtung dynamischen/weniger nützlichen IP-Adressen bewegt

F: Wie funktioniert die Variante sitzungsbasierte Identität?

A: Diese Variante Pfad besteht darin, eine neue Identität für nicht registrierte Autoren – basierend auf einem in ihrem Browser platzierten Cookie – zu erstellen. Bei diesem Lösungsansatz gibt es einen automatisch generierten Benutzernamen, dem seine Bearbeitungen und Aktionen zugeordnet werden. Beispiel: einem Benutzer:192.168.1.2 könnte der Benutzername Benutzer:Anon3406 vergeben werden.

Bei diesem Ansatz bleibt die Sitzung des Benutzers so lange bestehen, wie er das Cookie hat, auch wenn er die IP-Adresse ändert.

Vorteile dieses Ansatzes:

• Bindet die Benutzeridentität an den Browser und bietet gleichzeitig eine dauerhaftere Möglichkeit, mit ihm zu kommunizieren.
• Die Benutzeridentität ändert sich nicht bei einer Änderung der IP-Adresse.
• Dieser Ansatz kann nicht registrierten Autoren die Möglichkeit bieten, auf bestimmte Einstellungen zuzugreifen, die derzeit nur registrierten Benutzern zur Verfügung stehen.
• Dieser Ansatz kann nicht registrierten Autoren die Möglichkeit bieten, ihr nicht registriertes Benutzerkonto in ein registriertes Benutzerkonto umzuwandeln und gleichzeitig ihre Bearbeitungshistorie zu behalten.

Nachteile dieses Ansatzes:

• Signifikante Änderung im aktuellen Modell gegenüber einem nicht registrierter Autor.
• Die Identität des nicht registrierten Bearbeiters bleibt nur so lange bestehen, wie der Browser-Cookie gespeichert wird.
• Vandalen im Datenschutzmodus oder die ihre Cookies löschen, würden eine neue Identität bekommen, ohne dass sich jedoch ihre IP ändert.
• Erfordert möglicherweise ein Überdenken einiger Community-Workflows und -Tools

F: Hat die Stiftung einen bevorzugten Weg oder Ansatz?

A: Unser bevorzugter Ansatz wird die sitzungsbasierte Identität sein, da dies viele Möglichkeiten für die Zukunft eröffnet. Wir könnten Kommunikationsprobleme ansprechen, die wir seit zwanzig Jahren haben. Während jemand sein Cookie löschen könnte, um eine neue Identität zu erhalten, wäre die IP weiterhin für alle aktiven Vandalenbekämpfer mit dem neuen Benutzerrecht sichtbar. Wir erkennen natürlich an, dass das Löschen eines Cookies einfacher ist, als der Wechsel einer IP und beachten die Auswirkungen, die es haben würde.

<span id="10. Juni 2021:_Proposal_for_sharing_IP_addresses_with_those_who_need_access">

10. Juni 2021: Vorschlag für die gemeinsame Nutzung von IP-Adressen durch diejenigen, die Zugriff benötigen

Hallo allerseits. Seit unserem letzten Update zu diesem Projekt sind einige Monate vergangen. Wir haben uns diese Zeit genommen, um mit vielen Leuten zu sprechen – in der Redaktions-Community und innerhalb der Foundation. Wir haben sorgfältig alle Bedenken abgewogen, die in unseren Diskussionen mit erfahrenen Community-Mitgliedern über die Auswirkungen auf die Anti-Vandalismus-Bemühungen in unseren Projekten geäußert wurden. Wir haben auch von einer beträchtlichen Anzahl von Personen gehört, die diesen Vorschlag als einen Schritt zur Verbesserung der Privatsphäre nicht registrierter Autoren und zur Verringerung der rechtlichen Bedrohung durch die weltweite Offenlegung von IPs für unsere Projekte unterstützen.

Als wir in der Vergangenheit über dieses Projekt sprachen, hatten wir keine klare Vorstellung davon, wie dieses Projekt aussehen wird. Unsere Absicht war zu verstehen, wie hilfreich IP-Adressen für unsere Gemeinschaften sind. Seitdem haben wir viel Feedback zu diesem Thema aus einer Reihe von Gesprächen in verschiedenen Sprachen und in verschiedenen Communities erhalten. Wir sind allen Community-Mitgliedern sehr dankbar, die sich die Zeit genommen haben, uns darüber zu berichten, wie die Moderation in ihren Wikis oder in ihrer spezifischen Cross-Wiki-Umgebung funktioniert.

Wir haben jetzt einen konkreteren Vorschlag für dieses Projekt, von dem wir hoffen, dass der Großteil der Anti-Vandalismus-Arbeit unbeirrt durchgeführt wird und gleichzeitig der Zugriff auf IP-Adressen von denjenigen Personen eingeschränkt wird, die sie nicht sehen müssen. Ich möchte das Wort „Vorschlag“ betonen, weil es in keinster Weise eine endgültige Entscheidung darstellt, was letztlich geschehen wird. Wir möchten Dein Feedback zu dieser Idee einholen – Was denkst Du, wird funktionieren? Was denkst du wird nicht funktionieren? Welche anderen Ideen können den Vorschlag verbessern?

Diese Ideen haben wir in mehreren Gesprächen mit erfahrenen Community-Mitgliedern entwickelt und in Zusammenarbeit mit unserer Rechtsabteilung weiterentwickelt. Hier ist der Entwurf:

• Checkuser, Stewards und Administratoren sollten in der Lage sein, die vollständigen IP-Adressen zu sehen, indem sie sich für eine Einstellung entscheiden, in der sie zustimmen, sie nicht an andere weiterzugeben, die keinen Zugriff auf diese Informationen haben.
• Autor/inn/en, die sich an Anti-Vandalismus-Aktivitäten beteiligen, die von der Community überprüft wurden, können ein Recht auf IP-Adressen erhalten, um ihre Arbeit fortzusetzen. Dies könnte ähnlich gehandhabt werden wie die Adminschaft in unseren Projekten. Die Zustimmung der Community ist wichtig, um sicherzustellen, dass nur Autor/inn/en, die diesen Zugang wirklich brauchen, ihn auch bekommen. Die Autor/inn/en müssen ein Konto haben, das eine bestimmte Zeit seit der Registrierung (die Schwelle muss noch festgelegt werden) und eine bestimmte Anzahl von Bearbeitungen (die Anzahl muss noch festgelegt werden) aufweist.
• Alle Nutzer/innen mit Konten, die einen bestimmten Schwellenwert in Bezug auf die Zeit seit der Registrierung (der Schwellenwert wird noch festgelegt) und die Anzahl der Bearbeitungen (die Anzahl wird noch festgelegt) erfüllen, können ohne Genehmigung auf teilweise unmaskierte IPs zugreifen. Das bedeutet, dass eine IP-Adresse mit dem/den letzten Oktett(en) - dem/den letzten Teil(en) - versteckt angezeigt wird. Dies wird über eine Einstellung zugänglich sein, in der du zustimmst, sie nicht mit anderen zu teilen, die keinen Zugriff auf diese Informationen haben.
• Alle anderen Benutzer können nicht auf IP-Adressen für nicht registrierte Benutzer zugreifen.

Der Zugriff auf die IP-Adresse wird protokolliert, damit im Bedarfsfall eine entsprechende Überprüfung erfolgen kann. Dies ist vergleichbar mit dem Protokoll, das wir für den Zugriff von Benutzern auf private Daten führen. Auf diese Weise hoffen wir, das Bedürfnis nach Privatsphäre mit dem Bedürfnis der Gemeinschaften nach Zugang zu Informationen in Einklang zu bringen, um Spam, Vandalismus und Belästigungen zu bekämpfen. Wir möchten die Informationen an diejenigen weitergeben, die sie benötigen, aber wir brauchen einen Prozess, wir benötigen ein Opt-In, damit sie nur diejenigen mit einem tatsächlichen Bedarf sehen und die Zugriffe protokolliert werden.

Wir würden gerne Deine Meinung zu diesem vorgeschlagenen Ansatz hören. Bitte gib uns Dein Feedback auf der talk-page (Diskussionsseite).

• Was denkst du wird funktionieren?
• Was denkst du wird nicht funktionieren?
• Welche anderen Ideen können dies verbessern?