Uk:Вандалізм

From OpenStreetMap Wiki
Jump to navigation Jump to search
Вандалізм у вигляді вигаданого міста

Вандалізм — це умисне ігнорування норм, погоджених спільнотою OpenStreetMap, щодо редагування даних зокрема. Звичайні огріхи та помилки правок не є вандалізмом, але для їхнього усунення можуть бути застосовані деякі з інструментів, що використовуються для боротьби з вандалізмом.

Перегляньте сторінку Зловживання для ознайомлення з деякими прикладами порушення прийнятих норм спільноти.

Вандалізм та інші види поганого редагування

Графіті у вигляді GPS-треків (3 назви орієнтирів)

Вандалізм у чистому розумінні був би актом розміщення "графіті" на мапі для розваги або для заподіяння умисної шкоди OpenStreetMap. Порівняно не часто можна спостерігати випадки чистого вандалізму. OpenStreetMap — це неприбутковий рух з добрими намірами надати вільні дані, які "належать" спільноті. І в цілому люди, як правило, це поважають.

Існує кілька типів поганого редагування, які дуже близькі до вандалізму, частіше схожі на дитячі забавки, але вимагають тих самих видів захисту. Серед них:

  • Порушення авторських прав
  • Суперечки в базі OpenStreetMap (війни правок)
  • Суперечки на wiki
  • Недоречне використання ботів
  • Стійка агресивна поведінка
  • Спам
  • Цілеспрямоване видалення або пошкодження даних, які вважаються правильними
  • Навмисне додавання некоректних даних
  • Неналежні імпорти

Звичайні огріхи та помилки правок не є вандалізмом, хоч і можливо, деякі мають бути 'скасовані'.

Реагування на вандалізм

Інформація для початківців

Якщо ви бачите помилку або якесь пошкодження мапи (зловмисні чи ні), ви можете розгубитися, бути не впевнені, що і як слід робити. У такому випадку зверніться до інших маперів та попросіть про допомогу. Але, можливо, інформація на цій сторінці допоможе.

Загальні принципи

Відповідно до обговорення [1] у вересні 2009 точка зору була такою:

(адреса з англійського оригіналу сторінки, схоже, помилкова)

  • Ми сподіваємось, що усі учасники постійно намагаються робити корисні, точні та обґрунтовані зміни.
  • Ми повинні бути впевнені, що кожен учасник робить дані кращими, а не навпаки. Якщо конкретний внесок є сумнівним, ми зобов’язуємось передати його іншим учасникам для розгляду та реагування.
  • Ми усвідомлюємо, що люди припускаються помилок, потребують часу на навчання, а новачки часто потребують підтримки і вони відгукнуться на неї.
  • Ми можемо просити, але не вимагати від учасників коментувати їхні правки та створювати корисні особисті сторінки з деякими відомостями про їхні зацікавлення та знання. Тоді скасовування змін будуть менш імовірними, а особа з ймовірніше отримає допомогу, якої потребує.
  • Якщо за кимось помічені дивні правки, до них спочатку треба поставитись як до сумлінних, але уважно переглянути і за потреби обговорити їх з іншими.
  • Якщо значна кількість правок може бути однозначно доведена як зловмисна, образлива, наклепницька або вважається, що вона принесе проєкту погану славу, тоді відповідні правки можуть бути скасовані негайно без дискусії і без 100% перевірки решти змін в наборі.
  • Якщо правки сумнівні, але не визнані невірними, тоді варто зв’язатись з особою для отримання додаткової інформації. Якщо ми не отримуємо розумної (або взагалі ніякої) відповіді, а сумнівні правки тривають і не врівноважуються великою кількістю однозначно позитивних правок, тоді нам варто пошукати способи довести щонайменше одну шкідливу правку, щоб вирішити в дискусії з іншими доречність скасування набору змін, або навіть усіх наборів змін даної особи.
  • Учасник, визнаний проблемним, надалі потребує лише поверхневого догляду за його наступними правками щодо скасування його майбутніх наборів змін.
  • Якщо проблема не зникає, ми накладаємо на таких маперів "віртуальний бан", де правки скасовуються без огляду на заслуги, доки особи не зв’яжуться з системним адміністратором і не сповістять, що вони подорослішали та хочуть отримати ще один шанс.
  • Коли дехто робить погані правки у будь-якій частині світу, він повинен очікувати на глобальну реакцію, тому що навряд чи хтось може призвести до безладу в Ірландії та робити гарну роботу в Ісландії, і майже ніхто не буде розбиратися що коїлося в їхніх головах — швидше буде захищено гарну роботу інших учасників від шкоди, в результаті якої вона могла б зникнути, лише сподіваючись, що деякі корисні правки були також зроблені поміж нісенітниці.
  • Люди, які скасовують роботу інших людей, повинні вміти продемонструвати, що скасування є обґрунтованими та пропорційними проблемі.
  • Іноді 'порожні'('null') правки — такі, з якими нічого не можна вчинити, хіба що 'торкнутися' елементу, — зроблені помилково, редактором або є корисними для оновлення областей. Щоправда, велика кількість 'порожніх' правок розцінюватиметься як руйнівна поведінка.

