안녕하세요,
스팸으로 인해 사용자가 신고될 때, 해당 플래그에 동의하고 사용자를 정지하는 과정에서 매번 입력하지 않아도 되도록 사유 목록에 “스패머” 옵션이 기본적으로 선택되어 있으면 좋겠습니다.
또한, 사용자를 스패머로 신고할 때 계정을 복원하고 싶을 이유가 전혀 없으므로, 기본 정지 기간이 "영구"로 자동 선택되도록 해야 합니다.
안녕하세요,
스팸으로 인해 사용자가 신고될 때, 해당 플래그에 동의하고 사용자를 정지하는 과정에서 매번 입력하지 않아도 되도록 사유 목록에 “스패머” 옵션이 기본적으로 선택되어 있으면 좋겠습니다.
또한, 사용자를 스패머로 신고할 때 계정을 복원하고 싶을 이유가 전혀 없으므로, 기본 정지 기간이 "영구"로 자동 선택되도록 해야 합니다.
호기심이 생기네요 – 스팸 게시물을 그냥 삭제하고 차단하는 건 아니죠? 여러분의 처리 과정이 궁금합니다.
@HAWK 님, 안녕하세요. 사용자가 게시물을 스팸으로 신고했을 때 제가 검토(Review) 인터페이스에서 처리하는 상황입니다. 인터페이스에서는 “이 게시물이 스팸입니까?”와 같은 질문을 하고, 저는 예 > 게시물 삭제 및 사용자 정지 옵션(문구는 기억에 의존해 대략적으로 기억한 것입니다)을 선택합니다. 그러면 스크린샷에 보이는 팝업이 나타납니다.
하지만 제가 모더레이터/관리자로서 직접 스팸 게시물을 발견하더라도 단순히 게시물을 삭제하는 것만으로는 부족합니다. 사용자가 계속 스팸을 하지 않도록 계정도 정지해야 합니다. 이를 위해 /admin/users/.../... 경로에서 해당 사용자의 계정 설정을 열고 정지 버튼을 누릅니다. 그러면 사유와 기간을 입력하도록 요구하는 동일한 팝업이 나타납니다.
또 다른 옵션은 스팸머 계정을 단순히 삭제하는 것입니다. 이렇게 하면 해당 이메일/IP 주소가 새 계정에 가입하는 것도 차단할 수 있어, 영구 정지보다는 더 나은 해결책이 될 수 있습니다.
정지는 전통적으로 일시적인 조치입니다. 예를 들어, 학교에서 문제를 많이 일으킨 학생은 1주 또는 1개월 동안 정학 처분을 받을 수 있지만, 이는 퇴학과는 완전히 다릅니다. 퇴학은 다시 잘해볼 기회를 주지 않고 졸업할 수 없게 만드는 것이죠.
혹시 모를 경우를 대비해 말씀드리자면, 사용자 삭제 옵션은 사용자 관리 페이지 하단에 있으며, 익명화 옵션 바로 옆에 있습니다. 익명화 옵션은 사용자의 게시글은 유지하되 계정은 종료하는 방법입니다.
안녕하세요 @anon65426961, 그건 하나의 옵션이지만 보고서 검토 워크플로우와 통합되어 있지 않습니다. 또한 저는 정지된 계정을 데이터베이스에 유지하고 IP를 차단하지 않는 방식을 개인적으로 선호합니다. 1) Gmail과 같이 가입에 상당한 노력이 필요한 이메일 주소를 사용하는 스팸머들이 계정을 삭제한 후 같은 이메일로 다시 가입하는 것을 방지하기 위해 노력 장벽을 높이고 싶고, 2) IP는 나중에 합법적인 사용자에게 할당될 수 있는 대규모 공유 IP 블록에 있는 경우가 많아서 차단하고 싶지 않기 때문입니다.
오, 흥미롭네요. 보고서 검토 워크플로우에 대해 저는 아무것도 모릅니다.
계정을 데이터베이스에서 삭제하는 대신 정지 상태로 유지하는 것이 더 나은 아이디어인 것 같습니다. 이메일/IP를 차단하지 않고 계정만 삭제하는 옵션은 있지만, 이메일만 차단하는 옵션은 없습니다. IP와 이메일을 동시에 차단하는 옵션만 있거든요(이미 아시는 대로, 다른 스레드에서 이메일만 차단하는 기능을 요청하셨었죠). 아마도 추후에 추가할 수 있는 옵션일 수 있습니다.
이와 관련된 논의가 있는 다른 스레드가 여기에 있습니다:
@jordan.vidrine 이 드롭다운에 Spammer를 추가하는 것만으로 꽤 쉬운 수정이 될 것 같은데요. 반대 의견 있으신 분 계신가요?
이 의견에 매우 공감합니다. 어떤 경우에는 넓은 지역 내의 모든 사용자가 동일한 IP로 보일 수 있습니다. 그리고 전문 버전을 결제하지 않으면 Cloudflare 보호를 받는 서비스는 실제 IP를 노출하지 않습니다. 따라서 IP 차단 기능을 사용하는데 주저하게 되며, 실수로 우리의 우수한 사용자에게 심각한 피해를 줄 수 있기 때문입니다.
Cloudflare가 Cf-Connecting-IP 헤더에 실제 IP를 전송한다고 생각하는데, 최근에 변경된 건가요?
그래요? 저는 이걸 잘 못 하거든요. 제가 일하는 서버 유지보수 담당자가 이렇게 말해줬어요. 실제 IP를 전달하려면 추가 요금이 발생한다고 했어요.
말씀하신 사이트에서 이 기능이 빠져 있었던 건가요?
Discourse 인스턴스가 제공된 템플릿을 사용하도록 올바르게 구성되었을 경우, 모든 CloudFlare 계정은 연결된 IP 주소를 확인할 수 있습니다.
최근 Akismet에 의해 플래그가 지정된 게시물에 대해 모더레이터가 올바른 조치를 취할 수 있도록 개선 작업을 진행했습니다.
가시성을 위해 GitHub에서 수행된 작업 내용을 복사/붙여넣기합니다:
이 변경 사항이 무엇인가요?
여러 건의 피드백에 따르면, Akismet에 의해 플래그가 지정된 게시물의 검토 작업이 혼란스럽다고 합니다. 사람이 스팸으로 표시한 게시물과 컴퓨터가 스팸으로 표시한 게시물 사이에 개념상 큰 차이가 없으므로, 이 PR은 코어에서 스팸으로 표시된 게시물에 대해 가지고 있는 옵션들과 더 일치하도록 옵션을 조정합니다.
변경 전
변경 후
오래된 글이지만, 아직 다른 분들이 이 맥락을 제공하지 않은 것 같아…
저는 소켓 퍼펫(spam) 스팜러를 식별하기 위해 그들의 모든 활동 기록을 쉽게 접근할 수 있도록 계정을 (영구적으로) 정지 상태로 유지합니다. 저는 거의 10개의 계정이 명확히 동일한 행위자임을 식별했으며, 이를 활용하여 새로운 스팸이 들어올 때마다 이를 차단하는 데 도움을 받았습니다. 만약 단순히 (예를 들어) IP를 차단했다면 그들은 IP를 변경했을 것이고, 저는 스팜러를 식별하는 데 사용하는 수많은 신호 중 하나로 이를 활용할 수 없었을 것입니다. 실제로 이는 제 사이트를 새로운 스팸으로부터 자유롭게 유지하는 데 매우 유용한 도구가 되어 왔습니다.
좋은 지적입니다! 해결하기 쉬운 문제가 아니죠.
개인적으로는 조직적인 일회성 스팸(drive-by spam)과 다른 형태의 개인적 부적절한 행동을 구별하는 것이 매우 중요하다고 생각합니다. 또한 계정 탈취 가능성에 대해서도 매우 신중해야 합니다. 여러 개의 스팸 게시글을 남긴 후 계정이 삭제되어, 이전에 작성했던 수많은 실질적인 게시글들이 함께 사라지는 경우를 본 적이 있습니다. 계정은 동일했지만, 저에게는 분명히 다른 사람이었습니다.在这种情况下, 계정 정지나 익명화가 훨씬 바람직했을 것입니다.
인근 스레드에서는 TL2 이상 계정을 충분한 숙고 없이 삭제하는 것은 현명하지 않다는 제안의 힌트가 있습니다. 물론 스팸을 게시하는 TL0 계정은 훨씬 더 낮은 임계값을 적용해야 합니다.
가이드라인과 사용자 인터페이스가 이러한 가능성을 반영하는 것이 좋을 것입니다: 어떤 일이 벌어지고 있을 수 있으며, 어떤 대응이 좋은지 보여주는 것이죠.
스팸을 증오하고 극단적인 조치로 대응하고 싶다고 표현하는 사람들(아마도 트라우마를 겪은 사람들)을 본 적이 있습니다. 하지만 그들이 놓치는 점은, 그들이 '사람’에 대해 말하고 있지만 실제로는 '계정’에 대해 행동하며, 계정에는 역사(기록)가 있다는 것입니다.
알려주셔서 감사합니다. 이러한 기능이 일반 “스팸” 신고 처리에도 적용될 수 있는지 고려해 보셨나요?