: Successful deployment on minor pilots and progress on the features
As planned, at the end of October and in the first days of November, we launched Temporary Accounts to 12 projects. We are happy to report that we did not encounter any issues that required us to roll back the deployment. There is a lot of activity from temporary accounts on these projects. We are currently collecting detailed data, and will publish a report with our findings about it in the coming weeks. We will also be running a survey to better understand the impact of this rollout on users with advanced rights. Many thanks to the communities of the pilot wikis, stewards, CheckUsers, and global sysops for their openness, good questions, and ideas for changes.
We are implementing an onboarding dialog box to help registered users understand temporary accounts and associated features. The dialog box will introduce the concept of temporary accounts, the IP Info tool with the IP reveal feature, and more. (T373818)
A mockup of AutorevealWe have decided to implement an "auto-reveal" feature. It will allow selected functionaries to view all IP addresses, for all temporary accounts in a defined period of time. This feature will help functionaries respond quickly to abuse, for example vandalism events that require checking a lot of IP addresses. We are currently defining the typical tasks and designs for this feature. We will be grateful if you share your thoughts about Autoreveal in this Phabricator task. The decision to build it was based on our discussions with stewards and other users with extended rights, and we would like to thank them again for their continued involvement and invaluable advice.
Special:GlobalContributions will be able to display information about cross-wiki contributions from registered users, IP addresses, IP ranges, and temporary accounts in the near future. (T375632)
: Deployments on the first pilots
Deployment schedule
We have a finalized list of small-to-medium sized projects where we will be deploying temporary accounts over the next couple of weeks. The goal is to ensure all critical functionality (patroller workflows, tools etc.) for temporary accounts works as expected. We decided to split this phase into two batches. This way, we will have more control over the key functionality and more confidence before temporary accounts are introduced on the largest of the first pilots.
We are developing a public dashboard for monitoring metrics for our pilot projects. We will have a documentation page in place shortly to explain which metrics we are focusing on and why.
Special:GlobalContributions is now ready for looking up cross-wiki contributions from an IP address. This page will only be accessible to users who qualify to see IP addresses associated with a temporary account. We are still ironing out permissions for this page access. We will have a documentation page up about it over the next week.
We have updated IP Info to support information for multiple IP addresses that may be associated with a temporary account. Special:IPInfo should be available on all projects where temporary accounts will be deployed.
We are updating IP Info access policy to be at par with the IP Reveal policy. You can follow along with this task for further information.
Temporary accounts can now be globally blocked. Global autoblocks work is in progress and should be implemented over the next couple of weeks.
Temporary accounts are now available on all beta cluster projects except for en-rtl for testing.
We are looking forward to your comments on the talk page.
: Deployment plan is ready!
We are happy to announce our timeline and strategy for the temporary accounts deployments across all wikis.The plan was co-created by the Product and Technology, Legal, and Communications departments at the Foundation.We also consulted stewards and informed CheckUsers.All the date below are subject to change based on the extent of pending work.We will be informing you if anything changes.
In late October 2024, we will roll out on approximately 10 small and medium-sized wikis.This phase is called the minor pilot deployment.We have pre-selected potential good pilots based on different factors.These include: the numbers of active admins and IP edits per month, lack of blockers related to the configuration of a given wiki, availability of potential ambassadors and technical members of the respective communities, and more.After we deploy there, we will be monitoring the impact of this project on collaboration on wikis.We will also be contacting community members of these wikis.Some time later, we will monitor what will happen when the initial IP addresses of temporary accounts are not available to patrollers.
If the first deployments are successful and we don't have a ton of unexpected work, then in February 2025, we will roll out on larger wikis.We call this major pilot deployment.It may include some top10 wikis, but not English Wikipedia.
Next, in May 2025, we will deploy on all remaining wikis in one carefully coordinated step.After that, we will be providing support, monitoring metrics, and solving issues as they arise.
We will do our best to inform everyone impacted ahead of time.Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms.At conferences, for example regional and national ones, we or our colleagues on our behalf will be inviting talk about this project with attendees.We will also try to have presentations there.In addition, we will be contacting affiliates running programs of support for editors with advanced permissions.Subscribe to our new newsletter to stay close in touch.
: Progress on our technical work
Before we deploy temporary accounts to any non-test wiki, we need to complete our work on a few remaining tasks.These include:
Live-updated metrics on temporary accounts.Before the October deployments, we will build a dashboard presenting the impact of temporary accounts on communities.There will be different graphs showing, for example, numbers of reverts, blocks, temp accounts' IP address previews ("IP Reveal"), successful and abandoned edits, and more.All these will be updated very frequently, for instance, every day, to give everyone a good visibility of the actual work of temporary accounts on wikis. (T357763)
Allowing global autoblocks for temporary accounts (T368949), building a mechanism automatically giving the eligible users the right to reveal IP addresses of temporary accounts (T327913), and some other tasks.
Relatedly, we wanted to share a kind request to the maintainers of community-owned code like tools, bots, gadgets etc.We want to avoid any unnecessary disruptions to your software.If it uses data about IP addresses or is available for not logged-in users, please read our documentation, and in particular, the section on how your code might need to be updated.We will gladly help you out, and we're waiting for your questions.
Graduating IP Info out of beta features.IP Info provides reliable information about IP addresses to some logged-in users.According to a dedicated policy, this tool may only be used for the investigation or prevention of violations of policies.Users can access it if they select a checkbox in their preferences, agreeing to use this tool in accordance with these terms.Then, they can see a button ⓘ displayed next to the IP address on pages like Recent Changes, Watchlist, and page history.The feature is also available for them at the top of the Special:Contributions page when contributions of a specific IP address are listed.Soon, we will make this a regular feature and remove it from the list of beta features.We will also make some changes to its functionality.For more information about IP Info, watch its project page or subscribe to our new newsletter. (T375084)
: Global blocks are here. Temporary accounts on testwiki
Deployment on testwiki. We have rolled out temporary accounts to testwiki. Anyone who edits testwiki without an account will see their edits being attributed to a temporary account. We would like to emphasize that this is an early release, and things may break. This deployment makes it possible for some teams (like Data Platform Engineering or Apps) to start adjusting their code to temporary accounts. We aren't planning on introducing temporary accounts on any other wiki just yet. Instead, we will invite patrollers from different communities to testwiki and ask them to familiarize themselves with the new experience and share opinions with us. Currently, only testwiki admins can see the implemented patroller workflows (such as revealing IPs and view IP contributions) for temporary accounts. Over the next few weeks we will broaden the access to allow more users to test temporary accounts related workflows on testwiki.
Global blocking. We are really glad to announce that we launched global account blocks on all wikis (T17294). A request for this feature was first documented in 2008. It was also the top6 feature in the stewards' wishlist from 2015. Now, stewards can globally block regular and temporary account users. Read our previous update to learn more about the expected impact of global blocks.
Wikimania. We will be hosting sessions "Temporary Accounts are coming" (add to your favorite sessions) and "Getting better at blocking bad activity on the wikis" (add to your favorite sessions). Register to Wikimania to add sessions to favorites. Please join us in-person or virtually, and don't hesitate to get in touch with our team members during the event!
AbuseFilter. Some existing edit/abuse filters set up by community members on different wikis will need to be updated to work with temporary accounts. (See our instructions for developers on how to do this.) After the deployment of temporary accounts on a given wiki, abuse filters using data about IP together with related logs will be hidden from general view. It will be possible for admins to view and edit these filters. Later, we may change the group of users with access to the impacted filters, to potentially include technical editors who don't have any other advanced permissions.
Ältere Updates
: Priority for functionary and patroller tools
Team changes. In our update from September 2023, we wrote that changes to the team may have an effect on the timeline of this project. Indeed, they had, as we wrote on the talk page earlier this year. Briefly, the Anti-Harassment Tools and Trust and Safety Tools teams were merged into one to work according to a unified plan. Now, we encourage you to look at our refreshed team page and our part of the 2024–2025 annual plan: key results WE4.1, WE4.2, and WE4.4. Temporary accounts are documented as WE4.4.
Documentation. We invite you to read the new FAQ, visit the main project page, and click around. We have migrated pages from Meta-Wiki, and restructured and updated them. Hopefully, the new structure makes it easier to learn about the future changes, how temporary accounts will work, and why this change will happen.
Wikimania. Our team members will hold two sessions at Wikimania 2024: about temporary accounts and about getting better at blocking bad activity on wikis. Whether you're going to be in Katowice or connecting online, join us!
Projected timeline for deployments:
We have reviewed our previous plans and prioritized support for patroller tools and anti-abuse workflows. The most important part of our work is ensuring that wiki functionaries and patrollers are comfortable with the rollout of temporary accounts. We can't estimate how much time this part of work will take. As a result, we can't announce the dates of deployments yet.
In April, we asked volunteer developers to update the code they maintain. This was an early call to give them time to prepare. Some tools may need to be updated before the test wiki deployment.
We are discussing our strategy for content wiki deployments. We're weighing different factors, including consistency of functionaries' workflows across wikis, and availability of functionaries and frequency of abuse on different wikis.
Changes to features and tools. As we mentioned, we are prioritizing support for patrollers and functionaries. Below are examples of our recent work:
Global blocking. Currently, there is no tool that allows stewards to globally block an account – there is only global lock, which logs the person out of their account. Without our changes, a temporary account holder blocked this way would lose their account and create a new one with their next edit attempt. After our changes, they will not be logged out, and they will see a block notice on their next edit attempt (T17294). Doing this also means that stewards will be able to globally block registered users, which implements a long-requested feature and provides better tools to combat cross-wiki abuse.
Autoblocks. To make the above effective, we will also support autoblocks, limiting temporary account creations (T355286). This will limit the avenues for abuse if a person using a temporary account that is globally blocked exits their session and tries to make an edit again.
Global User Contributions. The Global User Contributions tool allows patrollers to track a logged-out user's edits on all wikis and track cross-wiki abuse. It depends on IP addresses being public, though. As a result of our deployments, it will stop working. We are building a new tool with the same name which will provide the same functionality (T337089).
Special page for IP contributions. Currently, functionaries check contributions made by logged-out users from IPs, using the page Special:Contributions. After our deployments, only regular and temporary account holders' contributions will be listed on this special page. We are building a new page, Special:IPContributions, to keep the functionality (T358852).
We are also updating other tools like AbuseFilter, CheckUser tools, action API, and more.
: 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.
: 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:
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.
↑(Auch wenn das Fragezeichen ein gutes Zeichen für etwas Unbekanntes ist und allgemein verstanden wird, gibt es Details, die wir noch herausfinden müssen. Sie muss zum Beispiel mit %3F in der URL kodiert werden. Diese URL-Kodierung sollte kein Problem darstellen, ist aber ein Hindernis für Benutzer/innen, die es gewohnt sind, URLs von Hand einzutippen).
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=":_Refocusing_work_on_IP_Masking">
: 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.
: 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=":_IP_Masking_and_changes_to_workflows">
: 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.
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.
: 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).
Screenshot einer IP-basierten Identität
Screenshot einer sitzungsbasierten Identität
.png)