사회적, 문화적 요인 때문일 수 있으며, 저는 그러한 맥락에서 제 생각을 공유해 보고자 합니다. 누구를 판단하려는 의도는 아닙니다.
일부 사용자는 변화에 대한 저항이 크고 검열이 심한 국가에 거주하고 있습니다(이러한 환경에서는 자유를 다른 관점이나 문화로부터 직접적으로 위협하는 일들이 당연시될 수 있습니다).
하지만 Discourse는 전 세계 최고의 포럼 플랫폼이 되고자 하며, 저는 이러한 주제를 논의하는 것이 모두에게 항상 좋은 일이라고 생각합니다.
공간을 제공해 주셔서 감사합니다. 사용 사례에 해를 끼치지 않으면서도 사용자 및 커뮤니티의 Discourse에 대한 신뢰도 훼손되지 않도록 재검토되기를 바랍니다 
우리는 대규모 커뮤니티에서 발생할 수 있는 매우 심각한 악용을 방지하고, 사용자가 Discourse에 부여하는 신뢰를 해치지 않기를 논의하고 있습니다.
중앙 집중식 단일 데이터베이스를 사용하는 시스템에서 관리자도 데이터를 가질 수밖에 없으므로, 맹목적인 포럼이나 관리자가 데이터를 갖지 못하게 하는 것에 대해서는 논의하지 않습니다.
이 질문은 '예, 하지만’에 해당하며 ‘예 또는 아니오’ 논쟁에 속하지 않는다고 생각합니다.
죄송하지만 그것이 제 토픽의 핵심이 아닙니다. 다른 토픽을 열어 원하는 대로 질문하셔도 됩니다.
제 의도를 오해하신 것 같습니다. 그것이 바로 이 주제의 핵심입니다.
impersonate 기능을 제거한다고 해서 이를 방지할 수 있는 것은 아니며, 없어도 같은 방식으로 쉽게 실행할 수 있습니다. impersonate를 제거하는 주요 효과는 계정 관련 문제를 해결하는 것이 더 어려워지는 것입니다.
아니요. 데이터베이스를 수동으로 관리하는 것은 다른 사람이 클릭하고 게시물을 올리는 것과 완전히 다릅니다.
이 기능은 개발자 테스트를 넘어선 명확한 설명이나 보편적인 사용 사례 없이도 기본 Discourse 인스턴스에서 활성화되어 있습니다.
제가 이 스레드에서 말하려는 것이 바로 이것입니다. 다시 한번 죄송하지만, 다른 스레드를 열거나 원하는 대로 생각하셔도 됩니다.
데모를 실행해 보고 관리자 기능을 몇 가지 시도해 보세요. 누군가의 말을 변경하거나 그들의 메시지를 읽기 위해 데이터베이스 접근 권한이나 임의의 사용자 계정으로 로그인할 필요가 없습니다.
1클릭이든 10클릭이든 큰 차이는 없으며, 여전히 가능합니다. 저는 재택근무를 자주 하는 사람을 알고 있는데, 회사의 내부 시스템에 접속하기 위해 약 6개의 비밀번호, 2단계 인증 ID 및 기타 복잡한 절차를 거쳐야 합니다. 하지만 그에게 몇 분밖에 걸리지 않습니다.
당신과 당신의 사용자가 개발자와 관리자를 신뢰하느냐, 아니면 신뢰하지 않느냐의 문제입니다. 그리고 시스템에 대한 신뢰가 없다면, 시스템을 사용하는 방식도 달라질 가능성이 높습니다.
물론 당신의 관점에서 보면 그렇습니다
제 관점에서는 이것이 Discourse가 프라이버시와 자유를 고려하고 있음을 보여줍니다.
데이터베이스를 수동으로 관리하는 것은 개발자에게는 괜찮습니다. 모든 관리자가 impersonate를 사용할 수 있는 단일 버튼은 불필요하며 적절하지 않습니다.
중간책으로, impersonate가 사용되었음을 투명하게 보여주는 간단한 시스템을 도입할 수 있습니다.
즉, 옵션을 고려하거나 이 문제를 당신의 관점만으로 축소할 수 있습니다.
다시 답변하기 전에 내 최근 게시물들을 다시 읽어봐 주세요. 관리자는 impersonate나 데이터베이스 접근 없이도 여전히 모든 작업을 수행할 수 있습니다. impersonate와 대부분의 관리자 작업은 이미 로그에 기록되어 있으므로, 다른 관리자가 악의적인 관리자를 추적할 수 있는 기록이 필요합니다.
또는 단순히 Encrypt 플러그인으로 그 공개된 기능을 닫아두는 방법도 있습니다. 결국 사람들이 문제점으로 인식할 수 있는 기능에 대해 선택지를 제공하는 것은 좋은 일입니다. 이는 보안감, 안전감 등에 대한 잘못된 착각을 줄여줄 수 있습니다. Adama의 인용을 빌리자면, 유일한 보안 시스템은 다른 시스템과 네트워크로 연결되지 않은 오프라인 터미널입니다.
찬성과 반대 모두 타당한 관점(PoV)을 가지고 있습니다. 모든 당사자에게 최선의 해결책은 타협입니다. Encrypt 플러그인은 PM/DM 서브시스템에 대한 프라이버시 레이어를 갖추려는 욕구, 그리고 일부에서는 가능한 요구사항을 충족하기 위해 개발되었을 것으로 추정됩니다.
아마도 코어에 옵션으로 포함되지 않는다면, 마음의 평화를 원하는 셀프 호스티드(Self-Hosted) 시스템 사용자를 위해 원하는 효과를 달성하는 플러그인 형태가 될 수 있을 것입니다.
커스텀 배지를 만드는 스크립트는 관리자에게만 직접 접근 권한이 있으므로 비활성화할 필요가 없다고 말할 수 있습니다. 그러나 이는 Root에서 활성화해야 합니다. 만약 이것이 변경되지 않았다면요.
완벽한 이상적인 상황이라면, 사람들은 직분에 있는 사람들을 신뢰할 수 있어야 한다고 동의합니다. 불행히도 신뢰는 때때로 잘못 놓여지고, 오해가 발견되었을 때 비로소 그 진상이 드러나는 법입니다.
이것은 성능 조치로, 공유 환경에서 호스팅되는 고객들이 서로의 사이트를 무너뜨리지 않도록 보장하기 위한 것입니다. 이를 통해 서버 관리자와 포럼 관리자를 구별할 수 있습니다.
한 번 클릭하든 열두 번 클릭하든 비슷해 보이지만 실제로는 다르며, 이 때문에 '구독 해제’라고 적힌 단순한 버튼을 제공하지 않아 많은 기업들이 막대한 금전적 손해를 입고 있습니다.
우리는 아마도 정반대의 관점에서 이야기하고 있는 것 같지만, 도덕적·윤리적 관점에서는 그렇습니다.
저는 4년 전부터 디스코urses를 관리자로 사용해 왔으며, 말씀하시는 내용을 잘 알고 있습니다(사용자 위장과는 완전히 다른 경우입니다).
말씀하신 내용은 다른 사람의 글과 동일한 방식으로 게시할 수 있는 기능을 활성화하지 말라는 뜻입니다. 이는 제3자의 IP나 ID를 사용하는 것과 같으며, 이는 검열을 위해 그들의 게시물을 편집하는 것과 다릅니다.
참고로, 암호화가 중단되어 사용자 DM(개인 메시지)을 읽을 수 있는 가능성이 제거되기를 바랍니다. 하지만 이는 다른 스레드에서 다룰 내용이며, 테스트를 위한 업데이트를 기다리고 있습니다
다시 인용할게요. 슬로우 모드가 추가된 것 같으니까요…
‘소유권 변경’ 또는 '게시물 편집 후 수정 이력 숨기기’와 같은 실용적인 예시들을 가지고 이 기능이 impersonate 버튼을 건드리지 않고도 마치 본인이 말하지 않은 것을 말한 것처럼 보이게 만드는 방법에 대해 주로 무의미한 논쟁임을 보여줄 수 있을지 고민해 봤습니다. 하지만 결국 그걸 하지 않기로 했습니다.
하지만 UI에만 있는 마법 같은 버튼들만으로도, 하물며 rails 콘솔을 가지고 노는 것까지 포함하면, 제가 정말로 악랄한 짓을 할 수 있는 방법은 분명히 몇 가지 이상 있습니다. 저는 이러한 기능들이 TL4/카트모드/모더레이터 레벨에서도 사용 가능하기 때문에, 이 문제는 관리자뿐만 아니라 커뮤니티의 신뢰에 크게 달려 있다고 생각합니다. 일반적으로 ‘스태프’ 그룹은 자신의 커뮤니티에 대한 자해 행위이기 때문에, 이러한 도구들을 파괴적으로 사용하려고 애쓰지 않는 경향이 있다고 봅니다.
따라서, impersonate 기능 자체가 왜 비윤리적인 것으로 지목되는지 모르겠습니다.
하지만 이것만은 남겨두고 갈게요…
진심으로 말하지만, 남용과 기타 문제를 주장하는 이러한 모든 댓글들은 저에게 전혀 합리적이지 않습니다. 이 특정 기능을 비활성화할 이유가 전혀 없습니다. 다른 분들이 지적했듯이 관리자는 여전히 모든 것을 수행할 수 있습니다.
하지만 여전히 다른 사람들의 말을 듣지 않으려 하고, 없는 문제를 만들고 있습니다. 여전히 무엇이 정말로 문제인지 이해할 수 없습니다. 사용자를 잃을까 걱정되나요? 아니면 다른 관리자가 이 기능을 이용해 당신에게 해를 끼칠까 두려운 건가요? 그렇다면 그렇게 간단하게 당신이 신뢰하지 않는 사람을 관리자로 만들지 말아야 합니다.
Richard, 솔직하게 말씀드리겠습니다. 당신과 @merefield님은 매우 타당하고 긍정적인 사용 사례를 제시하고 계십니다. 하지만 두 분 모두 선택적 설정을 가진 요소들을 변경하는 것이自己的工作 흐름을 방해할 수 있다고만 보고 있는 것 같습니다. 실제로는 그렇지 않을 것입니다. 호스팅을 제공하는 경우 두 분 모두에게 해당 기능이 변경되지 않으므로요.
예를 들어, 금전적 보상 또는 프로 보노(pro bono)에 대한 합의가 필요한 문제를 게시해서 도움을 요청하는 경우가 있습니다. 도움을 제공하는 당신이나 Robert, 혹은 그 누구도 자체 호스팅된 Discourse에서 필요한 도구를 나열할 수 있습니다.
예를 들어, “Dan, 당신의 문제를 해결해 주는 대가로 $X를 받고 싶습니다. 이를 위해 다음이 필요합니다. 당신의 사이트에 계정을 생성하고 관리자 권한을 부여해 주십시오. 또한 문제를 적절하고 효율적으로 진단하고 수정하기 위해 Impersonate(특정 사용자 목록에 대해 이 기능을 사용할 수 있도록 허용)에 접근할 수 있어야 합니다. 만약 Impersonate가 비활성화되어 있다면 루트 관리자(root admin)가 이를 활성화해 주어야 합니다. 제 조건에 동의하시면 이 과정을 시작할 수 있습니다.”
저는 해당 작업을 자동화하고 있으므로 이에 대해 전혀 걱정하지 않습니다. (실제로, 우리가 호스팅하는 Discourse 설치 환경의 호스트명과 사용자명을 인수로 받아 로그인 링크(2FA 및 로그인을 포함)를 제공해주는 셸 스크립트가 있습니다.)
저는 이미 2시간 전에 제 반대 의견을 설명했습니다. (하지만 제 동기 부여에 대한 추가적인 혼란을 피하기 위해 기꺼이 다시 설명하겠습니다.)
읽고 있는 내용을 GPT-4로 직접 요약해 보려 가장 노력한 결과:
약간의 마찰을 더 원하시는 분들을 위해 (저도 그 진영에 속합니다. 개인적으로 버튼을 클릭할 유혹을 받지 않도록, iOS의 스크린 타임(Screen Time)과 같은 유혹을 피하는 데 도움이 되는 트릭처럼요):
.btn-impersonate {
display: none;
}
아마도 그보다 더 많은 마찰을 원하실 수 있고, 누군가가 이를 수행하기 위한 플러그인이나 더 고급스러운 테마 구성 요소를 만들 수도 있겠지만, 저는 이것을 시도해 보고 원치 않는 유혹을 피하는 데 충분한 마찰을 제공하는지 확인해 보고 싶습니다.
저에게는 이것이 핵심입니다. 관리자는 다른 사용 가능한 도구를 통해 여전히 사용자를 ‘위장’할 수 있으며, 이는 문자 그대로 몇 번의 클릭 거리입니다.
하지만 결국 Discourse는 플러그인 시스템을 갖춘 오픈소스 프로젝트이므로, 자신의 커뮤니티에 가장 적합하다고 생각하는 방식으로 기능을 조정할 수 있습니다.
플러그인이 필요하다면, Guardian.can_impersonate?를 오버라이드하는 것부터 시작하는 것이 좋습니다. 이 메서드는 Impersonate 버튼의 존재 여부를 결정하는 직렬화기(serializer)와 백엔드 체크 모두에서 사용됩니다. 제 개발 인스턴스에서 간단한 테스트를 해본 결과, 잘 작동했습니다:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
(일정 부분) 다소 관련이 있는 주제입니다. 다만 유혹에 관한 것이 아니라, 우리가 그것을 사용하고 있다는 사실을 모른 채 또는 실수로 민감한 기능을 사용하는 경우(사용자의 개인 메시지 읽기)에 관한 것입니다: Add a warning when checking personal messages from a user public profile, as an admin
두 가지 경험을 공유합니다. 하나는 첫 번째 게시물에 작성되어 있고, 다른 하나는 여기에 있습니다: Add a warning when checking personal messages from a user public profile, as an admin - #11 by Canapin
…다른 사용자의 프로필에서 해당 사용자의 전체 메시지 목록을 이렇게 쉽게 클릭해서 볼 수 있다는 걸 몰랐습니다…
네, 개인/비공개 채팅까지 확장되길 바라는 이유 중 하나이기도 합니다. Discourse Encrypt를 좋아하거든요.
다만, 관리자로서 사용자의 개인 채팅을 보는 게 그렇게 쉬운 건 아닌 것 같은데, 실제로 그런가요?