Пожалуйста, добавьте «спаммер» как причину для блокировки пользователя

Привет,

Небольшое неудобство: когда пользователя сообщают за спам, при согласии с флагом и приостановке аккаунта в списке причин должен быть заранее выбран вариант «спаммер», чтобы нам не приходилось вводить его каждый раз.

Также, когда помечаем пользователя как спаммера, я не могу придумать причины, по которой кто-то захотел бы восстановить аккаунт, поэтому по умолчанию период приостановки должен автоматически устанавливаться на «навсегда».

8 лайков

Мне интересно — вы не просто удаляете и блокируете спамеров через спам-пост? Хотелось бы узнать о вашем процессе.

8 лайков

Привет @HAWK, это происходит, когда пользователи отмечают пост как спам, и я обрабатываю это в интерфейсе проверки. Система задаёт вопрос вроде «Этот пост — спам?», и я выбираю опцию Да > Удалить пост и приостановить учётную запись (текст приблизительный, по памяти), после чего появляется всплывающее окно, показанное на моём скриншоте.

Но даже если я сам, как модератор или администратор, замечу спам-пост, я не просто удалю его, а также приостановлю учётную запись, чтобы пользователь не продолжал спамить. Для этого я открываю настройки учётной записи пользователя по адресу /admin/users/.../... и нажимаю там кнопку Приостановить, что вызывает то же самое всплывающее окно, где нужно указать причину и срок приостановки.

3 лайка

Другой вариант — просто удалить аккаунт спамера. Это также позволяет заблокировать его адрес электронной почты или IP-адрес, чтобы он не мог зарегистрировать новый аккаунт. Похоже, это более подходящее решение, чем бессрочная блокировка.

Блокировка традиционно носит временный характер. Например, если ученик создаёт много проблем в школе, его могут отстранить от занятий на неделю или месяц. Но это совершенно не то же самое, что исключение из школы, когда человеку не дают второго шанса исправиться и закончить обучение.

На случай, если вы не знали: опция удаления пользователя находится внизу страницы администрирования пользователей, прямо рядом с опцией анонимизации. Анонимизация позволяет сохранить посты пользователя, но при этом закрыть его аккаунт.

3 лайка

Привет, @anon65426961, это вариант, но он не интегрирован с рабочим процессом проверки отчётов. Кроме того, я лично предпочитаю оставлять заблокированные учётные записи в базе данных и не блокировать их IP-адреса. Во-первых, это может повысить порог усилий для спамеров, использующих адреса регистрации, такие как Gmail, для которых требуется значительная работа при регистрации, чтобы они не использовали тот же адрес повторно после удаления их учётной записи. Во-вторых, IP-адреса часто находятся в крупных общих пулах, которые позже могут быть назначены легитимным пользователям, и я не хочу их блокировать.

3 лайка

О, интересно, я ничего не знаю о рабочем процессе проверки отчетов.

Кажется, что лучше было бы оставлять аккаунты в базе данных в статусе «заблокирован», вместо их удаления. Есть опция удаления аккаунта без блокировки email/IP, но нет опции блокировки только email — блокируются и IP, и email (как вы уже знаете и просили добавить возможность блокировать только email в той другой теме). Возможно, это опция, которую они смогут добавить в будущем.

Есть ещё одна тема с обсуждением этого здесь:

4 лайка

@jordan.vidrine Похоже, что это довольно простое решение — просто добавить Spammer в этот выпадающий список. Есть какие-либо возражения?

8 лайков

Я полностью согласен с этим. В некоторых случаях все пользователи в большом регионе имеют один и тот же IP-адрес. А если вы не используете профессиональную версию, сервис под защитой Cloudflare не раскрывает реальный IP-адрес. Поэтому я не решаюсь использовать функцию блокировки по IP — это может серьёзно навредить нашим отличным пользователям по ошибке.

6 лайков

Полагаю, Cloudflare отправляет реальные IP-адреса в заголовке Cf-Connecting-IP. Не менялось ли это недавно?

2 лайка

Да? Я не очень хорошо в этом разбираюсь. Это то, что мне сказала администратор сервера, с которой я работаю. Помню, она говорила, что за передачу реального IP-адреса взимается дополнительная плата.

1 лайк

Этого не хватало на сайтах, о которых вы говорите?

2 лайка

Все аккаунты CloudFlare могут видеть IP-адрес подключившегося пользователя, при условии, что экземпляр Discourse правильно настроен для использования предоставленного шаблона.

3 лайка

Мы недавно упростили работу модераторов с постами, помеченными Akismet как нежелательные.

Для наглядности приводим описание изменений из GitHub:

Что изменилось?

Несколько отзывов указывают на то, что действия по проверке постов, помеченных Akismet, вызывают путаницу. Поскольку концептуально разница между постом, помеченным как спам человеком, и компьютером, минимальна, этот запрос на слияние (PR) приводит варианты действий в соответствие с теми, что предусмотрены для постов, помеченных как спам в основной версии.

До

akismet-spam-before

После

akismet-spam-after

4 лайка

Я знаю, что это старый пост, но не уверен, что кто-то ещё предоставил этот контекст…

Я оставляю их подвешенными (навсегда), чтобы все записи об их действиях были легко доступны для выявления спамеров, использующих подставные аккаунты. Я уже идентифицировал около 10 аккаунтов как принадлежащих одному и тому же лицу и использовал эту информацию для блокировки нового спама по мере его появления. Если бы я просто (например) блокировал IP-адрес, они бы сменили IP, и у меня не было бы этого сигнала среди множества других, которые я использую для выявления спамеров. На практике это оказалось чрезвычайно полезным инструментом для поддержания чистоты моего сайта от нового спама.

2 лайка

Отличная мысль! Это непростая задача.

Лично я бы очень хотел отличать организованный спам «на бегу» от других видов индивидуального проступка. Также я был бы крайне осторожен в отношении возможности взломанных аккаунтов: я видел случаи, когда аккаунт удаляли после нескольких спам-сообщений, при этом терялись многие предыдущие содержательные посты. Это был тот же аккаунт, но, очевидно (для меня), не тот же человек. Временная блокировка или анонимизация были бы гораздо предпочтительнее.

В соседней теме есть намёк на мысль, что удалять аккаунты уровня TL2 и выше без размышлений — не лучшая идея. Конечно, для аккаунтов уровня TL0, публикующих спам, порог должен быть значительно ниже.

Было бы полезно, если бы руководство и интерфейс пользователя отражали возможные ситуации: что может происходить и какой может быть адекватный ответ.

Я видел, как люди (возможно, травмированные) выражали ненависть к спамерам и призывали действовать с крайней жестокостью. То, что они упускают, — это то, что они имеют в виду людей, но действуют в отношении аккаунтов, а у аккаунтов есть история.

Спасибо за предупреждение. Рассматривалось ли включение этих функций в стандартную обработку жалоб на «спам»?

1 лайк