IP-редагування: Поліпшення приватності та зменшення зловживань/Новини
: Нові функції, нові назви і Вікіманія
Новини проєкту
- Формат імен тимчасових облікових записів. Формат імен тимчасових облікових записів буде
~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.
Ми обговорюємо різні варіанти префіксів і будемо проводити тестування їх користувачами. Наші нинішні кандидати (у випадковому порядку) такі:
- Карет (
^) —User:^12345 - Дефіс (
-) —User:-12345 - Тильда (
~) —User:~12345 - Знак оклику (
!) —User:!12345 - Знак питання (
?)[1] –User:?12345 - Префікс року –
User:2023-12345
Чи якийсь із цих варіантів виглядає крутим або жахливим? Будь ласка, залиште свій коментар на сторінці обговорення або на Фабрикаторі.
- ↑ (Хоча знак питання є чудовим позначенням чогось невідомого і є широковпізнаваним, є певні деталі, які ми все ще опрацьовуємо. Наприклад, його треба закодовувати у посиланні як
%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-маскування буде запущено. Ми звертатимемося до наших технічних волонтерів по допомогу з оцінкою змін і мігрування інструментів за потреби. Дещо з цієї планувальної роботи уже почато на Фабрикаторі, і ви можете звертатися до нас там, якщо виникатимуть запитання щодо конкретних завдань.
Наступний допис матиме огляд МЖП (мінімально життєздатного продукту), до якого ми прийшли. Цей МЖП базується на обговореннях, які ми проводили зі спільнотою раніше, на цій сторінці та в інших місцях. Ви можете перечитати ці попередні обговорення, а також попередні оновлення на цій сторінці. Якщо у вас є запитання чи застереження, пишіть нам на сторінці обговорення.
<span id=":_Implementation_Strategy_and_next_steps">
: Стратегія впровадження та подальші кроки
Вітання усім. У нас є оновлення щодо стратегії впровадження 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, то ймовірно, що у багатьох користувачів буде напівпостійна сторінка обговорення, поки вони зумисне цьому не завадять. Іншою перевагою, яку слід відзначити, є те, що повідомлення на сторінках обговорення в будь-якому разі не отримають хибні отримувачі.
.png)
Блокування незареєстрованих редакторів
Поточний стан: Адмін може заблокувати IP-адресу або IP-діапазон напряму. Окрім цього, адміни можуть перетворити це на автоблокування, яке збереже кукі на стороні браузера, що не дасть користувачеві редагувати навіть після зміни IP-адреси. Цей функціонал було впроваджено кілька років тому.
Ідентичність на основі IP: Ситуація зберігається така ж, як зараз. IP маскуються за замовчуванням, але адміни й патрульні з відповідними правами мають до них доступ.
Ідентичність на основі сесії: Цей спосіб впровадження дозволяє нам зберігати поточну можливість блокування IP-адреси. Він також дозволяє виконувати і блокування на основі лише кукі. Це може бути помічним для ситуацій спільного використання пристроїв (як-то у бібліотеці чи комп'ютерному клубі), коли блокування IP-адреси чи діапазону IP-адрес призводить до небажаних побічних збитків. Хочу звернути увагу, що це не спрацює, якщо вандали є досвідченими редакторами і можуть уникати блокувань за кукі. <span id=":_IP_Masking_Implementation_Approaches_FAQ">
: Підходи до впровадження 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, звичайно, і поважаємо наслідки, які це може мати.
<span id=":_Proposal_for_sharing_IP_addresses_with_those_who_need_access">
: Пропозиція поширювати IP-адреси на тих, хто потребує доступу
Привіт усім. Минуло кілька місяців з часу нашого минулого оновлення по цьому проєкту. Ми використали цей час, щоб поговорити з багатьма людьми — як у спільноті, так і в межах Фонду. Ми дуже обачно підійшли до зважування усіх занепокоєнь, озвучених під час дискусій з досвідченими членами спільноти про те, який вплив це матиме на зусилля боротьби з вандалізмом у наших проєктах. Ми також послухали значну кількість людей, що підтримують цю пропозицію як крок до покращення приватності незареєстрованих редакторів і зменшення правових загроз, які ставить перед нашими проєктами розкривання IP на весь світ.
Коли ми говорили про цей проєкт у минулому, у нас не було чіткого уявлення, якої форми цей проєкт набуде. Нашим наміром було зрозуміти, як IP-адреси помічні нашим спільнотам. З того часу ми отримали багато відгуків у цьому напрямку під час численних розмов різними мовами й у різних спільнотах. Ми дуже вдячні усім членам спільноти, які виділили час, щоб просвітити нас про те, як працює модерування у їхніх вікі чи про конкретне кросвікі середовище.
У нас тепер є більш конкретна пропозиція для цього проєкту, яка, ми сподіваємось, дозволить більшості антивандальної роботи тривати без перешкод, при цьому обмежуючи доступ до IP людям, які не мають в них потреби. Я хочу підкреслити слово «пропозиція», оскільки це в жодному разі, вигляді чи формі не фінальний вердикт того, що відбується. Ми намірені отримати відгук від вас про цю ідею: Як ви думаєте, що спрацює? Що, на вашу думку, не спрацює? Які інші ідеї можуть бути кращими?
Ми розробили ці ідеї під час кількох дискусій із досвідченими членами спільноти і вдосконалили їх разом з нашим юридичним відділом. Ось, що вийшло:
- Чек'юзери, стюарди й адміни мають могти бачити повні IP-адреси, увімкнувши цю можливість у налаштуваннях, де вони погоджуються не розголошувати їх тим, хто не має доступу до цієї інформації.
- Редактори, які займаються противандальною діяльністю, згідно з рішенням спільноти, можуть отримати права на перегляд IP-адрес, щоб продовжувати свою роботу. Це може мати відбуватися приблизно так само, як з адмінправами. Схвалення спільноти важливе для забезпечення доступу до адрес лише тих редакторів, яким це справді потрібно. Редакторам треба буде мати обліковку, зареєстровану певний час тому (про поріг ще треба вирішити) і з певним мінімумом кількості редагувань (про число ще треба вирішити).
- Усі користувачі з обліковими записами, зареєстрованими певний час тому (про поріг ще треба вирішити) і з певним мінімумом кількості редагувань (про число ще треба вирішити), зможуть отримати доступ до частково демаскованих IP без отримання дозволу. Це означає, що IP-адреса буде видима, з прихованим прикінцевим октетом(-ами) — останніми частинами. Це буде доступне як налаштування, яке можна увімкнути, погодившись не розголошувати цю інформацію тим, хто не має до неї доступу.
- Усі інші користувачі не матимуть доступу до IP-адрес незареєстрованих користувачів.
Доступ до IP-адрес буде журналюватися, щоб коли і якщо з'явиться потреба в ретельній перевірці, її можна було провести. Це подібне до журналів, які ми ведемо для чек'юзерського доступу до приватних даних. У такий спосіб ми намагаємося збалансувати потребу приватності із потребою спільнот у доступі до інформації для боротьби зі спамом, вандалізмом та переслідуваннями. Ми хочемо давати інформацію тим, хто її потребує, але нам треба процес, нам треба, щоб це була функція за увімкненням, щоб інформацію бачили лише ті, кому вона справді треба, і нам треба, щоб були журнали отримання доступу.
Ми хотіли б почути ваші міркування про цей пропонований підхід. Будь ласка, залишайте свої відгуки на сторінці обговорення.
- Як ви думаєте, що спрацює?
- Що, на вашу думку, не спрацює?
- Які інші ідеї можуть це покращити?