: 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.
Старіші новини
: 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.
Формат імен тимчасових облікових записів. Формат імен тимчасових облікових записів буде ~YYYY-nnnnn-nnn. YYYY — це рік створення тимчасового облікового запису. N-послідовність є унікальним ідентифікатором тимчасового імені користувача. Наприклад, тимчасовий обліковий запис, створений у 2023 році, може виглядати так: ~2023-27459-041. Префікс року допомагає визначити вік тимчасового облікового запису. Це дає інформацію патрульним або будь-кому, хто хоче спілкуватися з цим редактором. Ми прийняли рішення після обговорень на сторінці обговорення у вікі й у Фабрикаторі (T337103). Дякуємо всім, хто брали участь у цих розмовах!
Зміни в команді та очікуваний час початку впровадження. Команда інструментів боротьби з переслідуваннями об'єдналася із Командою інструментів довіри та безпеки. Новосформована команда називається Продукти довіри та безпеки. Вона матиме розширену сферу діяльності. Ця зміна структури може вплинути на часові рамки цього проекту. У нас буде більше новин, коли ми розробимо план дій для нової команди. Наші поточні прогнозовані терміни для цього проекту такі:
Впровадження у testwiki — січень 2024
Впровадження у перших пілотних вікі — з березня 2024
Сторінка частих запитань. Ми створили сторінку частих запитань (FAQ). Ми розширимо й оновимо її у найближчі тижні і місяці.
Новини про Вікіманію і зміну назви проєкту. На Вікіманії в Сінгапурі ми представили новини проєкту. Ви можете подивитися слайди презентації. Також є запис повної презентації, доступний на YouTube. На Вікіманії ми використовували колишню назву проекту, IP Masking. Після цього ми вирішили змінити її на «тимчасові облікові записи для незареєстрованих редакторів», або ж просто тимчасові обліковки. Вона представляє наші зміни простими словами, без технічної метафори.
Нові функції
Глобальне блокування. Ми працюватимемо над глобальним блокуванням для зареєстрованих і тимчасових користувачів. Наразі глобальне блокування працює тільки для IP-адрес і діапазонів. Уже давно існує запит на розширення цієї функції, щоб мати змогу блокувати і користувачів теж. Ми будемо визначати цю функцію і розвивати її упродовж наступних декількох місяців. Ви можете стежити за оновленнями у завданні на Фабрикаторі (T17294).
Глобальний внесок користувача. Ми впровадимо функцію глобального внеску користувача у MediaWiki. Зараз вона існує як інструмент GUC. Наша зміна дозволить користувачам легше бачити внесок облікового запису у різних проєктах. Це робитиметься на спеціальній сторінці. Це буде особливо корисно, коли увійдуть в дію тимчасові обліковки. Технічні подробиці див. у T337089.
: План IP-маскування
Як і обіцяли, ось оновлення щодо того, як працюватиме IP-маскування.
Тут йтиметься про зміни як для незареєстрованих, так і зареєстрованих редакторів.
Ми хочемо одразу відзначити, що досі є багато відкритих питань і невирішених пунктів.
Це наш початковий план, і в нього не входить геть усе, що ми хочемо досягти упродовж цього проєкту.
По ходу справи ми знаходимо нові ділянки раніше не передбаченої роботи.
Ваші відгуки допоможуть нам зрозуміти, що ще ми можемо зробити, щоб IP-маскування було простішим для наших спільнот.
Це оновлення зроблене у форматі ЧаПів, щоб прийдешні зміни були чіткими й зрозумілими.
Що змінює IP-маскування для незалогіненого редактора?
Наразі до того, як незалогінені користувачі завершують редагування, їм повідомляють, що їхні редагування будуть записані під їхньою IP-адресою.
У майбутньому перш ніж незалогінені користувачі завершать редагування, вони отримуватимуть сповіщення, що їхні редагування будуть записані під тимчасовим обліковим записом.
Іменем такої обліковки буде число, яке зростатиме з кожним новим обліковим записом.
Обліковий запис буде прив'язаний до куків, що живуть у браузері користувача.
Поки куки існують, користувач буде продовжувати працювати під тим же обліковим записом, і їхні редагування будуть записуватися під ним.
IP-адреси користувача можуть змінюватись, але тимчасовий обліковий запис не змінюватиметься доти, доки існують куки.
Тимчасовий обліковий запис, згенерований в одній вікі, також працюватиме в інших вікі, де користувач може робити свій внесок.
Як виглядатимуть тимчасові імена користувачів?
Ми ще не знаємо.
Наші початкові макети передбачали використання астериска (зірочки) як префікса, а далі порядковий номер.
(Приклад: *12345.)
Ці макети наведено нижче.
Але як звернули увагу деякі волонтери, астериск не є гарним вибором через яскравий баг у MediaWiki.
Ми обговорюємо різні варіанти префіксів і будемо проводити тестування їх користувачами.
Наші нинішні кандидати (у випадковому порядку) такі:
Чи якийсь із цих варіантів виглядає крутим або жахливим?
Будь ласка, залиште свій коментар на сторінці обговорення або на Фабрикаторі.
↑(Хоча знак питання є чудовим позначенням чогось невідомого і є широковпізнаваним, є певні деталі, які ми все ще опрацьовуємо. Наприклад, його треба закодовувати у посиланні як %3F. Це кодування не має бути проблемою, але воно зашпортуватиме користувачів, які звикли вводити URL вручну.)
Як довго тримаються тимчасові імена користувачів?
Через деякий час після першого редагування (орієнтовно через рік) або після очищення кешу, термін дії куки автоматично закінчиться.
Однак наявні редагування далі будуть підписані цим іменем користувача.
Після того як термін дії старого імені користувача вийде, користувач отримає новий тимчасовий обліковий запис, якщо редагуватиме знову.
Що змінює IP-маскування для патрульного?
Обмежена видимість IP-адрес
Найбільша зміна полягає в тому, що IP-адреси більше не будуть видимі публічно.
Будь-хто, хто не має облікового запису або не відповідає необхідним критеріям доступу до IP-адрес (див. оновлення від юристів), не зможе бачити IP-адреси.
Щоб пом'якшити вплив на патрулювання, ми будемо покращувати функцію IP-інфо.
Це включатиме дані з сервісу Spur.
Отримання доступу до IP-адрес
Разом з Юридичним відділом Фонду ми розробили нові настанови.
Вони визначають, хто зможе мати доступ до IP-адрес і як.
Користувачі, які відповідають вимогам, зможуть увімкнути собі доступ до IP-адрес на сторінці Спеціальна:Налаштування.
Дивіться детальніше про те, як працюватиме цей функціонал.
Такий доступ буде журналюватися і буде доступним для обмеженої групи користувачів (чек'юзери, стюарди, Trust & Safety).
Кращі канали комунікації з тимчасовими редакторами
Тимчасові облікові записи будуть прив'язані до кук у браузері.
Доти, доки кука існує, редагування користувача записуватимуться під тим же тимчасовим обліковим записом.
Власники тимчасових облікових записів зможуть отримувати сповіщення про повідомлення на сторінці обговорення так само, як зареєстровані користувачі.
Ми сподіваємося, що це уможливить краще спілкування з тимчасовими користувачами.
Це також може вирішити деякі довготривалі проблеми, про які повідомляли спільноти (див. T278838).
Документування IP-адрес вандалів
Можливість документування IP-адрес користувачів з поганими намірами на сторінках-переліках вандалів залишатиметься, як і зараз.
Однак слід обережно ставитись до нерозкриття IP-адрес інших тимчасових користувачів.
При обговоренні можливих недобрих намірів, варто використовувати приховування, якщо підозра на вандалізм не підтвердилася.
Більше про це можна почитати у настанові.
Доступні інструменти для патрулювання
Як і IP-редактори, тимчасових користувачів можна перевіряти і патрулювати в інструментах Special:Block, Special:Checkuser та Special:Investigate.
Додатково можна використовувати функцію IP-інфо, де є інформація про IP-адресу, з якої збережено певну версію.
Ми розробляємо настанови для Хмарних інструментів і ботів, що отримують доступ до IP для патрулювання.
Оновлення про це буде опубліковано невдовзі.
Що станеться з наявними IP-адресами на наших сайтах?
Наявні IP-адреси, які зараз записані у наших вікі, залишаться без змін.
Редагування, зроблені після впровадження IP-маскування, будуть записуватися в історії під тимчасовими іменами користувачів.
Оскільки ми розгортаємо IP-маскування поступово, це означатиме, що ця зміна відбудеться у різних вікі в різний час.
Як працюватиме функціонал розкриття IP-адрес?
Користувачі, що мають доступ до IP-адрес, могтимуть розкривати IP-адреси тимчасових облікових записів.
Макети того, як працюватиме цей функціонал:
Що станеться з інструментами і ботами, яким необхідні IP-адреси для роботи?
Ми працюємо над осмисленням впливу на волонтерські інструменти.
Над цим завданням працює наша команда, а також команди Research та Engineering.
Далі ми працюватимемо з Юридичним відділом, щоб визначити, які інструменти зможуть і далі користуватися доступом до IP-адрес і за якими правилами вони можуть працювати.
Ми опублікуємо оновлення на цій сторінці, як тільки матимемо план дій.
Плани розгортання
Ми плануємо тестувати IP-маскування повільно, щоб дати достатньо часу на відгуки і тестування спільнотою.
Ми прагнемо, щоб це розгортання не заважало процесам спільнот.
Іншим нашим пріоритетом є уникнення небажаних наслідків для здоров'я наших спільнот.
Ми визначили метрики, за якими будемо спостерігати під час розгортання змін.
Наразі шукаємо спільноти, які хотіли б бути кандидатами для тестового (пілотного) запуску IP-маскування.
Ми розглядаємо такі критерії як кількість редагувань з IP у спільноті, терміновість антивандальної роботи, розмір проєкту та потенціал деструктивного впливу.
Ми опублікуємо на цій сторінці ще одне оновлення про обраних кандидатів ближче до запуску IP-маскування.
Якщо ви хотіли б, щоб ваша спільнота потестувала запуск IP-маскування, будь ласка, прийміть рішення спільнотою і повідомте нас на сторінці обговорення.
<span id=":_Refocusing_work_on_IP_Masking">
: Зміна фокусу роботи над IP-маскуванням
Привіт усім. Ми офіційно зміщуємо фокус нашої роботи над ключовим проєктом IP-маскування, оскільки завершили першу фазу функції IP-інфо та інших пов'язаних проєктів. Ми переходимо до подальшого технічного планування і визначення, що нам треба буде змінити, коли IP-маскування буде запущено. Ми звертатимемося до наших технічних волонтерів по допомогу з оцінкою змін і мігрування інструментів за потреби. Дещо з цієї планувальної роботи уже почато на Фабрикаторі, і ви можете звертатися до нас там, якщо виникатимуть запитання щодо конкретних завдань.
Наступний допис матиме огляд МЖП (мінімально життєздатного продукту), до якого ми прийшли. Цей МЖП базується на обговореннях, які ми проводили зі спільнотою раніше, на цій сторінці та в інших місцях. Ви можете перечитати ці попередні обговорення, а також попередні оновлення на цій сторінці. Якщо у вас є запитання чи застереження, пишіть нам на сторінці обговорення.
Вітання усім. У нас є оновлення щодо стратегії впровадження IP-маскування.
Перш за все, дякуємо усім, хто завітали на цю сторінку й запропонували свої відгуки. Від багатьох із вас ми почули, що цю сторінку важко читати і ми працюємо над тим, щоб це виправити. Ми хочемо щиро подякувати вам за те, що витратили час на читання інформації тут і на сторінці обговорення. Ми врахували кожен коментар на сторінці обговорення, перш ніж прийняти рішення про план впровадження.
Хочемо перш за все сказати також, що все ще залишається багато відкритих запитань. Перед нами довгий шлях у цьому проєкті, і ми б хотіли, щоб ви продовжували висловлювати свою точку зору у подальших таких дискусіях, коли вони будуть. Якщо ви ще не читали, будь ласка, перегляньте цей допис про те, хто й далі матиме доступ до IP-адрес, перш ніж читати далі.
Ми отримали змішані відгуки від спільноти про дві запропоновані ідеї імплементації без чіткого консенсусу по жодній з них. Ось деякі цитати зі сторінки обговорення:
Думаю, що шлях ідентичності на основі IP кращий для малих вікі, бо навряд чи два анонімні користувачі матимуть однакову IP, а для вандала змінити IP буде складніше, ніж почитати куки.
Система на основі сесії виглядає краще, вона б полегшила комунікацію з анонімними редакторами. Я адмін в англійській Вікіпедії й основна моя взаємодія з IP-редакторами — відкидання й попередження їх щодо вандалізму. У кількох останніх випадках навіть не хотілося витрачати час на попередження, бо не було схоже, що потрібна людина його отримає. В одному випадку я намагався/лася вести розмову про якусь пропоновану зміну, і говорив/ла з кількома IP-адресами, і було не ясно, чи це та сама людина, і доводилося весь час про це перепитувати.
Як адмін у німецькомовній Вікіпедії із двох описаних тут шляхів (ідентичність на основі IP vs. ідентичність на основі сесії) я чітко віддаю перевагу шляху на основі IP. Скористатися анонімним режимом браузера або очистити куки надто просто (я теж роблю це весь час); зміна вашої IP-адреси принаймні вимагає більше зусиль, а у нас уже є політика проти використання відкритих проксі. Я погоджуюся із Beland, що шлях ідентичності на основі сесії, ймовірно, полегшить комунікацію з порядними незареєстрованими користувачами, але він якийсь не надто міцний.
Я за шлях на основі сесії. Він більше цінує можливість ідентифікувати й комунікувати з легітимними анонімними редакторами. Однак у той же час нам треба опції фільтра зловживань, які дадуть змогу визначати численні нові сесії з тієї самої IP. Це може бути добросовісним випадком (наприклад, зі школи), але радше всього позначатиме зловживання або бота. Одна функція, яку я не бачу, щоб згадували досі: коли користувач сесії хоче створити обліковий запис, то за замовчуванням наявний ідентифікатор сесії має бути перейменовано на вибране ними ім'я. Нам треба могти бачити й/або асоціювати новоназваного користувача з попередньою діяльністю у цій сесії.
Я схиляюся до ідентичностей на основі IP, навіть у разі шифрування, бо куки видаються більш складними, щоб мати з ними справу, і надто надокучливими, щоб весь час закривати їхні набридливі спливні повідомлення (дуже звично у Європі). Мушу згадати, що я віддаю перевагу тому, що до цього дня людина може користуватися Вікіпедією без cookies, якщо тільки їй не треба входити в систему й редагувати під її іменем користувача.
Можливість робити блокування виключно на основі сесії на додачу до наявних блокувань за IP+сесією була б цікавим апґрейдом. Можливість комунікувати з користувачами IPv6 через їхню сесію замість IP-адрес, які весь час змінюються, теж була б перевагою.
Підсумовуючи, основний аргумент проти шляху на основі сесії в тому, що cookies легко позбутися і користувач може дуже легко змінювати свою ідентичність.
А основні аргументи про шляху на основі IP такі:
метод шифрування може бути скомпрометовано, що скомпрометує і самі IP-адреси
цей підхід не дає перевагу покращеної комунікації з незареєстрованими редакторами
не дозволяє блокувати на основі сесії (на додачу до блокувань за IP)
У світлі викладеного вище й дискусій із нашою технічною командою щодо доцільності й широких наслідків такої імплементації, ми вирішили зупинитися на шляхові на основі сесії з деякими важливими доповненнями щодо проблеми вилучення користувачами cookies та зміни ними своєї ідентичності. Якщо користувач часто змінює своє ім'я користувача, то ці ідентичності можна буде поєднувати завдяки додатковій інформації в інтерфейсі. Ми все ще працюємо над тим, як достеменно це працюватиме, але це буде подібним до того, як працює виявлення ляльок (з деякою автоматизацією).
Ми все ще працюємо над багатьма технічними деталями і невдовзі матимемо для вас інше оновлення щодо них. Сюди входить документація LTA, комунікація з IP, фільтри зловживань, треті вікі, додатки, користувацькі скрипти, хмарні інструменти ФВМ, обмеження прав IP-глядачів тощо. Ми цінуємо ваші відгуки і запрошуємо залишати будь-які коментарі, які у вас для нас є, на сторінці обговорення.
<span id=":_IP_Masking_and_changes_to_workflows">
: IP-маскування і зміни до процедур
Ми обговорили два різні підходи до IP-маскування, які ми розглядаємо. Як наслідок, ми розробили кілька різних процедур з різними змінами і двома різними способами впровадження.
Зверніть увагу, що в обох альтернативах адміни, стюарди, чек'юзери та користувачі з роллю IP-переглядач зможуть демаскувати IP на сторінках на зразок сторінок нових редагувань та історії версій з метою боротьби з вандалізмом.
Досвід редагування для незареєстрованих редакторів
Поточний стан: Наразі незареєстровані редактори можуть редагувати, не входячи в систему (у більшості вікі). Перед тим, як зробити редагування, вони бачать банер, який повідомляє, що їхня IP-адреса буде публічно записана й опублікована назавжди.
Ідентичність на основі IP: Незареєстровані редактори зможуть редагувати, як і зараз. Перед тим, як зробити редагування, вони побачать повідомлення про те, що їхні редагування будуть підписані зашифрованою версією їхньої IP-адреси. Сама IP-адреса буде видима адміністраторам і патрульним. Вона зберігатиметься упродовж обмеженого періоду часу.
Ідентичність на основі сесії: Подібно до того, що вище, з тією відмінністю, що редактори отримають повідомлення, що їхні редагування будуть підписані автоматично згенерованим іменем користувача.
Знімок екрана для ідентичності-за-IP
Знімок екрана для ідентичності-за-сесією
Комунікація стосовно незареєстрованих редакторів
Поточний стан: Незареєстрованих редакторів називають за їхньою IP-адресою, а якщо вони відомі довготривалими зловживаннями, то їм часто присвоюють ім'я на основі поведінки.
Ідентичність на основі IP: Патрульні й адміни не зможуть називати IP-адреси публічно, але зможуть відсилатися до зашифрованих IP-адрес або імен багаторічних вандалів. Вони можуть ділитися IP з тими, хто також має до них доступ.
Ідентичність на основі сесії: Патрульні й адміни не зможуть називати IP-адреси публічно, але зможуть використовувати автозгенеровані імена користувачів. Вони можуть ділитися IP з іншими, хто має до них доступ. Це допоможе ідентифікувати окремого а́ктора, але також може спантеличувати, якщо за одним іменем користувача буде багато IP, подібно до того, як зараз може бути за одним IP багато людей. Щоб полегшити цю турботу, ми розробляємо інструмент, який дозволить піднімати інформацію про різні IP-адреси, з яких редактор є активним.
Досвід сторінок обговорення для незареєстрованих редакторів
Поточний стан: Незареєстрований редактор може отримувати повідомлення на сторінці обговорення своєї IP. Коли IP-адреса редактора змінюється, вони отримують повідомлення на сторінці обговорення нової IP-адреси. Це розщеплює розмови й ускладнює контакт з конкретними незареєстрованими користувачами.
Ідентичність на основі IP: У цьому способі впровадження це залишається таким же, як зараз. Незареєстровані користувачі отримуватимуть повідомлення на сторінках обговорення своїх зашифрованих IP, а після зміни IP відповідна сторінка обговорення зміниться теж.
Ідентичність на основі сесії: У цьому способі впровадження незареєстровані редактори отримуватимуть повідомлення на сторінці обговорення, що пов'язана з cookie у їхньому браузері. Навіть якщо їхня IP зміниться, це все одно дозволить їм отримувати повідомлення на своїй сторінці обговорення. Якщо cookie у браузері очищено, вони втрачають ідентичність на основі сесії, отримують нове cookie, і нову сторінку обговорення, пов'язану вже з ним. Оскільки IP змінюються частіше за cookie, то ймовірно, що у багатьох користувачів буде напівпостійна сторінка обговорення, поки вони зумисне цьому не завадять. Іншою перевагою, яку слід відзначити, є те, що повідомлення на сторінках обговорення в будь-якому разі не отримають хибні отримувачі.
Сповіщення сторінки обговорення
Блокування незареєстрованих редакторів
Поточний стан: Адмін може заблокувати IP-адресу або IP-діапазон напряму. Окрім цього, адміни можуть перетворити це на автоблокування, яке збереже кукі на стороні браузера, що не дасть користувачеві редагувати навіть після зміни IP-адреси. Цей функціонал було впроваджено кілька років тому.
Ідентичність на основі IP: Ситуація зберігається така ж, як зараз. IP маскуються за замовчуванням, але адміни й патрульні з відповідними правами мають до них доступ.
Ідентичність на основі сесії: Цей спосіб впровадження дозволяє нам зберігати поточну можливість блокування IP-адреси. Він також дозволяє виконувати і блокування на основі лише кукі. Це може бути помічним для ситуацій спільного використання пристроїв (як-то у бібліотеці чи комп'ютерному клубі), коли блокування IP-адреси чи діапазону IP-адрес призводить до небажаних побічних збитків. Хочу звернути увагу, що це не спрацює, якщо вандали є досвідченими редакторами і можуть уникати блокувань за кукі.
Ці ЧаПи допомагають відповісти на деякі ймовірні запитання, які виникнуть у спільноти про різні підходи до впровадження IP-маскування і того, як вони вплинуть на спільноту.
П: Хто зможе бачити IP-адреси після впровадження IP-маскування?
В: Чек'юзери, стюарди й адміни зможуть бачити повні IP-адреси, увімкнувши цю можливість у налаштуваннях, де вони погоджуються не розголошувати їх тим, хто не має доступу до цієї інформації.
Редактори, які беруть участь у боротьбі з вандалізмом, за рішенням спільноти, можуть отримати право бачити IP-адреси задля продовження своєї роботи. Спільноти буде займатися цим правом користувача, як і іншими правами, воно вимагатиме мінімальну кількість та днів редагувань.
Усі користувачі з обліковими записами певного віку з мінімальною кількістю редагувань (ще буде визначена) зможуть отримати доступ до частково демаскованих IP без отримання дозволу. Це означає, що IP-адреса буде видима, з прихованим прикінцевим октетом(-ами) — останніми частинами. Це буде доступне як налаштування, яке можна увімкнути, погодившись не розголошувати цю інформацію тим, хто не має до неї доступу.
Усі інші користувачі не матимуть доступу до IP-адрес незареєстрованих користувачів.
П: Які можливі варіанти технічного впровадження?
В: За останні кілька тижнів ми взяли участь у численних обговореннях технічних можливостей досягнення нашої мети IP-маскування з мінімальним впливом на наших редакторів і читачів. Ми зібрали відгуки від різних команд і поглянули з різних точок зору. Нижче подано два ключові шляхи.
Ідентичність на основі IP: У цьому підході ми зберігаємо усе, як є, але заміняємо наявні IP-адреси на хешовані версії IP. Це зберігає багато наявних процедур, але не передбачає жодних нових вигод.
Ідентичність на основі сесії: За цим підходом, ми створюємо ідентичність для незареєстрованих редакторів на основі кукі браузера, що ідентифікує браузер їхнього пристрою. Кукі залишається, навіть якщо IP-адреса змінилася, тобто сесія не завершується.
П: Як працює шлях ідентичності на основі IP?
В: Зараз незареєстровані редактори ідентифікуються за їхніми IP-адресами. Ця модель працювала для наших проєктів багато років. Користувачі, добре обізнані з IP-адресами, розуміють, що одну IP-адресу можуть використовувати численні різні користувачі, залежно від того, наскільки ця IP-адреса динамічна. Це більш справедливо для IPv6 IP-адрес, ніж IPv4.
Незареєстрований користувач може також змінювати IP-адреси, якщо їде в транспорті чи редагує з іншого місця.
Якщо ми підходимо до IP-маскування із рішенням ідентичності на основі IP, ми збережемо спосіб, в який IP-адреси функціонують зараз, просто замаскувавши їх зашифрованим ідентифікатором. Це рішення збереже IP чіткими, у той же час зберігши приватність користувача. Наприклад, незареєстрований користувач на зразок Користувач:192.168.1.2 може показуватися як Користувач:ca1f46.
Переваги цього підходу:
Зберігає наявні процедури і моделі з мінімальним впливом
Недоліки цього підходу:
Не пропонує жодних переваг у світі, що швидко рухається в бік більш динамічних / менш корисних IP-адрес
П: Як працює шлях ідентичності на основі сесії?
В: Цей шлях полягає у створенні нової ідентичності для незареєстрованих редакторів на основі кукі у їхньому браузері. За цим підходом є автозгенероване ім'я користувача, яким підписуються редагування і дії. Наприклад, Користувач:192.168.1.2 може отримати ім'я Користувач:Anon3406.
За цим підходом сесія користувача триватиме стільки, скільки у них є кукі, навіть якщо змінюється IP-адреса.
Переваги цього підходу:
Прив'язує ідентичність користувача до браузера пристрою, надаючи більш стійкий спосіб комунікації з ними.
Ідентичність користувача не змінюється зі зміною IP-адреси
Цей підхід може надати спосіб незареєстрованим користувачам отримати спосіб до певних налаштувань, які зараз доступні лише зареєстрованим користувачам
Цей підхід може надати спосіб незареєстрованим користувачам перетворитися на постійний обліковий запис, при цьому зберігши свою історію редагувань
Недоліки цього підходу:
Значна зміна порівняно з поточною моделлю того, чим є незареєстрований редактор
Ідентичність незареєстрованого користувача існує стільки, скільки існує кукі у браузері
Вандали в режимі приватності або ті, хто вилучає кукі, отримають нову ідентичність без зміни своєї IP
Може вимагати переосмислення деяких практик та інструментів спільнот
П: Чи віддає Фонд перевагу якомусь із шляхів чи підходів?
В: Ми віддамо перевагу підходу з ідентичністю на основі сесії, оскільки це відкриє багато можливостей на майбутнє. Ми змогли б зайнятися проблемами комунікації, які в нас існують уже двадцять років. Якщо хтось вилучає кукі, щоб отримати нову ідентичність, то IP все одно видима усім активним борцям з вандалізмом, які мають нове право користувача. Ми розуміємо, що вилучити кукі простіше, ніж змінити IP, звичайно, і поважаємо наслідки, які це може мати.
: Пропозиція поширювати IP-адреси на тих, хто потребує доступу
Привіт усім. Минуло кілька місяців з часу нашого минулого оновлення по цьому проєкту. Ми використали цей час, щоб поговорити з багатьма людьми — як у спільноті, так і в межах Фонду. Ми дуже обачно підійшли до зважування усіх занепокоєнь, озвучених під час дискусій з досвідченими членами спільноти про те, який вплив це матиме на зусилля боротьби з вандалізмом у наших проєктах. Ми також послухали значну кількість людей, що підтримують цю пропозицію як крок до покращення приватності незареєстрованих редакторів і зменшення правових загроз, які ставить перед нашими проєктами розкривання IP на весь світ.
Коли ми говорили про цей проєкт у минулому, у нас не було чіткого уявлення, якої форми цей проєкт набуде. Нашим наміром було зрозуміти, як IP-адреси помічні нашим спільнотам. З того часу ми отримали багато відгуків у цьому напрямку під час численних розмов різними мовами й у різних спільнотах. Ми дуже вдячні усім членам спільноти, які виділили час, щоб просвітити нас про те, як працює модерування у їхніх вікі чи про конкретне кросвікі середовище.
У нас тепер є більш конкретна пропозиція для цього проєкту, яка, ми сподіваємось, дозволить більшості антивандальної роботи тривати без перешкод, при цьому обмежуючи доступ до IP людям, які не мають в них потреби.
Я хочу підкреслити слово «пропозиція», оскільки це в жодному разі, вигляді чи формі не фінальний вердикт того, що відбується. Ми намірені отримати відгук від вас про цю ідею: Як ви думаєте, що спрацює? Що, на вашу думку, не спрацює? Які інші ідеї можуть бути кращими?
Ми розробили ці ідеї під час кількох дискусій із досвідченими членами спільноти і вдосконалили їх разом з нашим юридичним відділом. Ось, що вийшло:
Чек'юзери, стюарди й адміни мають могти бачити повні IP-адреси, увімкнувши цю можливість у налаштуваннях, де вони погоджуються не розголошувати їх тим, хто не має доступу до цієї інформації.
Редактори, які займаються противандальною діяльністю, згідно з рішенням спільноти, можуть отримати права на перегляд IP-адрес, щоб продовжувати свою роботу. Це може мати відбуватися приблизно так само, як з адмінправами. Схвалення спільноти важливе для забезпечення доступу до адрес лише тих редакторів, яким це справді потрібно. Редакторам треба буде мати обліковку, зареєстровану певний час тому (про поріг ще треба вирішити) і з певним мінімумом кількості редагувань (про число ще треба вирішити).
Усі користувачі з обліковими записами, зареєстрованими певний час тому (про поріг ще треба вирішити) і з певним мінімумом кількості редагувань (про число ще треба вирішити), зможуть отримати доступ до частково демаскованих IP без отримання дозволу. Це означає, що IP-адреса буде видима, з прихованим прикінцевим октетом(-ами) — останніми частинами. Це буде доступне як налаштування, яке можна увімкнути, погодившись не розголошувати цю інформацію тим, хто не має до неї доступу.
Усі інші користувачі не матимуть доступу до IP-адрес незареєстрованих користувачів.
Доступ до IP-адрес буде журналюватися, щоб коли і якщо з'явиться потреба в ретельній перевірці, її можна було провести. Це подібне до журналів, які ми ведемо для чек'юзерського доступу до приватних даних. У такий спосіб ми намагаємося збалансувати потребу приватності із потребою спільнот у доступі до інформації для боротьби зі спамом, вандалізмом та переслідуваннями. Ми хочемо давати інформацію тим, хто її потребує, але нам треба процес, нам треба, щоб це була функція за увімкненням, щоб інформацію бачили лише ті, кому вона справді треба, і нам треба, щоб були журнали отримання доступу.
Ми хотіли б почути ваші міркування про цей пропонований підхід. Будь ласка, залишайте свої відгуки на сторінці обговорення.
Знімок екрана для ідентичності-за-IP
Знімок екрана для ідентичності-за-сесією
.png)