Звичайне скасування

Якщо вандалізм має локальний характер і вплив на спільноту обмежений, тоді здійсніть ввічливий прямий запит до особи через повідомлення OSM, припускаючи добрі наміри та почекайте відповіді одну-дві доби. Якщо адекватна відповідь не отримана, проблему можна обговорити у відповідному списку розсилки (зазвичай, локальному, національному або регіональному), або з довіреними особами. Якщо доведено, що деякі правки є контрпродуктивними і корисні зміни не очевидні, тоді сумнівні набори змін мають бути скасовані.

Термінове скасування

Якщо значна кількість правок однозначно трактується як зловмисна, образлива, наклепницька або вважається, що вона принесе проєкту погану славу, тоді важливо відповісти негайно і скасувати їх, паралельно задаючи учаснику питання. Також належить одночасно зв’язатись з Data Working Group. Об’єкти, які було зачеплено після первісних поганих змін вимагають складніших методів їх скасування, отже, якщо у вас недостатньо навичок для роботи з такими інструментами зверніться по допомогу до спільноти або Data Working Group.

Тимчасове блокування

Якщо після звернення до учасника з боку інших маперів через обговорення його наборів змін або через персональні повідомлення, він не виходить на контакт та не припиняє свою діяльність, Data Working Group може накласти тимчасове блокування на такого учасника. Це не є ні презумпцією вини, ні вигнанням з проєкту. Скоріше, це міра, щоб привернути увагу мапера, оскільки він (вона) повинні увійти на сайт OSM і прочитати повідомлення про блокування, перш ніж вони зможуть продовжувати завантажувати зміни на сайт.

Блокування може накладатись на час від 0 до 96 годин. Вони також мають можливість вимагати від користувача входу та ознайомлення з повідомленням про блокування перед його зняттям, незалежно від часу закінчення терміну дії блокування. Члени DWG часто накладають 0-годинні блокування, лише для того, щоб учасник ознайомився з повідомленням, якщо він не виходить на контакт. Історію блокувань можна переглянути тут.

Постійне блокування

Ознайомтесь з OSM Foundation ban policy для отримання докладної інформації.

Управління

По можливості локальна спільнота OpenStreetMap має розв'язувати проблеми вандалізму через вищезгадані процеси.

Data Working Group

Основна стаття: Data working group

Data Working Group — група, уповноважена Фундацією мати справу з серйознішими проявами вандалізму та звітувати перед правлінням на щомісячних зустрічах. У рідкісних випадках, коли підхід через взаємодію зі спільнотою не працює, про проблему доповідають в data working group (data@osmfoundation.org).

До Data Working Group потрібно звертатись у випадках, коли потрібно прибрати дані з історії редагування об’єктів.

Розробка

