RU:Вандализм
Вандализм — это преднамеренное игнорирование принятых норм сообщества OpenStreetMap. Простые недоразумения и ошибки редактирования не являются вандализмом, но они должны быть исправлены с помощью тех же инструментов, которые используются для устранения последствий вандализма.
Вандализм и другие типы плохого редактирования
Вандализмом в самом узком смысле этого слова были бы действия по добавлению граффити на карту, совершённые по причинам ребяческой забавы, а также целенаправленная попытка повредить OpenStreetMap. Относительно редко можно видеть примеры вандализма в узком смысле этого слова. Так как OpenStreetMap является некоммерческим проектом, а географические данные принадлежат сообществу, то это является хорошим доводом в его пользу. Многие люди склонны уважать его за это.
Имеются многочисленные другие типы плохого редактирования, которые очень похожи на вандализм, совершённые по различным причинам, не связанным с ребяческой забавой, но заканчивающиеся потребностью в тех же самых средствах защиты. Они включают:
- Нарушение авторского права.
- Споры в базе данных OpenStreetMap (войны правок).
- Споры в вики.
- Неуместное использование ботов.
- Массовое редактирование данных (например, добавление или изменение тегов).
- Постоянное недопустимое поведение.
- Спам.
- Целенаправленное удаление или деградация данных, которые, как известно, являются правильными.
- Необсуждённый импорт.
Простые недоразумения и ошибки редактирования не являются вандализмом, хотя некоторые из них должны быть отменены.
Юридическое состояние
Многие страны имеют законы о киберпреступлениях, которые включают деяние «Изменение данных в компьютерной системе, нанёсшее ущерб» или что-то подобное. Нет никаких известных случаев, когда на кого-то подали бы в суд или даже осудили бы за вандализм в OpenStreetMap, но в теории эти законы могли бы применяться даже к тем, кто постоянно добавляет граффити в OpenStreetMap, особенно если им явно сообщили, что они наносят ущерб OpenStreetMap, делая так.
Обнаружение
Обнаружение вандализма в OpenStreetMap — это сложная проблема, поскольку типы вандализма, перечисленные выше, имеют широкий диапазон по типу, степени и эффекту. Один из самых лёгких способов обнаружения вандализма, заключающийся в использовании кнопки «История» на главной странице сайта и изучении правок в месте нахождения, выполняется легче при осмотре ограниченной области, например небольшого города или маленького муниципального района.
Существуют множественные подходы к автоматизированному обнаружению вандализма, которые обычно попадают в две категории: анализ пакета правок и анализ пользователя. Но, как и в случае любой системы обнаружения, анализ также часто будет давать ложные срабатывания и будет пропускать изощрённых вандалов.
Анализ пакета правок
Анализ пакета правок полагается на сканирование пакетов правок на недопустимое поведение путём проверки метаданных пакета правок и, возможно, фактических объектов или типа используемых тегов. Один общий метод использует пределы на количество изменённых, добавленных или удалённых объектов. Пример программы на псевдокоде:
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, могут перечислять общие торговые марки (Generic trademark generic trademark в Википедии), например, Google, Garmin, создавая ложную достоверность. Использование устаревших или необыкновенных редакторов, добавление очень длинных значений тегов, включая множество посторонних тегов пакета правок, являются другими примерами анализа тегов для обнаружения плохих правок.
Другой компонент подхода анализа пакета правок заключается в исследовании пространственных характеристик объектов в пакете правок. Добавленные или изменённые объекты могли бы быть сравнены с образцами лиц смайликов, вытянутых слов, анатомических особенностей и бессмысленных рисунков, чтобы проверить насколько они похожи на граффити.
Анализ пользователя
Анализ пользователя заключается в исследовании характера редактирования человека. Сделал ли пользователь 300 правок за 10 минут соединения? Являются ли все правки нового пользователя удалениями? Этот подход стремится изучить поведение человека вместо изучения характеристик объектов.
Противодействие вандализму
Общие рекомендации
Точка зрения обсуждения в talk в сентябре 2009 была:[1]
- Мы должны надеяться, что все участники должны всё время пытаться делать хорошие, точные и хорошо исследуемые изменения.
- Нам необходимо обеспечить, чтобы каждый участник делал набор данных лучше, но не хуже. Если вклад сомнителен, мы уведомляем об этом других участников, чтобы исследовать его и отреагировать.
- Мы должны знать, что люди делают ошибки, нуждаются во времени на изучение и что новые участники часто нуждаются в поддержке.
- Мы можем просить, но не требовать, чтобы участники добавляли комментарии к их пакетам правок и создали полезную личную страницу с некоторыми деталями об их интересах и знаниях. Выполнение этого делает отмену правок менее вероятным и более вероятным, что человеку будут помогать, если это нужно.
- В случае если кажется, что кто-то делает странные изменения, сначала следует предположить «добросовестность участника», но следует внимательно наблюдать и обсуждать с другими, если это нужно.
- Если существенное количество правок точно являются злонамеренными, непристойными, клеветническими или считается, что они могли бы испортить проекту репутацию, тогда связанные пакеты правок могут быть отменены немедленно без обсуждения и без проверки 100% остальных пакетов правок.
- Если правки сомнительны, но нет доказательств, что они неверны, то нам следует связаться с человеком и попросить некоторую дополнительную информацию. Если мы не получаем разумный ответ (или не получаем никакого ответа) и сомнительные правки продолжаются без большого количества явно позитивных правок, то мы должны доказать, по крайней мере, одну плохую правку, а затем можем прийти к решению в обсуждении с другими, что уместно отменить рассматриваемый пакет правок и потенциально все пакеты правок этого человека.
- Как только кто-то был идентифицирован как проблемный участник, тогда только требуется выполнить краткий осмотр последующих правок перед откатом (отменой) пакетов правок.
- Если проблема продолжается, тогда мы помещаем на проблемных участников «виртуальную блокировку» в каком-либо месте, где их правки отменяются без осмотра качества до тех пор, пока люди не входят в контакт с системным администратором и говорят, что они имеет серьёзные намерения и просят ещё один шанс.
- Если кто-то совершает плохие правки в любой части мира, тогда они могут рассчитывать на глобальный ответ, потому что кажется очень маловероятным, чтобы кто-то создавал бы беспорядок в Ирландии и делал бы хорошую работу в Исландии, и я не уверен, что я хотел бы выяснять, что происходит в их голове - я лучше предпочту защищать хорошую работу других от вреда, который позволяет хорошей работе быть испорченной, чем некоторые хорошие правки, сделанные среди плохих.
- Люди, которые отменяют работу других людей, должны быть способны продемонстрировать, что отмена была хорошо обоснована и пропорциональна проблеме.
- Иногда случаются «пустые правки», то есть такие, которые не имеют никакой цели, кроме как «затронуть» элемент, сделанные по ошибке, программой-редактором или с целью обновить область. Однако, большое количество «пустых правок» будет рассматриваться как недопустимое поведение.
Это просто список некоторых идей. Не все из них реализованы в настоящее время.
Обычный откат
Если по площади вандализм небольшой и воздействие на всё сообщество ограничено, тогда с человеком входят в прямой вежливый контакт через личные сообщения на сайте или обсуждения пакетов правок, принимая хорошие намерения, и ждут ответ в течение 24-48 часов. Если компетентный ответ не получен, тогда эта проблема может быть обсуждена в списке рассылки электронной почты (местном, национальном или региональном) или с доверенными людьми. Если доказано, что некоторые правки причиняют вред и полезность правок не очевидна, тогда рассматриваемые пакеты правок следует откатить.
Возможно, уместно использовать журнал откатов. Для русскоязычных участников существует специальная тема на форуме.
Быстрый откат
Если доказано, что значительное число правок является злонамеренным, непристойным, клеветническим или может испортить репутацию проекта, тогда важно отреагировать немедленно и сначала выполнить откат, а потом уже задавать участнику вопросы. Возможно, имеет смысл в это же время войти в контакт с рабочей группой по данным. Объекты, которые были затронуты, начиная с первой плохой правки, могут потребовать сложного метода отката, так что если вы не знакомы с этими инструментами, то обратитесь, пожалуйста, за помощью к сообществу или рабочей группе по данным.
Временная блокировка
Если после установки контакта с участником через личные сообщения и/или через обсуждения пакетов правок, этот участник отказывается отвечать и не меняет своё поведение, тогда рабочая группа по данным может временно заблокировать рассматриваемого участника. Это не является ни презумпцией вины, ни изгнанием из проекта. Скорее всего, это мера для привлечения внимания участника, так как он должен войти на сайт OpenStreetMap и прочитать сообщение о блокировке, прежде чем он сможет продолжить загрузку правок через API.
Блокировки бывают различной продолжительности до окончания от 0 до 96 часов. Они также имеют возможность требовать, чтобы участник вошёл на сайт и прочитал сообщение о блокировке прежде, чем она закончится, независимо от времени её окончания. Члены рабочей группы по данным будут часто помещать блокировки на 0 часов на учётные записи с условием прочтения сообщения о блокировке в качестве первоначальной меры к конфликтующему и не отвечающему на вопросы участнику. История блокировок доступна здесь.
Постоянная блокировка
Смотрите OSM Foundation ban policy для дополнительной информации.
Инструменты и ссылки
Есть доступные инструменты для отката правок в отдельных пакетах правок до тех пор, пока в дальнейшем сделанные правки не имеют каких-либо указанных признаков. Эти инструменты в настоящее время трудно использовать, так как они требуют хороших технических знаний для того, чтобы работать без причинения дополнительного ущерба.
Управление
Где возможно, местное сообщество OpenStreetMap должно противодействовать вандализму через вышеупомянутые процессы.
Рабочая группа по данным
- Основная статья: Data working group
Рабочая группа по данным уполномочена фондом OpenStreetMap бороться с более серьезным вандализмом и отчитывается перед советом фонда OpenStreetMap на ежемесячных встречах совета. В редких случаях, когда подход сообщества не работает, о проблеме нужно сообщить рабочей группе по данным. Для этого есть несколько способов, перечисленных в порядке предпочтения:
1. Письмо на адрес (data@osmfoundation.org)
Плюсы:
- это сообщение получат все члены DWG.
- это сообщение автоматически будет зарегистрировано в системе OTRS (система обработки заявок клиентов), которая используется DWG. Для членов DWG это самый удобный способ (требует меньше всего действий).
Минусы:
- иногда почта не доходит до DWG. Возможно, что это только российская проблема.
2. Личное сообщение пользователю OSMF Data Working Group
Плюсы:
- это сообщение получат все члены DWG.
- это сообщение автоматически будет зарегистрировано в OTRS.
Минусы:
- для связи с участником членам DWG придётся пользоваться системой личных сообщений от своего имени и копировать вручную все сообщения в OTRS (чтобы они были доступны другим членам DWG). Личные сообщения видны только получателю и отправителю. Члены DWG не могут читать личные сообщения.
3. Жалоба через очередь модерации (через кнопку "Сообщить ..." на сайте).
Плюсы:
- это сообщение получат все члены DWG.
Минусы:
- члену DWG придётся вручную создать обращение в OTRS.
- члену DWG придётся пользоваться системой личных сообщений от своего имени и копировать всю переписку вручную в OTRS.
Есть ещё один минус, о котором нужно сказать подробнее. На сайте есть следующие типы пользователей:
- анонимные (например, могут создать заметку)
- обычные
- с ролью "Модератор" (члены DWG)
- с ролью "Администратор" (члены OWG)
На сайте есть две очереди модерации:
- очередь модераторов
- очередь администраторов
Через сайт можно сообщить о:
- пользователе - сообщение попадёт в очередь модерации для администраторов
- записи в дневнике - сообщение попадёт в очередь модерации для администраторов
- комментарии в дневнике - сообщение попадёт в очередь модерации для администраторов
- заметке - сообщение попадёт в очередь модерации для модераторов
То есть, если вы сообщаете о заметке, то ваше сообщение сразу увидят члены DWG в своей очереди. Но если вы сообщаете о пользователе, то ваше сообщение не попадёт к DWG. Оно попадёт к администраторам. Администраторы должны просмотреть это сообщение. Если оно относится к DWG, то администраторы вручную переведут сообщение в очередь модераторов. Только тогда члены DWG увидят ваше сообщение. Иногда обращения в DWG долго "висят" у админов и не видны в DWG. Члены DWG могут перенаправить сообщение обратно админам (например, если нужна какая-либо помощь админов вроде анализа IP-адресов).
4. Личное сообщение члену DWG. Этот способ работает, но другие члены DWG не увидят это сообщение.
Минусы:
- члену DWG придётся вручную создать обращение в OTRS.
- члену DWG придётся пользоваться системой личных сообщений от своего имени и копировать всю переписку вручную в OTRS.
- этот конкретный член DWG может не иметь свободного времени и сутками не подходить к компьютеру.
Развитие
Есть множество возможных инструментов и методов, которые могли бы использоваться, чтобы справляться с проблемами вандализма. Возможные инструменты включают:
- Белые списки
- Откат данных — Позволяет сообществу решать эту задачу, используя инструменты, которые были протестированы
- Удаление данных — Позволяет сообществу решать эту задачу, используя инструменты, которые были протестированы
- Откат правки
- Удаление истории — Требует привилегий высокого уровня
- Откаты
- Данные с прежней историей
