: Successful deployment on minor pilots and progress on the features
Harmonogram wdrażania
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)
: Wdrażanie na pierwsze wiki pilotażowe
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.
<span id=":_Deployment_plan_is_ready!">
: Plan wdrażania jest gotowy!
Z przyjemnością ogłaszamy harmonogram i strategię wdrażania kont tymczasowych na wszystkich wiki.
Plan został wspólnie stworzony przez zespoły Product and Technology, Legal oraz Communications.
Skonsultowaliśmy się również ze stewardami i poinformowaliśmy CheckUserów.
Wszystkie poniższe daty mogą ulec zmianie w zależności od zakresu prac.
Będziemy informować Was na bieżąco.
Pod koniec października 2024 r. uruchomimy tę funkcję na około 10 małych i średnich wiki. Faza ta nazywana jest małym wdrożeniem pilotażowym. Wstępnie wybraliśmy potencjalne wiki pilotażowe na podstawie różnych czynników. 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.
Starsze wiadomości
: 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.
Format nazw kont tymczasowych. Formatem nazw tymczasowych kont będzie ~YYYY-nnnnn-nnn. YYYY oznacza rok, w którym utworzone zostało konto tymczasowe. Sekwencja n reprezentuje unikalny identyfikator nazwy konta tymczasowego. Na przykład, konto tymczasowe utworzone w 2023 roku może wyglądać tak: ~2023-27459-041. Prefiks roku pomaga określić, od ilu lat może to konto tymczasowe być utworzone. Daje to informację patrolującym i innym osobom o możliwości skontaktowania się z tym użytkownikiem. 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.
Nowe narzędzia
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.
: Plan maskowania IP
Tak jak obiecaliśmy, oto najnowszy opis, jak będzie działało maskowanie IP.
Obejmuje on zmiany jakie dotkną zarówno niezarejestrowanych jak i zarejestrowanych użytkowników.
Na wstępie chcemy zaznaczyć, że wciąż mamy wiele otwartych pytań i rzeczy, co do których nie podjęliśmy decyzji.
To jest nasz wstępny plan i nie obejmuje wszystkiego, co zamierzamy zrobić w ramach tego projektu.
W miarę postępów odkrywamy nowe elementy wcześniej niezaplanowanej pracy.
Twoja opinia pomoże nam zrozumieć, co jeszcze możemy zrobić, aby maskowanie adresów IP było bardziej zrozumiałe dla społeczności.
Ten komunikat jest w formie FAQ, dzięki czemu przedstawi nadchodzące zmiany jasno i zrozumiałe.
Co zmienia IP Masking z perspektywy niezalogowanego edytującego?
Obecnie niezalogowany użytkownik, zanim zakończy edycję, jest informowany, że autorstwo jego zmian zostanie przypisane do jego adresu IP.
W przyszłości, zanim niezalogowany użytkownik zakończy edycję, zostanie poinformowany, że jego zmiany zostaną przypisane do konta tymczasowego.
Jego nazwa będzie liczbą, zwiększającą się dla każdego nowego konta.
Konto zostanie powiązane z plikiem cookie przechowywanym w przeglądarce użytkownika.
Dopóki ten plik cookie istnieje, użytkownik będzie utrzymywał w posiadaniu to samo konto tymczasowe, a wszystkie jego zmiany będą przypisywane do tego konta.
Adresy IP użytkownika mogą się zmieniać, ale konto tymczasowe nie zmieni się tak długo, jak istnieje plik cookie.
Tymczasowe konto utworzone na jednej wiki będzie działać również na innych wiki, na których ten sam użytkownik może edytować.
Jak będą wyglądały tymczasowe nazwy użytkownika?
Jeszcze tego nie wiemy.
Nasze pierwsze plany rozważały użycie gwiazdki jako prefiksu, po którym następuje automatycznie zwiększająca się liczba.
(Przykład: *12345.)
Te plany znajdziesz niżej.
Ale jak zauważyli niektórzy wolontariusze, gwiazdka nie jest dobrym wyborem z powodu znanego od dłuższego czasu błędu MediaWiki.
Prowadzimy dyskusję na temat różnych opcji prefiksów i będziemy przeprowadzać z nimi testy na użytkownikach.
Nasze najlepsze propozycje (kolejność nie ma znaczenia) to:
Czy któryś z nich wydaje ci się świetnym lub złym wyborem?
Prosimy o komentowanie, zarówno na stronie dyskusji jak i w Phabricatorze.
↑(Chociaż znak zapytania jest świetnym znakiem, oznaczającym coś nieznanego i jest powszechnie rozumiany, są szczegóły, nad którymi wciąż się zastanawiamy. Na przykład, w URL-ach musi być on zakodowany, w postaci %3F. Kodowanie URL samo w sobie nie jest problemem, ale może przysporzyć trudności użytkownikom wpisującym adresy ręcznie.)
Jak długo utrzymują się tymczasowe nazwy użytkowników?
Jakiś czas po pierwszej edycji (wstępnie sugerujemy jeden rok) lub w wyniku wyczyszczenia pamięci podręcznej użytkownika, plik cookie automatycznie wygaśnie.
Dotychczasowe edycje będą jednak nadal do niego przypisane.
Po wygaśnięciu starej nazwy użytkownika, jeśli użytkownik dokona edycji w przyszłości, otrzyma nowe konto tymczasowe.
Co zmienia IP Masking z perspektywy patrolującego?
Ograniczone pokazywanie adresów IP
Najważniejsza zmianą jest to, że adresy IP nie będą już dłużej pokazywane wszystkim publicznie.
Każdy, kto nie ma konta lub nie spełnia wymaganych progów dostępu do adresów IP (patrz komunikat działu prawnego), nie będzie mógł zobaczyć adresów IP.
Aby złagodzić wpływ na patrolowanie, udostępnimy ulepszenia funkcji informacji o adresie IP.
Będzie zawierał on dane z usługi Spur.
Otrzymywanie dostępu do adresów IP
Wraz z działem prawnym Fundacji, opracowaliśmy nowe wytyczne.
Określają one, kto będzie mógł uzyskać dostęp do adresów IP i w jaki sposób.
Użytkownicy, którzy spełnią wymagania, będą mogli włączyć ujawnianie adresów IP w Preferencjach.
Zobacz szczegółowo, jak będzie działać funkcja ujawniania.
Ten dostęp i ujawnienie będą rejestrowane, a rejestr ten będzie dostępny dla ograniczonej grupy użytkowników (CheckUserzy, stewardzi, Trust & Safety).
Lepsze kanały komunikacji z użytkownikami tymczasowymi
Konta tymczasowe zostaną powiązane z plikiem cookie przeglądarki.
Tak długo, jak plik cookie istnieje, zmiany wprowadzone przez użytkownika będą przypisywane do tego samego konta tymczasowego.
Tymczasowi posiadacze kont będą również mogli otrzymywać powiadomienia ze stron dyskusji, tak jak zarejestrowani użytkownicy.
Mamy nadzieję, że pozwoli to na lepszą komunikację z użytkownikami tymczasowymi.
Może to również rozwiązać niektóre długotrwałe problemy zgłaszane przez społeczności (patrz T278838).
Dokumentowanie adresów IP wandali
Będzie można publicznie dokumentować adresy IP złych ludzi za pomocą stron o długoterminowych nadużyciach, tak jak dotychczas.
Należy jednak uważać, aby nie ujawnić adresów IP innych użytkowników tymczasowych.
Podczas analizowania potencjalnych złych kont, powinny być używane narzędzia takie jak ukrywanie wersji, jeśli użytkownik okazał się nie być wandalem.
Więcej szczegółów na ten temat można znaleźć w wytycznych.
Jesteśmy w trakcie opracowywania wytycznych dla obsługujących boty i narzędzia na serwerze narzędziowym dotyczących dostępu do adresów IP do celów patrolowania.
Wkrótce wydamy komunikat na ten temat.
Co stanie się z dotychczasowymi adresami IP na naszych stronach?
Istniejące adresy IP, które są już zapisane na naszych wiki, pozostaną nietknięte.
Edycje wykonane po wprowadzeniu maskowania adresów IP zostaną przypisane tymczasowym nazwom użytkowników.
Ponieważ maskowanie adresów IP będziemy wprowadzać stopniowo, będzie to oznaczać, że zmiana ta nastąpi na różnych wiki w różnym czasie.
Jak będzie działać funkcja ujawniania adresu IP?
Użytkownicy, którzy mają dostęp do adresów IP, będą mogli wyświetlać adresy IP kont tymczasowych.
Makiety przedstawiające jak to będzie działało:
Co stanie się z narzędziami i botami, których działanie polega na adresach IP?
Pracujemy nad przeanalizowaniem wpływu na narzędzia utrzymywane przez wolontariuszy.
This is a task for our team as well as the Research and Engineering teams.
Następnie będziemy współpracować z działem prawnym, aby ustalić, które narzędzia mogą nadal uzyskiwać dostęp do adresów IP oraz wytyczne dotyczące ich działania.
Zamieścimy komunikat na tej stronie, gdy będziemy mieli już plan działań.
Plan wdrażania
Zamierzamy testować maskowania adresów IP powoli, aby zapewnić wystarczająco dużo czasu na opinie i testy społeczności.
Chcemy, aby nasze wdrażanie nie utrudniało procesów zachodzących w społecznościach.
Innym naszym priorytetem jest unikanie niepożądanych skutków dla zdrowia społeczności.
Wdrożyliśmy metryki, które planujemy obserwować podczas wdrażania zmian.
Poszukujemy społeczności, które byłyby kandydatami do testowego uruchomienia (pilotażu) IP Masking.
Bierzemy pod uwagę takie kryteria, jak liczba edycji niezalogowanych na danej wiki, pilność działań związanych z przeciwdziałaniem aktom wandalizmu, rozmiar projektu i potencjalne zakłócenia.
Na tej stronie zamieścimy kolejny komunikat dotyczący wybranych przez nas kandydatów do szybszego wprowadzenia maskowania adresów IP.
Jeśli chcesz, aby Twoja społeczność przetestowała uruchomienie maskowania adresów IP, podejmijcie decyzję jako społeczność i dajcie nam znać na stronie dyskusji.
<span id=":_Refocusing_work_on_IP_Masking">
: Ponowne skupienie się na pracy nad maskowaniem adresów IP
Cześć wszystkim. Oficjalnie skupiamy się ponownie na głównym projekcie maskowania adresów IP, teraz, gdy zakończyliśmy pierwszą fazę tworzenia narzędzia Informacje o IP i inne powiązane projekty. Posuwamy się naprzód w planowaniu technicznym, aby ustalić, co trzeba będzie zmienić, gdy zacznie obowiązywać maskowanie adresów IP. W razie potrzeby skontaktujemy się z naszymi wolontariuszami technicznymi, aby pomogli ocenić zmiany i przeprowadzić migrację narzędzi. Część tych prac planistycznych już się rozpoczęła w Phabricatorze i tam możesz się z nami skontaktować, jeśli masz pytania dotyczące konkretnych zadań.
Wkrótce opublikuję kolejny post, aby podzielić się zarysem MVP (Minimum Viable Product), z którym wylądowaliśmy. To MVP opiera się na rozmowach, które odbyliśmy ze społecznością w przeszłości za pośrednictwem tej strony i innych mediów. Zachęcamy do zapoznania się z poprzednimi rozmowami i przeczytania poprzednich aktualizacji na tej stronie. Jeśli masz pytania lub wątpliwości, możesz skontaktować się z nami na stronie dyskusji.
Po pierwsze, dziękuję wszystkim, którzy weszli na tę stronę i podzielili się swoimi opiniami. Słyszeliśmy od wielu z Was, że ta strona nie jest łatwa do czytania i pracujemy nad poprawieniem tego. Naprawdę chcemy podziękować za poświęcenie czasu na przejrzenie tutejszych informacji i na stronie dyskusji. Wzięliśmy pod uwagę każdy komentarz na stronie dyskusji przed podjęciem decyzji o planie wdrożenia.
Wstępnie chcemy powiedzieć, że wciąż jest wiele otwartych pytań. Przed nami długa droga w związku z tym projektem i chcielibyśmy, abyście wyrazili swoją opinię w kolejnych dyskusjach, gdy się pojawią. Jeśli jeszcze tego nie zrobiłeś, przejrzyj ten post o tym, kto nadal będzie miał dostęp do adresów IP, zanim zaczniesz czytać dalej.
Otrzymaliśmy mieszane opinie od społeczności na temat dwóch proponowanych pomysłów na implementację, bez wyraźnego konsensusu w obu kierunkach. Oto kilka cytatów zaczerpniętych ze strony dyskusji:
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.
Podsumowując, głównym argumentem przeciwko podejściu opartym na sesji był fakt, że plików cookie łatwo się pozbyć, a użytkownik może bardzo łatwo zmienić swoją tożsamość.
A głównymi argumentami przeciwko podejściu opartemu na IP były:
metoda szyfrowania może zostać rozpracowana, a tym samym same adresy IP
to podejście nie zapewnia korzyści w postaci lepszej komunikacji z niezarejestrowanymi użytkownikami
nie pozwala na blokowanie na podstawie sesji (oprócz blokowania na podstawie adresu IP)
W świetle powyższych argmentów i dyskusji z naszym zespołem technicznym na temat wykonalności i szeroko zakrojonych implikacji tej implementacji, zdecydowaliśmy się na podejście oparte na sesjach z kilkoma ważnymi dodatkami, aby rozwiązać problem usuwania przez użytkowników ich cookies i zmiany ich tożsamości. Jeśli użytkownik wielokrotnie zmienia swoją nazwę użytkownika, możliwe będzie powiązanie jego tożsamości poprzez sprawdzenie dodatkowych informacji w interfejsie. Nadal pracujemy nad szczegółami tego, jak to będzie działać – ale będzie to podobne do tego, jak działa wykrywanie pacynek (z pewną automatyzacją).
Nadal pracujemy nad wieloma szczegółami technicznymi i wkrótce będziemy mieli dla Was kolejną aktualizację z większą ilością szczegółów. Obejmie to dokumentację LTA, komunikację dotyczącą adresów IP, filtry nadużyć, strony wiki spoza Wikimedia, gadżety, skrypty użytkowników, narzędzia w chmurze WMF, ograniczenia dotyczące uprawnień osób przeglądających adresy IP itp. Doceniamy Twój wkład i mile widziane są wszelkie opinie, które możesz przekazać nam na stronie dyskusji.
<span id=":_IP_Masking_and_changes_to_workflows">
: Maskowanie IP i zmiany w sposobie wykonywania zadań
Omówiliśmy dwa różne podejścia do maskowania adresów IP, które rozważamy. W ramach dalszych prac przywołaliśmy kilka różnych przepływów pracy i jak zmienią się one w dwóch tych różnych implementacjach.
Uwaga: w obu propozycjach administratorzy, stewardzi, checkuserzy u użytkownicy z funkcją IPViewer będą mogli odkryć adresy IP na stronach takich jak Ostatnie zmiany czy Historia celem walki z wandalizmami.
Sposób edytowania u niezalogowanych użytkowników
Obecne działanie: niezarejestrowani użytkownicy mogą edytować bez logowania się (na większości wiki). Zanim dokonają edycji, widzą banner informujący o tym, że ich adres IP zostanie zapisany i będzie upubliczniony na stałe.
Identyfikacja oparta na IP: Niezarejestrowani nadal będą mogli edytować. Zanim dokonają edycji, zobaczą banner, który poinformuje ich o tym, że autorstwo ich edycji zostanie przypisane zaszyfrowanej wersji zapisu ich adresu IP. Właściwy adres IP będzie widoczny dla administratorów i patrolujących i będzie przechowywany tylko przez ograniczony czas.
Identyfikacja oparta na sesji: Podobne do powyższego, ale edytujący będą informowani o przydzieleniu automatycznie wygenerowanej nazwie użytkownika, którą oznaczone zostanie autorstwo edycji.
IP-based identity screenshot
Session-based identity screenshot
Rozmawianie o niezarejestrowanych użytkownikach
Obecne działanie: Niezarejestrowani użytkownicy są wskazywani poprzez podanie ich adresów, a gdy są uciążliwymi i nawracającymi wandalami mają nadawane określenia na podstawie ich działań.
Identyfikacja oparta na IP: Patrolujący i administratorzy nie będą mogli wzmiankować publicznie adresów IP, ale będą mogli za odwołanie użyć ich zaszyfrowany adres IP lub nazwę uporczywego wandala. Podawać adres IP będzie mógł tylko innym użytkownikom, którzy też będą mieli uprawnienia dostępu do adresów IP.
Tożsamość oparta na sesji: Patrolerzy i administratorzy nie będą mogli publicznie odnosić się do adresów IP, ale będą mogli odnosić się do ich automatycznie generowanych nazw użytkowników. Mogą udostępniać IP innym osobom, które mają do niech dostęp. Może to pomóc zidentyfikować konkretną osobę stojącą za nimi, ale może być również mylące, jeśli za nazwą użytkownika znajduje się wiele adresów IP, podobnie jak wiele osób może dziś kryć się za adresem IP. Aby złagodzić ten problem, tworzymy narzędzie, które będzie w stanie wyświetlić informacje o wszystkich adresach IP, z których aktywny jest dany użytkownik.
Sposób działania stron dyskusji u niezalogowanych użytkowników
Obecne działanie: Niezarejestrowany użytkownik może otrzymywać wiadomości na stronie dyskusji powiązanej z adresem IP. Gdy adres IP tej osoby się zmieni, wiadomości będą przychodziły na stronę dyskusji nowego IP. To powoduje rozrzucenie wiadomości kierowanych do tej samej osoby.
Identyfikacja na podstawie IP: Podobnie jak dotychczasowe działanie, ale strony dyskusji mają w nazwie zaszyfrowany adres IP. Gdy zmieni się ich IP, tak samo jak dotychczas, strona dyskusji też się zmieni.
Identyfikacja oparta na sesji: Niezarejestrowani użytkownicy będą otrzymywać wiadomości na stronie dyskusji powiązanej z identyfikatorem przechowywanym w ciasteczku przeglądarki. Jeżeli ich adres IP się zmieni, wiadomości do tej samej osoby będą nadal przychodziły na tę samą stronę dyskusji. Gdy usuną ciasteczka przeglądarki, użytkownik nie wróci już do tej samej sesji i otrzyma nowe ciasteczko i nową stronę dyskusji. Ponieważ adresy IP zmieniają się częściej niż ciasteczka, prawdopodobnie strony dyskusji wielu użytkowników będą dla nich prawie że trwale przydzielone, chyba że się postara żeby było inaczej. Inną zaleta jest to, że wiadomości na stronie dyskusji nie będą pojawiać się u niewłaściwego adresata.
Powiadomienie o wiadomości na stronie dyskusji
Blokowanie niezarejestrowanych użytkowników
Obecne działanie: Administrator może bezpośrednio blokować adresy IP lub ich zakresy. Mogą też włączyć automatyczne blokowanie edycji nawet po zmianie IP (zapisywane jest ciasteczko w przeglądarce zablokowanego użytkownika).
Tożsamość oparta na adresie IP: Zachowanie pozostaje takie samo jak obecne. Adresy IP są domyślnie maskowane, ale dostęp do nich mają administratorzy i patrolujący z odpowiednimi uprawnieniami.
Tożsamość oparta na sesji: Ta implementacja pozwala nam zachować obecne zachowanie blokowania według adresów IP. Pozwala nam to również na nakładanie wyłącznie blokad opartych na plikach cookie. Może to być pomocne w scenariuszach, w których ludzie współużytkują urządzenia (takie jak biblioteka lub kawiarenka internetowa), a blokowanie adresu IP lub zakresu adresów IP może spowodować niepotrzebne skutki uboczne. Chcę zaznaczyć, że nie zadziała to w przypadkach, gdy wandale są doświadczonymi użytkownikami i potrafią ominąć blokadę z użyciem cookie.
: Najważniejsze pytania i odpowiedzi dotyczące wdrożenia maskowania IP
Te FAQ pomoże odpowiedzieć na niektóre możliwe pytania społeczności dotyczące różnych podejść do implementacji maskowania adresów IP oraz wpływu każdego z nich na społeczność.
Kto po zaimplementowaniu maskowania IP będzie mógł zobaczyć adresy IP?
Checkuserzy, stewardzi i administratorzy będą mogli zobaczyć pełne adresy IP po włączeniu opcji w preferencjach i jeśli zaakceptują, że nie mogą ich ujawniać osobom innym niż także mających dostęp do tej informacji.
Użytkownicy, którzy biorą udział w działaniach przeciwko wandalizmom, zgodnie z wolą społeczności, mogą otrzymać prawo do wglądu w adresy IP, aby mogli działać dalej. Te uprawnienie użytkownika byłoby traktowane przez społeczność podobnie jak inne uprawnienia użytkowników i wymagałoby minimalnej liczby edycji i dni spędzonych na edytowaniu.
Wszyscy użytkownicy z kontami o określonym stażu i z minimalną liczbą edycji (do ustalenia) będą mogli uzyskać dostęp do częściowo zdemaskowanych adresów IP bez konieczności uzyskania specjalnego uprawnienia. Oznacza to, że adres IP pokazywany będzie z ukrytymi końcowymi oktetami – ostatnimi częściami. Będzie to dostępne do włączenia za pośrednictwem preferencji, w których zgodzą się oni nie udostępniać ich innym osobom, które nie mają dostępu do tych informacji.
Pozostali użytkownicy nie będą mieli dostępu do adresów IP niezarejestrowanych użytkowników.
Jakie są możliwe rozwiązania techniczne?
W ciągu ostatnich kilku tygodni byliśmy zaangażowani w wiele dyskusji na temat technicznych możliwości osiągnięcia naszego celu w zakresie maskowania adresów IP przy jednoczesnym zminimalizowaniu wpływu na naszych redaktorów i czytelników. Zebraliśmy opinie od różnych zespołów i uzyskaliśmy różne perspektywy. Poniżej znajdują się dwie kluczowe ścieżki.
Identyfikacja oparta na IP: wszystko działa tak jak dotychczas, ale zamiast IP używany jest hash adresu IP.
Identyfikacja oparta na sesji: W tym przypadku tworzymy tożsamość użytkowników niezarejestrowanych na podstawie ciasteczka przeglądarki. Ciasteczko utrzymuje się nawet, gdy adres IP zmieni się.
Jak działa ścieżka tożsamość oparta na adresie IP?
Obecnie niezarejestrowanych identyfikuje się po ich adresach IP. Ten model sprawdza się w naszych projektach od wielu lat. Użytkownicy dobrze zorientowani w adresach IP rozumieją, że jeden adres IP może być używany przez wielu różnych użytkowników w zależności od tego, jak dynamiczny jest ten adres IP. Jest to bardziej prawdziwe w przypadku adresów IP IPv6 niż IPv4.
IP użytkownika niezalogowanego może tez zmienić się, gdy się on przemieszcza lub będzie edytować z innego miejsca niż poprzednio.
Jeżeli wprowadzimy identyfikacje na bazie IP jako sposób na maskowanie IP, zachowamy sposób działania mechanizmów wiki z nimi związanych, bo tylko zamaskujemy IP za pomocą identyfikatora będącego zaszyfrowanym adresem IP. Zachowamy w ten sposób rozróżnianie adresów IP ale jednocześnie zapewnimy prywatność. Na przykład niezarejestrowany użytkownik User:192.168.1.2 może się wyświetlać jako User:ca1f46.
Zalety tego sposobu:
Zachowuje dotychczasowe sposoby pracy, z niewielkimi zakłóceniami
Wady tego sposobu:
Nie oferuje żadnej przewagi w świecie, gdzie IP są dynamiczne i mało użyteczne
Jak działa ścieżka tożsamość oparta na sesji?
Ścieżka polega na utworzeniu nowej tożsamości dla niezarejestrowanych na podstawie pliku cookie umieszczonego w ich przeglądarce. W tym podejściu występuje automatycznie generowana nazwa użytkownika, do której przypisywane są ich edycje i działania. Na przykład Użytkownik:192.168.1.2 może otrzymać nazwę użytkownika: Użytkownik:Anon3406.
W tym podejściu sesja użytkownika będzie trwała tak długo jak będzie miał zapisane ciasteczko, nawet gdy zmieni adres IP.
Zalety tego sposobu:
Pozwiązuje tożsamość użytkownika z przeglądarka i urządzeniem oferując bardziej trwały sposób na komunikowanie się z nim.
Tożsamość użytkownika nie zmienia się wraz ze zmianą adresu IP
To podejście oferuje niezarejestrowanym użytkownikom możliwość ustawiania niektórych preferencji dostępnych dotychczas tylko dla zarejestrowanych.
Może też zaoferować możliwość skonwertowania na konto stałe z zachowaniem ich historii edycji
Wady tego sposobu:
Znaczna zmiana modelu tego, co reprezentuje konto użytkownika niezalogowanego
Użytkownik jest identyfikowany tak długo, jak istnieje jego ciasteczko w przeglądarce
Wandale korzystający z trybu prywatnego lub usuwający ciasteczka mogą zmienić tożsamość nawet bez zmiany IP
Wymaga zmian w przepływach pracy społeczności i narzędziach
Czy Fundacja preferuje któreś rozwiązanie?
Naszym preferowanym podejściem będzie tożsamość oparta na sesjach, ponieważ otworzy to wiele możliwości na przyszłość. Moglibyśmy rozwiązać problemy z komunikacją z niezarejestrowanymi, które mamy od dwudziestu lat. Chociaż ktoś mógłby usunąć plik cookie, aby uzyskać nową tożsamość, adres IP byłby nadal widoczny dla wszystkich aktywnych zwalczających wandalizmy z nowym uprawnieniem. Zdajemy sobie sprawę, że usunięcie pliku cookie jest oczywiście łatwiejsze niż zmiana adresu IP i uwzględniamy skutki, jakie by to przyniosło.
: Propozycja udostępniania adresów IP osobom, które tego potrzebują
Cześć wszystkim. Minęło kilka miesięcy od naszej ostatniej aktualizacji tego projektu. Poświęciliśmy ten czas na rozmowy z wieloma osobami — ze społeczności redakcyjnej i z Fundacji. Dołożyliśmy wszelkich starań, aby rozważyć wszystkie obawy wyrażone w naszych dyskusjach z doświadczonymi członkami społeczności na temat wpływu, jaki będzie to miało na działania związane z przeciwdziałaniem aktom wandalizmu w naszych projektach. Słyszeliśmy również od znacznej liczby osób, które popierają tę propozycję jako krok w kierunku poprawy prywatności niezarejestrowanych i zmniejszenia zagrożenia prawnego, jakie stwarza dla naszych projektów ujawnianie adresów IP światu.
Kiedy rozmawialiśmy o tym projekcie w przeszłości, nie mieliśmy jasnego wyobrażenia o kształcie, jaki przybierze ten projekt. Naszym zamiarem było zrozumienie, w jaki sposób adresy IP są pomocne dla naszych społeczności. Od tego czasu otrzymaliśmy wiele opinii na ten temat z wielu rozmów w różnych językach i w różnych społecznościach. Jesteśmy bardzo wdzięczni wszystkim członkom społeczności, którzy poświęcili czas, aby nas uświadomić, jak działa moderacja na ich wiki lub w ich specyficznym środowisku cross-wiki.
Mamy teraz bardziej konkretną propozycję dotyczącą tego projektu, która, mamy nadzieję, pozwoli na niezakłócone działanie większości prac związanych z przeciwdziałaniem wandalizmowi, jednocześnie ograniczając dostęp do adresów IP osobom, które nie muszą ich widzieć.
Chcę podkreślić słowo „propozycja”, ponieważ w żaden sposób nie kształtuje ani nie formułuje ostatecznego werdyktu co do tego, co się stanie. Naszym zamiarem jest zasięgnięcie opinii na temat tego pomysłu – jak myślisz, co się sprawdzi? Jak myślisz, co nie zadziała? Jakie inne pomysły mogą to ulepszyć?
Opracowaliśmy te pomysły podczas kilku dyskusji z doświadczonymi członkami społeczności i udoskonaliliśmy je we współpracy z naszym działem prawnym. Oto zarys:
Checkuserzy, stewardzi i administratorzy będą mogli zobaczyć pełne adresy IP po włączeniu opcji w preferencjach i jeśli zaakceptują, że nie mogą ich ujawniać osobom innym niż także mających dostęp do tej informacji.
Redaktorzy, którzy biorą udział w działaniach przeciwko wandalizmowi, zgodnie z wolą społeczności, mogą otrzymać prawo do wglądu w adresy IP, aby dalej wykonywać swoją pracę. Można to załatwić w podobny sposób, jak uprawnienia administratora na naszych projektach. Zatwierdzenie przez społeczność jest ważne, aby zapewnić, że tylko redaktorzy, którzy naprawdę potrzebują tego dostępu, mogą go uzyskać. Redaktorzy będą musieli mieć konto, które spełnia pewien próg czasu od rejestracji (próg nie został jeszcze ustalony) i liczbę edycji (liczba nie została jeszcze ustalona).
Wszyscy użytkownicy z kontami, które osiągnęły pewien próg czasu od rejestracji (próg nie został jeszcze ustalony) i liczbę edycji (liczba nie została jeszcze ustalona) będą mogli uzyskać dostęp do częściowo zdemaskowanych adresów IP bez konieczności uzyskania dodatkowego uprawnienia. Oznacza to, że pojawi się adres IP z ukrytymi oktetami końcowymi – ostatnią częścią (ostatnimi częściami). Będą mogli to włączyć w preferencjach, gdzie zgodzą się nie udostępniać ich innym osobom, które nie mają dostępu do tych informacji.
Pozostali użytkownicy nie będą mieli dostępu do adresów IP niezarejestrowanych użytkowników.
Dostęp do adresu IP będzie rejestrowany, aby w razie potrzeby można było przeprowadzić kontrolę. Jest to podobne do rejestru, który prowadzimy odnośnie dostępu checkuserów do prywatnych danych. Mamy nadzieję, że w ten sposób zrównoważymy potrzebę prywatności z potrzebą społeczności dostępu do informacji w celu zwalczania spamu, wandalizmu i nękania. Chcemy przekazywać te informacje tym, którzy ich potrzebują, ale potrzebujemy procesu, potrzebujemy tego jako funkcja do samodzielnego włączenia, aby tylko ci, którzy naprawdę tego potrzebują, mogli je zobaczyć, a dostępy muszą być rejestrowane.
Chcielibyśmy poznać Twoją opinię na temat proponowanego podejścia. Przekaż nam swoją opinię na stronie dyskusji.
IP-based identity screenshot
Session-based identity screenshot
.png)