Існує низка можливих інструментів та методів, які можуть бути використані для розв’язання питань вандалізму. Серед них:

  • Білі списки
  • Відкат даних – Дозволити спільноті виконувати таке завдання, використовуючи перевірені інструменти
  • Видалення даних – Дозволити спільноті виконувати таке завдання, використовуючи перевірені інструменти
  • Відкат змін
  • Видалення історії – Потребує привілеїв вищого рівня
  • Відкати
  • Дані з історією

Виявлення

Основна стаття: Detect Vandalism

Існують інструменти, які можна використовувати для відкату певних наборів змін допоки об’єкти з них не зазнали подальших змін. Наразі такі інструменти використовувати важко, потрібно знати багато технічних тонкостей для роботи з ними, щоб не наробити ще більших проблем.

Виявлення випадків вандалізму в OSM є не тривіальним завданням через їх широкий спектр, поширення та вплив на проєкт. OSMCha – один з таких інструментів, який допомагає виявляти вандалізм.

Існує кілька підходів до автоматизованого виявлення вандалізму, які, як правило, належать до двох категорій: один орієнтований на набір змін, інший – на користувача. Але, як і у випадку з будь-якою системою виявлення, матимемо або помилкові спрацьовування, або пропускатимемо «розумних» вандалів.

Виявлення наборів змін

Підхід орієнтований на виявлення наборів змін покладається на сканування наборів змін на предмет нечестивої поведінки, на перевірку метаданих наборів змін і, можливо, фактичних об’єктів або природи застосованих теґів. Один із загальноприйнятих методів використовує обмеження на кількість об’єктів, відредагованих, доданих чи вилучених. Приклад програми в псевдокоді:

for changeset in diff file:
    if more than 1000 objects are added:
        flag as a potential import
    if more than 1000 objects are modified:
        flag as a potential mechanical edit
    if more than 1000 objects are deleted:
        flag as a potential vandal

Цей тип сканування покладається на думку, що користувачі, як правило, не редагують велику кількість об’єктів під час звичайного мапінгу. Але, у наведеному вище прикладі, усі події позначені як "потенційні", оскільки дуже часто є обґрунтовані пояснення для здійснення такої кількості дій (наприклад, санкціонований імпорт, скасування неправильних редагувань тощо). Він також не виявив жодного дрібного вандалізму та будь-якого вандалізму, розділеного на кілька наборів змін.

У підході до аналізу наборів змін, теґи також можуть виявляти потенційно погану поведінку. Перелік захищених авторським правом даних як джерела, як правило, має діяти як червоний прапор, хоча деякі користувачі, не знайомі з типовим джерелом фонових знімків, наприклад Bing, можуть зазначати перерахувати поширений товарний знак (наприклад, Google, Garmin), що призводить до помилкового виявлення. Використання дуже застарілих або незвичних редакторів, додавання дуже довгих значень теґів, включаючи безліч сторонніх теґів набору змін, та інші способи поведінки – це приклади, коли використання теґів для виявлення поганих редагувань може переважувати очікування.

Інша складова підходу аналізу наборів змін — це перевірка геопросторових властивостей об’єктів. Додані або змінені об’єкти можуть порівнюватись зі зразками, що містять смайлики, літери та написи, зображення анатомічних органів та різні каракулі для перевірки на схожість з ними, та чи схожі вони на графіті.

Виявлення вандалів

Підхід пов’язаний з аналізом поведінки учасників. Чи зробив мапер 300 змін через 10 хвилин після реєстрації? Чи всі його правки були вилученням даних? Такий аналіз має на меті оцінку поведінки кожного окремого користувача на відміну від аналізу властивостей доданих об’єктів.

Погляд з точки зору права

Багато країн мають закони щодо протидії кіберзлочинам, які стосуються «змін даних в комп'ютерних системах, що таким чином, спричиняють їх пошкодження» або щось подібне. На поточний момент не відомо жодного випадку притягнення до кримінальної відповідальності або навіть засудження за вандалізм в OSM, але теоретично ці норми права можуть бути застосовані до тих, хто постійно додає "графіті" в OSM, особливо, якщо учасника про це попереджали, та яких накладають тимчасові або довготривалі блокування.

Дивіться також

Зовнішні ресурси