비슷하다는 점은 이해하지만, 다른 토론에서 언급된 문제들이 이 문제와 관련이 있습니다:
그런데, 관리자일 때 정상적으로 접근할 수 없는 기밀 대화에 대한 링크가 실제로는 접근 금지 상태임을 알 수 있는 방법이 없습니다. 이것은 어제 우리에게 떠올라 이 주제를 시작하게 만든 하나의 사례일 뿐이며, 관리자와 참가자의 역할이 분리되지 않을 때 문제가 될 수 있는 경우입니다.
더욱이, Discourse 팀이 모두 관리자가 되는 경향이 있다는 점을 볼 수 있는데, 이는 수평적 초권력을 만들어내고, 일반적인 사용과 특권 있는 사용을 구별하는 문화 형성에 도움이 되지 않습니다. 모든 커뮤니티가 수평적이지는 않으며, 때로는 관리자 권한을 가진 기술 담당자들이 포럼의 모든 것에 대해 신뢰할 수 없을 수 있습니다. 그리고 이는 경계 사례가 아닙니다: root가 모든 것을 보고 할 수 있다는 것은 시스템의 초기부터 컴퓨터 시스템에 내장되어 있는 것입니다. 권한은 분명 책임이 따르지만, 특히 괜찮은 것과 접근 금지 상태를 구별할 수 없을 때 선의만으로는 충분하지 않은 경우가 있습니다.
일반 계정과 관리자 계정을 처리하기 위한 “다른 브라우저 프로필 사용” 솔루션은 매우 실용적이지 않습니다, 특히 우리가 모두 손에 도구를 가질 수 있는 것에 익숙해지기 때문입니다. 관리자 기능이 필요할 때마다 새로운 브라우저를 실행하는 것은 매우 번거로울 수 있습니다(모든 사람이 자신의 머신에서 유휴 리소스를 차지하는 것을 좋아하거나 감당할 수 있는 것은 아닙니다). 또한, 특권화된 BOFH 상황이 발생하는 것을 방지하지도 못합니다.
시대는 변합니다. 여기서는 우연히 다른 사람들의 삶에 영향을 미친 기밀 정보에 접근한 관리자가 있었는데, 그들은 그렇게 해서는 안 되었습니다. 이는 프라이버시 침해입니다. 보안 문제입니다.
잠재적인 복잡성은 이해하지만, 핵심 문제는 여전히 남아 있으며 어떤 방식으로든 해결되어야 할 것입니다. 제 생각에는 코드 베이스가 성숙해졌으므로 이제 이 질문을 재검토하고, 제안된 접근 방식이 실행 가능한지 평가하는 것이 유용할 것입니다.
맞습니다! 이러한 종류의 (경계 침범) 문제에 대한 경고와 보호 장치가 유용할 것입니다.
기존 플러그인에 대해:
- GitHub - discourse/discourse-anonymous-moderators · GitHub 가 유용할 수 있지만, 이메일 처리를 위한 최근 변경(Enabling e-mail normalization by default)이 이를 변경할 수 있습니다 – 기본 설정이 없음을 신뢰하는 것은 문제가 될 수 있습니다.
- GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias · GitHub 는 _게시물 작성_에만 제한됩니다.
위에서 언급한 모든 이유를 들어, 고전적이고 잘 알려진 sudo 은유를 사용하여 참가자와 관리자 사이를 정말로 깨끗하게 분리하는 것을 선호합니다.