Bearbeiten als IP: Verbesserung der Privatsphäre und Verminderung des Missbrauchs
IP Info feature New! • Other related tools
IP editing restriction study
Was ist die Maskierung einer IP und warum maskiert die Wikimedia Foundation IPs?
IP masking hides the IP addresses of unregistered editors on Wikimedia projects, fully or partially, from everyone except those who need access to fight spam, vandalism, harassment and disinformation.
Currently, anyone can edit Wikimedia wikis without a Wikimedia account or without logging in. MediaWiki, the software behind Wikimedia projects, will record and publish your IP address in its public log. Anyone seeking your IP address will find it.
Wikimedia projects have a good reason for storing and publishing IP addresses: they play a critical role in keeping vandalism and harassment off our wikis.
However, your IP address can tell where you are editing from and can be used to identify you or your device. This is of particular concern if you are editing from a territory where our wikis are deemed controversial. Publishing your IP address may allow others to locate you.
With changes to privacy laws and standards (e.g., the General Data Protection Regulation and the global conversation about privacy that it started), the Wikimedia Foundation Legal team has decided to protect user privacy by hiding IPs from the general public. However, we will continue to give access to users who need to see the addresses to protect the wikis.
We're aware that this change will impact current anti-abuse workflows. We are committed to developing tools or maintaining access to tools that can identify and block vandals, sock puppets, editors with conflicts of interest and other bad actors after IPs are masked.
Ergebnisse und technische Neuigkeiten
Refocusing work on IP Masking (16 February 2023)
Hi all. We’re officially refocusing our work on the core IP Masking project, now that we have completed the first phase on IP Info Feature and other related projects. We are moving forward with technical planning to understand what will need to change when IP Masking goes into effect. We will be reaching out to our technical volunteers to help evaluate changes and migrate tools, as needed. Some of this planning work has already started on Phabricator, and you may reach out to us there if you have questions about specific tasks.
I will follow this up with another post shortly to share an outline of the MVP (Minimum Viable Product) we have landed on. This MVP is based on the conversations we have had with the community in the past, through this page and other mediums. Please feel free to peruse those previous conversations and read through the past updates on this page. If you have questions or concerns, you can reach out to us on the talk page.
Implementierungsstrategie und die nächsten Schritte (25. Februar 2022)
Hello all. We have an update on the IP Masking implementation strategy.
First off, thank you to everyone who arrived on this page and offered their feedback. We heard from a lot of you about how this page is not easy to read and we are working on fixing that. We genuinely want to thank you for taking the time to go through the information here and on the talk page. We took every comment on the talk page into consideration before the decision about the implementation plan was made.
We want to preface this also by saying that there are still a lot of open questions. There is a long road ahead of us on this project and we would like you to voice your opinion in more of these discussions as they come up. If you haven’t already, please go through this post about who will continue to have IP address access before reading further.
We received mixed feedback from the community about the two proposed implementation ideas without a clear consensus either way. Here are some quotes taken from the talk page:
- For small wikis, I think the IP based approach is better because it is unlikely that two anonymous users will have the same IP, and for a vandal modifying its Ip is most difficult that erasing cookies.
- The session-based system does seem better, and would make it easier to communicate with anonymous editors. I'm an admin on English Wikipedia, and my main interaction with IP editors is reverting and warning them against vandalism. In several cases recently I haven't even bothered posting a warning, since it seems unlikely the right person would receive it. In one case I was trying to have a conversation about some proposed change, and I was talking to several different IP addresses, and it was unclear that it was actually the same person, and I had to keep asking them about that.
- As an admin in German-language Wikipedia, of the two paths described here (IP based identity vs. session-based identity) I clearly prefer the IP based approach. It's just too easy to use a browser's privacy mode or to clear the cookies (I'm doing it myself all the time); changing your IP address at least requires a bit more effort, and we have already a policy against using open proxies in place. I agree with Beland that the session-based identity approach could probably make communication with well-meaning unregistered editors easier, but it just doesn't seem robust enough.
- I prefer the session-based approach. It provides more value in being able to identify and communicate with legitimate anonymous editors. However, at the same time, we need abuse filter options to be able to identify multiple new sessions from a single IP. These could be legitimate (from a school, for example), but will most likely represent abuse or bot activity. One feature I haven't seen mentioned yet. When a session user wants to create an account, it should default to renaming the existing session ID to the new name of their choice. We need to be able to see and/or associate the new named user with their previous session activity.
- I am leaning towards the IP-based identities, even if encrypted, as cookies seem more complicated to deal with and very bothersome to keep shutting their annoying pop-ups (very standard in Europe). I have to mention that I prefer that till this day, one could use Wikipedia without cookies, unless he wants to log in to edit with his username.
- The ability to perform purely session-based blocks in addition to the existing IP+session blocking would be an interesting upgrade. Being able to communicate with IPv6 users through their session instead of their repeatedly changing IP address would also be a benefit.
In summary, the main argument against the session-based approach was that cookies are easy to get rid of and the user may change their identity very easily.
And the main arguments against the IP-based approach were:
- the encryption method can be compromised, hence compromising the IP addresses themselves
- this approach does not provided the benefit of improved communication with the unregistered editors
- does not allow for session-based blocking (in addition to IP based blocking)
In light of the above and the discussions with our technical team about the feasibility and wide-ranging implications of this implementation, we have decided to go with the session-based approach with some important additions to address the problem of users deleting their cookies and changing their identity. If a user repeatedly changes their username, it will be possible to link their identities by looking at additional information in the interface. We are still working out the details of how this will work – but it will be similar to how sockpuppet detection works (with some automation).
We are working out a lot of the technical details still and will have another update for you shortly with more specifics. This includes LTA documentation, communication about IPs, AbuseFilters, third-party wikis, gadgets, user-scripts, WMF cloud tools, restrictions for IP-viewer rights etc. We appreciate your input and welcome any feedback you may have for us on the talk page.
IP-Maskierung und Änderungen der Arbeitsweisen
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.
.png)
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.
=== IP-Maskierung-Implementierungsansätze (FAQ) ===
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.
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.
- Autoren, die an Anti-Vandalismus-Aktivitäten teilnehmen, die von der Community überprüft werden, können das Recht erhalten, IP-Adressen zu sehen, um ihre Arbeit fortzusetzen. Dies könnte in ähnlicher Weise wie die Verwaltung unserer Projekte abgewickelt werden. Die Community-Genehmigung ist wichtig, um sicherzustellen, dass sie nur Autoren, die diesen Zugriff wirklich benötigen, erhalten können. Die Autoren müssen einen Account haben, der mindestens ein Jahr alt ist und mindestens 500 Bearbeitungen enthält.
- Alle Benutzer mit Konten, die älter als ein Jahr sind und mindestens 500 Änderungen aufweisen, können ohne Erlaubnis auf teilweise demaskierte IPs zugreifen. Dies bedeutet, dass eine IP-Adresse mit ihren End-Oktett(en) – die IP-Adresse wird vor der Speicherung um das letzte Oktett gekürzt (IP-Maskierung) – verborgen erscheint. Dies wird über eine Einstellung zugänglich sein, bei der sie zustimmen, sie nicht an Dritte weiterzugeben, die normalerweise 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?
Daten zur portugiesischen Wikipedia, die IP-Bearbeitungen deaktiviert
Portuguese Wikipedia’s metrics following restriction
Insgesamt stellt der Bericht den Wandel positiv dar. Wir haben in dem Zeitraum, in dem diese Metriken erfasst wurden, keine nennenswerten Störungen festgestellt. Vor diesem Hintergrund werden wir jetzt ermutigt, ein Experiment mit zwei weiteren Projekten durchzuführen, um zu sehen, ob wir ähnliche Auswirkungen beobachten. Alle Projekte sind auf ihre Weise einzigartig und was für die portugiesische Wikipedia gilt, gilt möglicherweise nicht für ein anderes Projekt. Wir möchten ein zeitlich begrenztes Experiment mit zwei Projekten durchführen, bei denen eine Registrierung zum Bearbeiten erforderlich ist. Wir schätzen, dass es ungefähr 8 Monate dauern wird, bis wir genügend Daten gesammelt haben, um signifikante Änderungen zu erkennen. Nach Ablauf dieses Zeitraums werden wir für die Bearbeitung der Daten während der Datenanalyse keine Registrierung mehr verlangen. Nach der Veröffentlichung der Daten kann die Community selbst entscheiden, ob sie die unregistrierte Bearbeitung des Projekts weiterhin verbieten möchte.
Wir nennen dies das Login Required Experiment (Experiment das eine Anmeldung erfordert). Auf dieser Seite findest Du weitere Details sowie eine Zeitleiste. Bitte verwende diese Seite und die zugehörige Diskussionsseite, um dies weiter zu besprechen.
Portuguese Wikipedia IP editing restriction
Werkzeuge
Tool development
Wir haben bereits über Ideen für diese Tools gesprochen, und ich werde im Folgenden ein kurzes Update dazu geben. Beachte, dass bei diesen Tools in den letzten Monaten nur langsam Fortschritte erzielt wurden, da unser Team working on overhauling SecurePoll (an der Überarbeitung von SecurePoll) arbeitet, um die Anforderungen an die bevorstehenden WMF-Vorstandswahlen zu erfüllen.
IP-Info-Funktion
.png)
Wir bauen ein Tool, das wichtige Informationen zu einer IP-Adresse anzeigt, die häufig bei Ermittlungen gesucht wird. Normalerweise verlassen sich Sichter, Admins und Checkuser auf externe Webseiten, um diese Informationen zu erhalten. Wir hoffen, Dir diesen Prozess zu erleichtern, indem wir Informationen von zuverlässigen IP-Anbietern in unsere Webseiten integrieren. Wir haben vor kurzem einen Prototyp gebaut und eine Runde von Benutzertests durchgeführt, um unseren Ansatz zu validieren. Wir haben festgestellt, dass eine Mehrheit der Autoren im Interview-Set das Tool hilfreich fand und angab, es in Zukunft verwenden zu wollen. Es gibt ein update on the project page (Update auf der Projektseite), auf das ich Dich aufmerksam machen möchte. Wichtige Fragen, zu denen wir gerne Dein Feedback auf feedback on the project talk page (Diskussionsseite) hätten:
- Wenn Du nach Informationen über eine IP suchst, nach welchen genauen Informationen suchst Du? Auf welcher Seite suchst Du meistens nach diesen Informationen?
- Welche IP-Informationen findest Du am nützlichsten?
- Welche Art von IP-Informationen könnten Deiner Meinung nach unsere anonymen Autoren gefährden, wenn sie weitergegeben würden?
Editor-Matching-Funktion
Dieses Projekt wurde in früheren Gesprächen auch als "Sockenpuppen-Erkennung" bezeichnet. Wir versuchen einen passenden Namen dafür zu finden, der auch für Leute verständlich ist, die das Wort Sockenpuppen nicht verstehen.
Wir befinden uns in der Anfangsphase dieses Projekts. Wikimedia Foundation Research has a project, das bei der Erkennung helfen könnte, wenn zwei Autoren ein ähnliches Bearbeitungsverhalten zeigen. Dies wird dazu beitragen, verschiedene nicht registrierte Editoren zu verbinden, wenn sie unter verschiedenen automatisch generierten Konto-Benutzernamen bearbeiten. Wir haben viel Unterstützung für dieses Projekt erfahren, als wir vor einem Jahr anfingen, darüber zu diskutieren. Wir haben auch von den Risiken gehört, eine solche Funktion zu entwickeln. Wir planen, in naher Zukunft einen Prototyp zu bauen und mit der Community zu teilen. Es gibt eine wenig genutzte project page für dieses Projekt. Wir hoffen, bald ein Update dafür zu haben. Deine Gedanken zu diesem Projekt sind auf der project talk page sehr willkommen.
Wir haben uns entschieden, uns zuerst darauf zu fokussieren, das CheckUser-Tool flexibler, mächtiger und einfacher bedienbar zu machen. Es ist ein wichtiges Werkzeug, dass dazu dient, in vielen unserer Projekte böswillige Akteure aufzuspüren und zu sperren (insbesondere Langzeittäter). Das CheckUser-Tool wurde viele Jahre schlecht verwaltet. Es wirkt darum veraltet und es fehlen notwendige Funktionen.
Wir haben auch einen Anstieg der Anzahl der Benutzer erwartet, die sich für die Aufgabe als CheckUser in unseren Projekten entscheiden, sobald die IP-Maskierung in Kraft tritt. Dies verstärkte die Notwendigkeit einer besseren und einfacheren CheckUser-Erfahrung für unsere Benutzer. Vor diesem Hintergrund hat das Team von Anti-Harassment Tools im vergangenen Jahr daran gearbeitet, das CheckUser-Tool zu verbessern – und es viel effizienter und benutzerfreundlicher zu machen. Bei dieser Arbeit wurden auch viele ausstehende Funktionsanfragen der Community berücksichtigt. Wir haben uns im Laufe dieses Projekts ständig mit CheckUsern und Stewards beraten und unser Bestes gegeben, um ihre Erwartungen zu erfüllen. Das neue Feature soll im Oktober 2020 für alle Projekte live gehen.
Das nächste Feature, an dem wir arbeiten, ist IP-Info. Wir haben uns für dieses Projekt nach einer Beratungsrunde zu sechs Wikis entschieden, die uns geholfen hat, die Anwendungsfälle für IP-Adressen in unseren Projekten einzugrenzen. Schon früh wurde deutlich, dass IP-Adressen einige kritische Informationen enthalten, die zur Verfügung gestellt werden müssen, damit sie ihre Aufgaben effektiv erfüllen können. Das Ziel von IP Info ist es daher, schnell und einfach wichtige Informationen über eine IP-Adresse aufzudecken. IP-Adressen liefern wichtige Informationen wie Standort, Organisation, Möglichkeit, ein Tor/VPN-Knoten zu sein, rDNS, aufgeführte Reichweite, um nur einige Beispiele zu nennen. Indem wir dies schnell und einfach zeigen können, ohne dass externe Tools benötigt werden, die nicht jeder verwenden kann, hoffen wir, dass wir Patrouillen ihre Arbeit erleichtern können. Die bereitgestellten Informationen sind auf einem so hohen Level, dass wir sie anzeigen können, ohne den anonymen Benutzer zu gefährden. Gleichzeitig sind es genug Informationen, damit Patrouillen Qualitätsurteile über eine IP-Adresse fällen können.
Nach IP Info werden wir uns auf die Funktion finding similar editors feature (Ähnliche Autoren finden) konzentrieren. Wir werden ein Maschinenlernmodell verwenden, dass mit CheckUsern zusammenarbeitet und mit historischen CheckUser-Daten trainiert wird, um das Nutzerverhalten zu vergleichen und zu markieren, wenn zwei oder mehr Nutzer sich allzu ähnlich zu verhalten scheinen. Das Modell wird berücksichtigen, auf welchen Seiten Nutzer aktiv sind, ihre Schreibstile, Bearbeitungszeiten etc. um Vorhersagen zur Ähnlichkeit zweier Nutzer zu treffen. Wir kommen unserer Sorgfaltspflicht nach, indem wir sicherstellen, dass das Modell so akkurat wie möglich ist.
Wenn es fertig ist, gibt es vieles, was so ein Modell tun kann. In einem ersten Schritt werden wir es verwenden, damit CheckUser Sockenpuppen einfach und ohne viel händischer Arbeit auffinden können. Für die Zukunft können wir darüber nachdenken, wie wir dieses Werkzeug mehr Leuten zur Verfügung stellen können und es verwenden können, um bösartige Sockenpuppenringe und Falschinformationskampagnen aufzuspüren.
Du kannst auf unserer Projektseite für Werkzeuge mehr erfahren und Kommentare hinterlassen.
Forschung
Auf der sozialen Seite stand die Frage zur Diskussion, ob nicht-registrierte Nutzer Bearbeitungen vornehmen dürfen. Derzeit ist die Tendenz, nicht-registrierten Nutzern das Bearbeiten zu erlauben. Die Diskussion dreht sich einerseits um das Bedürfnis Vandalismus Einhalt zu gebieten und andererseits die Möglichkeit des pseudo-anonymen Editierend zu schaffen und die diesbezügliche Hemmschwelle abzubauen. Man geht von einer Voreingenommenheit gegenüber nicht-registrierten Nutzern aus, da sie mit Vandalismus in Verbindung gebracht werden. Das spiegelt sich auch als algorithmische Voreingenommenheit in Werkzeugen wir ORES wider. Zusätzlich gibt es wesentliche Kommunikationsprobleme, wenn man sich an nicht-registrierte Nutzende wenden will. Dies ergibt sich vor allem daraus, dass sie keine Nachrichten erhalten können und es nicht sichergestellt ist, dass auch die richtige Person die Nachrichten liest, die man auf der Diskussionsseite eines IP-Accounts hinterlässt.
Was die potenziellen Auswirkungen der IP-Maskierung betrifft, so wird sie erheblichen Einfluss auf die Arbeitsabläufe der Administratoren haben und kann die Arbeitsbelastung für CheckUser vorübergehend erhöhen. In diesem Fall oder wenn IP-Adressen maskiert werden, müssen wir uns darauf einstellen, dass die Fähigkeit unserer Admins, Vandalismus zu bearbeiten, stark beeinträchtigt wird. Dies kann durch die Bereitstellung von Werkzeugen mit gleichwertiger oder größerer Funktionalität gemildert werden, aber wir sollten mit einer Übergangszeit rechnen, die durch eine reduzierte Effizienz der Admins gekennzeichnet ist. Um die Arbeit unserer Administratoren angemessen zu unterstützen, müssen wir darauf achten, die folgenden Funktionen, die derzeit Informationen über IPs ergeben, beizubehalten oder Alternativen dazu bereitzustellen:
- Effektivität und Sicherheitenabschätzung blockieren
- Möglichkeiten schaffen, Ähnlichkeiten oder Muster unter unregistrierten Benutzern zu erkennen, wie z. B. geografische Ähnlichkeit, bestimmte Institutionen (z. B. wenn von einer Schule oder Universität aus editiert wird)
- Möglichkeiten schaffen, bestimmte Gruppen nicht-registrierter Nutzer anzusprechen, z. B. Vandalen, die wechselnde IPs innerhalb eines bestimmten Bereichs verwenden
- Orts- oder institutionsspezifische Aktionen (nicht unbedingt Sperren); z. B. die Möglichkeit, festzustellen, ob Bearbeitungen von einem offenen Proxy oder einem öffentlichen Ort wie einer Schule oder öffentlichen Bibliothek vorgenommen werden.
Je nachdem, wie wir mit temporären Konten oder Identifikatoren von nicht-registrierte Nutzern umgehen, können wir die Kommunikation mit nicht-registrierten Nutzern verbessern. Die zugrundeliegenden Diskussionen und Bedenken bezüglich des unregistrierten Editierens, des anonymen Vandalismus und der Voreingenommenheit gegenüber nicht-registrierten Nutzenden werden sich wahrscheinlich nicht wesentlich ändern, wenn wir IPs maskieren, vorausgesetzt, wir behalten die Möglichkeit bei, Projekte zu bearbeiten, während sie abgemeldet sind.
- Triaging: Bewertung der Fälle auf Machbarkeit und Komplexität.
- Profiling: Erstellen eines Verhaltensmusters, das die nutzende Person hinter mehreren Konten identifiziert.
- Checking: Untersuchung von IPs und Benutzern mit dem CheckUser-Werkzeug.
- Beurteilung: Abgleich dieser technischen Informationen mit den im Schritt Profiling ermittelten Verhaltensinformationen, um eine endgültige Entscheidung über die zu ergreifenden administrativen Maßnahmen zu treffen.
- Ergebnis: Berichterstattung über das Ergebnis der Untersuchung auf öffentlichen und privaten Plattformen, falls erforderlich, und angemessene Archivierung der Informationen für die zukünftige Verwendung.
Wir haben auch mit Mitarbeitern von Trust and Safety zusammengearbeitet, um ein Gefühl dafür zu bekommen, wie das CheckUser-Werkzeug in die Untersuchungen der Wikimedia Foundation und die Fälle, die an T&S weitergereicht werden, einfließt.
Die häufigsten und offensichtlichen Schwachstellen drehten sich alle um die nicht-intuitive Informationsdarstellung des CheckUser-Tools und die Notwendigkeit, jeden einzelnen Link in einem neuen Tab zu öffnen. Dies führte zu erheblicher Verwirrung, da die Masse der Tabs schnell außer Kontrolle geriet.
Dies führte zu massiver Verwirrung, da die Verbreitung von Tabs schnell außer Kontrolle geriet. Erschwerend kommt hinzu, dass die Informationen, die einem CheckUser angezeigt werden, sehr technisch und auf den ersten Blick nicht leicht zu verstehen sind, was die Nachverfolgung der Registerkarten erschwert. Alle unsere Befragten gaben an, dass sie auf separate Software oder physischen Stift und Papier zurückgegriffen haben, um den Überblick über die Informationen zu behalten.
Wir haben auch einige grundlegende Analysen der Sockenpuppenuntersuchungen der englischsprachigen Wikipedia-Seite durchgeführt, um einige grundlegende Metriken zu erhalten, wie viele Fälle sie bearbeiten, wie viele abgelehnt werden und wie viele Sockenpuppen ein bestimmter Bericht enthält.
In unserer Studie wurde versucht, aus folgenden fünf Wikis Schlüsse zu ziehen:
- Japanische Wikipedia
- Niederländische Wikipedia
- Deutsche Wikipedia
- Chinesische Wikipedia
- Englisches Wikiquote
Sie wurden wegen der der bekannten Einstellungen zu IP-Bearbeitungen, dem Prozentsatz der monatlichen Bearbeitungen, die von IPs vorgenommen wurden, und anderen einzigartigen oder ungewöhnlichen Umständen ausgewählt, mit denen IP-Bearbeitende konfrontiert sind, nämlich die Verwendung der Funktion "Pending Changes" (eine Art "ungesichtete Versionen") und die weit verbreitete Verwendung von Proxies. Die Teilnehmer wurden über offene Aufrufe auf Village Pumps oder dem lokalen Äquivalent rekrutiert. Wo möglich, haben wir auch auf Wiki-Botschaftsseiten gepostet. Leider hatten wir zwar Dolmetscherunterstützung für die Interviews selbst, aber keine Übersetzungsunterstützung für die Botschaften, was möglicherweise für die niedrigen Antwortraten verantwortlich war. Alle Interviews wurden über Zoom durchgeführt, wobei eine protokollierende Person anwesend war.
Die Ergebnisse früherer Studien bestätigend, fanden wir keine systematische oder einheitliche Verwendung von IP-Informationen. Außerdem wurden diese Informationen erst ab einer bestimmten Verdachtschwelle gesucht. Die meisten weiteren Untersuchungen verdächtiger Nutzeraktivitäten beginnen mit öffentlich zugänglichen On-Wiki-Informationen, wie z. B. der Überprüfung früherer lokaler Bearbeitungen, globaler Beiträge oder der Suche nach früheren Sperren.
Präzision und Genauigkeit waren weniger wichtige Eigenschaften für IP-Informationen: Als wir sahen, dass eine ausgewählte IP-Informationsseite drei verschiedene Ergebnisse für den geografischen Standort derselben IP-Adresse lieferte, erwähnte einer unserer Interviewpartner, dass die Präzision des Standorts nicht so wichtig sei wie die Konsistenz. Das heißt, solange eine IP-Adresse konsistent als aus einem Land stammend angezeigt wurde, spielte es weniger eine Rolle, ob sie korrekt oder präzise war. Dies deckt sich mit unserem Verständnis davon, wie IP-Adressinformationen verwendet werden: als eine halbwegs eindeutige Information, die mit einem einzelnen Gerät oder einer einzelnen Person assoziiert wird und die für den Durchschnittsbürger relativ schwer zu fälschen ist. Die Genauigkeit oder Präzision der dem Benutzer zugeordneten Informationen ist weniger wichtig als die Tatsache, dass sie zugeordnet und schwer zu ändern sind.
Unsere Ergebnisse heben einige wichtige Designaspekte für das IP-Info-Werkzeug hervor:
- Liefere auf einen Blick Schlussfolgerungen über Rohdaten
- Decke die wichtigsten Aspekte von IP-Informationen ab:
- Geolokalisierung (wenn möglich auf Stadt- oder Bezirksebene)
- Registrierte Organisation
- Verbindungstyp (hoher Datenverkehr, wie von einem Rechenzentrum oder Mobilfunknetz, gegenüber niedrigem Datenverkehr, wie bei privatem Breitband)
- Proxy-Status als binäres Ja oder Nein
AUs ethischer Sicht wird es wichtig sein, nachweisen zu können, wie alle Maßnahmen zu Stande kamen, und die Ungenauigkeit oder mangelnde Präzision erklären zu können, die mit dem Abrufen von IP-Informationen einhergeht. Obwohl dies für die Patrouilleure, mit denen wir gesprochen haben, kein größeres Problem darstellte, sollten wir bei der Erstellung eines Werkzeugs, das als Grundlage für Administratorentscheidungen dient, darauf achten, dass wir die Grenzen unseres Tools deutlich machen.
Stellungnahme der Rechtsabteilung der Wikimedia Foundation
Updates
Hintergrund
Um zu erklären, wie wir in diesem Stadium angekommen sind, möchten wir kurz zurückblicken. Wikipedia und seine Geschwisterprojekte wurden für die Ewigkeit gebaut. Die Summe allen Wissens zu teilen ist nicht etwas, das in einem Jahr, in zehn Jahren oder in unserem ganzen Leben möglich ist. Aber während die Mission der Communities und der Stiftung langfristig angelegt war, stammen die technischen und Governance-Strukturen, die diese Mission ermöglichen, größtenteils aus der Anfangszeit. Viele dieser Funktionen haben sich bewährt, andere nicht, da sich der Kontext, in dem sie arbeiten, geändert hat. In den letzten 20 Jahren hat sich viel entwickelt: die Art und Weise, wie Gesellschaften das Internet nutzen und damit umgehen, die Vorschriften und Richtlinien, die sich auf den Betrieb von Online-Plattformen auswirken, sowie die Erwartungen der Benutzer an den Umgang einer Website mit ihren Daten.
Insbesondere in den letzten fünf Jahren haben sich Benutzer und Regierungen immer mehr Sorgen um den Online-Datenschutz und die Erhebung, Speicherung, Verarbeitung und Weitergabe personenbezogener Daten gemacht. In vielerlei Hinsicht waren die Projekte dem Rest des Internets voraus: Privatsphäre und Anonymität sind der Schlüssel für die Fähigkeit der Benutzer, kostenloses Wissen zu teilen und zu konsumieren. Die Stiftung sammelt seit langem nur wenige Informationen über Benutzer, benötigt keine E-Mail-Adresse für die Registrierung und hat erkannt, dass IP-Adressen personenbezogene Daten sind (siehe beispielsweise die Version 2014–2018 unserer Datenschutzrichtlinie). In jüngerer Zeit hat sich die Diskussion über den Datenschutz verändert und neue Gesetze und bewährte Verfahren inspiriert: Die General Data Protection Regulation der Europäischen Union, die im Mai 2018 in Kraft getreten ist, hat den Ton für einen globalen Dialog über personenbezogene Daten angegeben und welche Rechte Einzelpersonen haben sollten, um ihre Verwendung zu verstehen und zu kontrollieren. In den letzten Jahren haben sich die Datenschutzgesetze auf der ganzen Welt geändert – sehen Sie sich die Bandbreite der Gespräche, Gesetzesentwürfe und neuen Gesetze beispielsweise in Brasilien, Indien, Japan oder den Vereinigten Staaten an.
Rechtliche Risken
Das Datenschutzteam der Foundation beobachtet ständig diese Entwicklungen, bewertet unsere Praktiken und plant für die Zukunft. Es ist unsere Aufgabe, die Projekte von heute zu betrachten und dann zu evaluieren, wie wir sie auf die rechtlichen und gesellschaftlichen Rahmenbedingungen von morgen vorbereiten können. Vor einigen Jahren haben wir im Rahmen dieser Arbeit festgestellt, dass sich das derzeitige System zur Veröffentlichung von IP-Adressen nicht eingeloggter Autoren ändern sollte. Wir glauben, dass die bisherige Handhabung ein Risiko für Benutzer darstellt, deren Informationen auf diese Weise veröffentlicht werden. Viele rechnen nicht damit – selbst mit den Hinweisen, die erklären, wie die Attribution bei den Projekten funktioniert - weshalb das Datenschutzteam oft von Benutzern kontaktiert wird, die editiert haben und dann überrascht sind, ihre IP-Adresse auf der Verlaufsseite zu sehen. Einige von ihnen befinden sich an Orten, an denen die Projekte umstritten sind, und sie befürchten, dass die Offenlegung ihrer IP-Adresse es ihrer Regierung ermöglichen könnte, sie ins Visier zu nehmen. Wir können vorhersehen, dass unsere derzeit geltenden rechtlichen Rahmenbedingungen und die Veröffentlichung der IP-Adressen heute echte Risiken für die Projekte und die Benutzer darstellen.
Wir haben von mehreren von Euch gehört, dass Ihr genauer wissen möchtet, welche rechtlichen Risiken dieses Projekt inspiriert haben, ob die Foundation derzeit mit rechtlichen Schritten konfrontiert ist, welche Konsequenzen unserer Meinung nach entstehen könnten, wenn wir IP-Adressen nicht maskieren usw. (viele dieser Fragen wurden in der erweiterten Liste am Ende von dieser Abschnitt gesammelt). Es tut uns leid, dass wir keine weiteren Informationen zur Verfügung stellen können, da wir einige Details der Risiken geheim halten müssen. „Privilegiert“ bedeutet, dass ein Anwalt etwas vertraulich behandeln muss, da seine Offenlegung seinem Mandanten schaden könnte. Deshalb wird selten auf Privilegien verzichtet; Es ist ein formales Konzept in den Rechtssystemen mehrerer Länder und existiert aus sehr praktischen Gründen – zum Schutz des Mandanten. Hier könnte der Verzicht auf das Privileg und die Preisgabe dieser Informationen den Projekten und der Stiftung schaden. Im Allgemeinen bemüht sich das Team für Rechtsangelegenheiten, so transparent wie möglich zu sein; Ein wichtiger Teil unserer Rechtsstrategie besteht jedoch darin, jedes Problem von Fall zu Fall anzugehen. Wenn wir öffentlich privilegierte Informationen darüber diskutieren, welche spezifischen Argumente vorgebracht werden könnten oder welche Risiken unserer Meinung nach am wahrscheinlichsten zu Rechtsstreitigkeiten führen könnten, könnte dies einen Fahrplan erstellen, mit dem jemand versuchen könnte, den Projekten und den Gemeinschaften zu schaden.
Wir haben dieses Risiko jedoch aus mehreren Blickwinkeln untersucht, wobei wir die rechtliche und politische Situation in verschiedenen Ländern der Welt sowie Bedenken und Aufsichtsanfragen von Benutzern, deren IP-Adressen veröffentlicht wurden, berücksichtigt haben. Wir kamen zu dem Schluss, dass IP-Adressen von nichtangemeldeten Benutzern nicht mehr öffentlich sichtbar sein sollten, hauptsächlich weil sie einem einzelnen Benutzer oder Gerät zugeordnet werden können und daher verwendet werden könnten, um nicht angemeldete Benutzer zu identifizieren und zu lokalisieren und sie mit ihren Aktivitäten im Wiki zu verknüpfen.
Trotz dieser Bedenken haben wir auch verstanden, dass IP-Adressen eine wichtige Rolle beim Schutz der Projekte spielen und es den Benutzern ermöglichen, Vandalismus und Missbrauch zu bekämpfen. Wir wussten, dass wir diese Frage ganzheitlich angehen müssen. Aus diesem Grund wurde eine Arbeitsgruppe aus verschiedenen Teilen der Wikimedia Foundation zusammengestellt, um diese Frage zu untersuchen und eine Empfehlung an die Geschäftsleitung auszusprechen. Als die Entscheidung getroffen wurde, mit der IP-Maskierung fortzufahren, war uns allen klar, dass wir dies mit den Communities tun mussten – dass wir diesen Übergang nur unter Berücksichtigung Eurer Beobachtungen und Ideen erfolgreich bewältigen können.
Ich möchte betonen, dass dieses Projekt nicht einfach endet, selbst wenn IP-Adressen zukünftig maskiert werden und neue Tools zur Unterstützung Eurer Vandalismus-Abwehr vorhanden sind. Es wird ein iterativer Prozess sein – wir möchten Feedback von Euch erhalten, was funktioniert und was nicht, damit die neuen Tools verbessert und an Eure Bedürfnisse angepasst werden können.
Fragen
In den letzten Monaten hattet Ihr Fragen, und oft waren wir nicht in der Lage, in unseren Antworten die erhoffte Detailtiefe bereitzustellen, insbesondere zu rechtlichen Fragen.
- Welche konkreten rechtlichen Risiken befürchten Sie?
Zu den einzelnen Rechtsrisiken, die wir bewerten, können wir keine Angaben machen. Wir wissen, dass es frustrierend ist, nach dem Warum zu fragen, und man einfach "das ist privilegiert" als Antwort erhält. Und es tut uns leid, dass wir keine genaueren Angaben machen können, aber wie oben erläutert, müssen wir die Details unserer Risikobewertung und die potenziellen rechtlichen Probleme, die wir am Horizont sehen, vertraulich behandeln, da die Bereitstellung dieser Details anderen helfen könnte, daraus zu ermitteln, wie man den Projekten, den Communities und der Foundation schaden könnte.
Auf einige Fragen gibt es jedoch genaue Antworten.
- Wird dieses Projekt fortgesetzt?
Ja, wir arbeiten daran, die besten Methode zu finden und umzusetzen, wie die IP-Adressen von nicht eingeloggten Benutzern verborgen werden kann und gleichzeitig die Fähigkeit der Communities zum Schutz der Projekte erhalten bleibt.
- Kann diese Änderung je nach Standort unterschiedlich eingeführt werden?
Nein. Wir bemühen uns, die Privatsphäre aller Benutzer nach dem gleichen Standard zu schützen; die Änderung betrifft alle Wikimedia-Projekte.
- Wenn andere Informationen über nicht eingeloggte Benutzer preisgegeben werden (z. B. Standort oder ISP), dann spielt es keine Rolle, ob auch die IP-Adresse veröffentlicht wird, oder?
Das ist nicht ganz der Fall. Im neuen System werden die von uns bereitgestellten Informationen allgemeine Informationen sein, die nicht mit einer einzelnen Person oder einem Gerät verknüpft sind, beispielsweise die Angabe eines Standorts auf Stadtebene oder der Hinweis, dass eine Bearbeitung von einer Person an einer bestimmten Universität vorgenommen wurde. Dies sind zwar immer noch Informationen über den Benutzer, aber weniger spezifisch und individuell als eine IP-Adresse. Obwohl wir einige Informationen zur Verfügung stellen, um Missbrauch zu verhindern, leisten wir jedoch einen besseren Job, um die Privatsphäre dieses bestimmten Benutzers zu schützen.
- Reicht es nicht, wenn wir jemandem mitteilen, dass seine IP-Adresse veröffentlicht wird?
Nein. Wie oben erwähnt, waren viele Leute irritiert, als sie ihre IP-Adresse veröffentlicht sahen. Auch wenn jemand den Hinweis sieht, ist die Foundation gesetzlich dazu verpflichtet, mit seinen personenbezogenen Daten richtig umzugehen. Wir sind zu dem Schluss gekommen, dass wir die IP-Adressen nicht eingeloggter Benutzer nicht veröffentlichen sollten, da dies nicht den aktuellen Standard für den Datenschutz entspricht aber auch wegen der damit verbundenen Risiken, einschließlich der Risiken für diese Benutzer.
- Wie wirkt sich die Maskierung auf die CC-BY-SA-Attribute aus?
Die IP-Maskierung hat keinen Einfluss auf die CC-Lizenzzuordnung auf Wikipedia. Die 3.0-Lizenz für Texte zu Wikimedia-Projekten besagt bereits, dass die Namensnennung „den Namen des ursprünglichen Autors (oder Pseudonyms)" (siehe license at section 4c) und die Verwendung einer maskierten IP-adresse entspricht entsprechend einem Pseudonym. IP-Adressen können bereits im Laufe der Zeit variieren oder unterschiedlichen Personen zugeordnet werden, so dass die Verwendung als Proxy für nicht registrierte Redakteure sich in der Qualität nicht von einer IP-Masking-Struktur unterscheidet und beide der Lizenz-Pseudonym-Struktur genügen. Darüber hinaus gelten unsere Terms of use section 7. Die Nutzungsbedingungen legen fest, dass Autoren zustimmen, dass Links zu Artikeln (die die Artikelhistorie enthalten) eine ausreichende Methode der Attribution sind.
Und manchmal wissen wir auf eine Frage noch keine Antwort, weil wir gemeinsam mit Dir eine Lösung finden möchten.
- Welche spezifischen Voraussetzungen sollte jemand haben, um dieses neue Benutzerrecht zu beantragen?
Es wird eine Altersgrenze geben; Wir haben noch keine endgültige Entscheidung über das Limit getroffen, aber es ist wahrscheinlich, dass sie mindestens 16 Jahre alt sein müssen. Darüber hinaus sollten sie aktive, etablierte Community-Mitglieder mit gutem Ansehen sein. Was das bedeutet, möchten wir gerne mit Euch erarbeiten.
- Ich sehe, dass das Team, das diese Änderungen vorbereitet, vorschlägt, ein neues Benutzerrecht für Benutzer zu schaffen, um Zugriff auf die IP-Adressen hinter einer Maske zu haben. Hat die Rechtsabteilung eine Meinung dazu, ob der Zugriff auf die vollständige IP-Adresse, die mit einer bestimmten Benutzernamensmaske verknüpft ist, nicht öffentliche personenbezogene Daten im Sinne der Vertraulichkeitsvereinbarung für nicht öffentliche Informationen darstellt und müssen Benutzer, die dieses neue Benutzerrecht anstreben, die Richtlinie zum Zugriff auf nichtöffentliche personenbezogene Daten oder eine Version davon unterschreiben?
- 1 Wenn ja, kann ich als Checkuser dann mit den Inhabern dieses neuen Nutzerrechts die Beziehungen zwischen registrierten Accounts und deren IP-Adressen besprechen, wie ich es derzeit mit anderen Unterzeichnern tue?
- 2 Falls nein, könnte jemand versuchen zu erklären, warum wir uns all diese Mühe machen, um Informationen zu erhalten, die wir nicht für nicht öffentlich halten?
- 3 Darf ein Checkuser in beiden Fällen Verbindungen zwischen registrierten Konten und nicht registrierten Benutzernamensmasken offenlegen?
Dies ist eine großartige Frage. Die Antwort ist teilweise ja. Erstens, ja, jeder, der Zugang zu diesem Recht hat, muss in irgendeiner Weise bestätigen, dass er auf diese Informationen zum Zwecke der Bekämpfung von Vandalismus und Missbrauch in den Projekten zugreift. Wir arbeiten daran, wie diese Anerkennung erfolgen soll; Der Prozess zur Erlangung des Zugangs ist wahrscheinlich weniger komplex als die Unterzeichnung der Vereinbarung über den Zugang zu nicht öffentlichen personenbezogenen Daten.
Wie sich dies derzeit auf CUs auswirken würde, ermöglicht die Richtlinie zum Zugriff auf nicht öffentliche personenbezogene Daten Benutzern mit Zugriff auf nicht öffentliche personenbezogene Daten, diese Daten mit anderen Benutzern zu teilen, die sie auch einsehen können. So kann ein CU Daten mit anderen CUs teilen, um deren Arbeit zu erledigen. Hier behalten wir eine Unterscheidung zwischen eingeloggten und ausgeloggten Benutzern bei, sodass eine CU IP-Adressen von eingeloggten Benutzern nicht mit Benutzern teilen könnte, die dieses neue Recht haben, weil Benutzer mit dem neuen Recht diesen Zugang zu solchen Informationen nicht hätten.
Unter der Annahme, dass sich der CU auch dafür entscheidet, IP-Adressen von nicht angemeldeten Benutzern zu sehen, wäre CU im Rahmen des aktuellen Schemas in der Lage, IP-Adressinformationen zu teilen, die Verbindungen zwischen angemeldeten Benutzern und nicht angemeldeten Benutzern zu zeigen, die mit anderen CUs maskiert, die sich ebenfalls angemeldet hatten. Sie konnten Benutzern mit dem neuen Recht auch anzeigen, dass sie Verbindungen zwischen angemeldeten und nicht angemeldeten Benutzern entdeckt haben. Die CU konnte jedoch nicht direkt die IP-Adressen der eingeloggten Benutzer mit Nicht-CU-Benutzern teilen, die nur das neue Recht haben.
Bitte lasse es uns wissen, wenn dies nicht praktikabel ist. Wie oben erwähnt, sind wir dabei, die Details zu erarbeiten und möchten Dein Feedback einholen, um sicherzustellen, dass es funktioniert.
Nächste Schritte
In den nächsten Monaten werden wir detailliertere Pläne und Prototypen für die Tools ausrollen, die wir bauen oder beabsichtigen zu bauen. Wir freuen uns über Dein Feedback zu diesen neuen Tools, die zum Schutz der Projekte beitragen. Wir werden weiterhin versuchen, Deine Fragen zu beantworten, wann immer wir können, und werden Deine Meinung einholen, wenn wir gemeinsam zu einer Antwort gelangen sollten. Mit Deinem Feedback können wir einen Plan erstellen, der es uns ermöglicht, die personenbezogenen Daten nicht eingeloggter Autoren besser zu schützen, ohne den Schutz von Wikimedia-Benutzern oder -Sites zu opfern. Wir schätzen Deine Ideen, Deine Fragen und Dein Engagement für dieses Projekt.
Diese Stellungnahme der Rechtsabteilung der Wikimedia Foundation wurde auf Anfrage für die Diskussionsseite geschrieben und stammt aus diesem Kontext. Aus Gründen der Sichtbarkeit wollten wir, dass Ihr sie auch hier lesen könnt.
Hallo an alle. Dies ist eine Nachricht vom Legal Affairs-Team. Zunächst einmal möchten wir uns bei allen für Eure wohl überlegten Kommentare bedanken. Bitte habt Verständnis dafür, dass wir als Juristen manchmal nicht alle Details unserer Überlegungen öffentlich teilen können; aber wir lesen Eure Kommentare und Perspektiven, und sie sind sehr hilfreich für uns bei der Beratung der Foundation.
In manchen Fällen müssen wir Einzelheiten unserer Arbeit oder unseren Rat an die Organisation vertraulich behandeln, und zwar aufgrund der Regeln der Rechtsethik und des Anwaltsgeheimnisses, die bestimmen, wie Anwälte mit Informationen über ihre Arbeit umgehen müssen. Wir sind uns bewusst, dass unsere Zurückhaltung, genau zu sagen, was wir denken und warum wir etwas tun oder nicht tun, in manchen Fällen frustrierend sein kann, so auch in diesem Fall. Obwohl wir nicht immer alle Details offenlegen können, können wir bestätigen, dass unsere allgemeinen Ziele darin bestehen, das Beste zu tun, um die Projekte und die Communities zu schützen und gleichzeitig sicherzustellen, dass die Foundation die geltenden Gesetze befolgt.
Innerhalb des Teams für Rechtsangelegenheiten konzentriert sich die Datenschutzgruppe darauf, sicherzustellen, dass die von der Foundation gehosteten Websites und unsere Praktiken der Datenerfassung und -verarbeitung im Einklang mit den einschlägigen Gesetzen, unseren eigenen Datenschutzrichtlinien und unseren Datenschutzwerten stehen. Wir sind der Meinung, dass der Schutz der Privatsphäre von Mitwirkenden und Lesenden notwendig ist, um die Erstellung, den Austausch und den Konsum von Freiem Wissen weltweit zu ermöglichen. Als Teil dieser Arbeit betrachten wir zunächst das geltende Recht, das durch ein Mosaik von Fragen, Bedenken und Wünschen der Nutzenden, Bedenken wegen der öffentlichen Leitlinien, organisatorischer Richtlinien und bewährter Praktiken der Branche ergänzt wird, um die datenschutzbezogene Arbeit der Foundation zu steuern. Auf der Grundlage dieser Eingaben entwerfen wir eine rechtliche Strategie für die Foundation, die unsere Herangehensweise an den Datenschutz und verwandte Themen bestimmt. In diesem speziellen Fall hat uns die sorgfältige Abwägung dieser Faktoren zu der Bemühung geführt, die IPs von nicht eingeloggten Editoren vor allen Besuchern der Wikimedia-Projekte zu verbergen. Wir können die genauen Details unserer Überlegungen oder die internen Diskussionen und Analysen, die dieser Entscheidung zugrunde liegen, aus den oben genannten Gründen bezüglich der rechtlichen Ethik und des Privilegs nicht darlegen.
Wir möchten betonen, dass die Einzelheiten, wie wir dies tun, flexibel sind; wir suchen nach dem besten Weg, dieses Ziel im Einklang mit der Unterstützung der Bedürfnisse der Community zu erreichen. Es liegen mehrere mögliche Optionen auf dem Tisch, und wir möchten sicherstellen, dass wir die Umsetzung in Partnerschaft mit Euch finden. Wir sind uns bewusst, dass Ihr vielleicht noch weitere Fragen habt, und wir möchten im Vorfeld klarstellen, dass wir in diesem Dialog möglicherweise nicht in der Lage sind, die Fragen zu beantworten, die rechtliche Aspekte haben. Vielen Dank an alle, die sich die Zeit genommen haben, sich mit dieser Arbeit auseinanderzusetzen und ihre Meinungen, Bedenken und Ideen einzubringen.
––
Best regards,
Anti-Harassment Tools Team
Please use the talk page for discussions on the matter. For any issues concerning this release, please don't hesitate to contact Niharika Kohli, Product Manager – niharika
wikimedia.org and cc Sandister Tei, Community Relations Specialist – steiwikimedia.org or leave a message on the talk page.
For more information or documentation on IP editing, masking and an overview of what has been done so far including community discussions, please see the links below.
About IP Editing · About IP Addresses · IP Editing Restriction Study · Impact report for Login Required Experiment on Portuguese Wikipedia · Research:Value of IP Editing