사용자 사칭에 대한 의견

[Stephen]

매우 흥미로운 주제인데, 이는 대부분 오해에서 비롯된 것으로 보입니다.

이것은 단순히 Discourse의 문제만이 아닙니다. 메시지 전송 시 종단 간 암호화(end-to-end encryption)와 디지털 서명/검증이 없는 모든 온라인 시스템에서 나타나는 문제입니다. Discourse는 기본적으로 이 두 가지 기능을 제공하지 않습니다.

@satonotdead

제 관점에서 보면, 이는 아마도 Discourse가 프라이버시와 자유를 고려하고 있음을 확인해 주는 것이겠죠.

여기서 논쟁의 대상이 되는 것도 아니고, 이는 Discourse라는 제품이나 CDCK 팀이 내린 결정과도 직접적인 관련이 없습니다. 세상에는 수많은 오해가 존재하며, 여러분은 단지 소프트웨어가 시스템의 최종 권한을 통제할 수 없다는 사실을 깨닫고 있는 것입니다. 많은 이들이 수십 년 전부터 이 사실을 어느 정도 인지하고 있었습니다.

커뮤니티의 명성은 Discourse의 기능에 좌우되는 것이 아니라, 거의 전적으로 키를 누구에게 맡기느냐에 달려 있습니다. 악의적인 관리자(admin)가 커뮤니티를 혼란에 빠뜨리는 행동을 저지르더라도, 그 행위를 저지르기 얼마나 쉬웠는지는 아무도 신경 쓰지 않을 것입니다. 결국 그들에게 힘을 실어 준 것은 특정 버튼이 아니라 여러분이었기 때문입니다.

@jimkleiber

• 일부는 현재 수준의 낮은 마찰(friction)로 인한 위장(impersonate)을 원합니다

사람들이 *관리자(admin)*가 가진 힘에 대해 무감각해졌다는 느낌이 더 강합니다. 위장 기능은 빙산의 일각일 뿐입니다.

[jimkleiber]

@Stephen

사람들이 관리자가 가진 힘에 무관심해졌다는 느낌이 더 강합니다.

이렇게 문제를 제기해 주셔서 감사드립니다. 사실, 저도 관리자로 얼마나 큰 권한을 가지고 있는지 알게 되었을 때 상당히 충격을 받았고(자주 무서웠습니다) 놀랐습니다.

제가 종단간 암호화를 항상 원해 온 이유가 바로 이것입니다: 관리자로 가진 권한을 줄이고, 그 권한으로 인해 일어날 수 있는 것에 대한 두려움을 줄이기 위해서입니다(예: 메시지를 읽거나 수정할 수 있는 능력, 사적인 대화에서 사람들이 말하는 내용을 보고해야 하는 법적 책임 등).

[Stephen]

그러나 이러한 문제들은 자유 및 오픈 소스 소프트웨어가 쉽게 해결할 수 있는 문제가 아닙니다. 10년 이상 존재해 온 소프트웨어도 마찬가지입니다.

결국 모든 것은 서비스의 애플리케이션과 그 왕국의 열쇠를 쥔 사람들 사이의 위험과 신뢰의 균형으로 귀결됩니다.

자신이 어떤 수준의 접근 권한을 가지고 있는지 인지하는 것이 실제로는 좋은 첫걸음입니다.

@jimkleiber

종단 간 암호화를 원해 온 이유는 정확히 이것입니다: 관리자로서 제가 가진 권력을 줄이고, 그 권력으로 인해 일어날 수 있는 것에 대한 두려움을 줄이는 것입니다(예: 메시지를 읽거나 수정할 수 있는 능력, 사적인 대화에서 사람들이 말하는 것을 보고해야 할 법적 책임 등).

이러한 것들이 단순하고 사용자 친화적으로 보이도록 하기 위해 필요한 막대한 양의 엔지니어링에 대해 경험해 보신 적 있으신가요?

그들은 단순한 실수로 인해 생략된 것이 아닙니다.

[jimkleiber]

@Stephen

이런 것들이 단순하고 사용자 친화적으로 보이도록 만드는 데 필요한 막대한 엔지니어링 작업에 대한 경험이 있으신가요?

Signal 엔지니어들에게 경외심을 갖고, 직접 암호화를 구현하는 것에 대해서는 상당한 두려움을 느끼기에 충분한 경험은 있습니다. 2012/13년에 암호화 일기 앱을 개발한 적이 있는데, 그것은 단 하나의 기기에서 사용자가 자신과 대화하는 단 하나의 사용자만 지원하는 것이었습니다… 그런데도 여전히 고생이 많았고, 아마도 그렇게 사용자 친화적이지 않았으며, 보안이 얼마나 되는지도 확신할 수 없습니다.

그러니, 네, 동의합니다. 단순하고 사용자 친화적이며 안전한 다중 사용자 통신 기술을 만들고 유지하는 것은 극도로 어렵습니다. 아마도 Discourse Encrypt 플러그인이 존재한다는 사실에 그렇게 기뻐했던 이유가 바로 그것일 것입니다.

어쨌든, 여러분의 코멘트는 이 플랫폼이 무료이고 오픈소스라는 것을 다시금 상기시켜 주었습니다. 이는 핵심 팀이 어떤 이유에서든 특정 기능(예: 채팅 암호화나 사칭 금지)을 구현하지 않기로 결정하더라도, 제가 직접 플러그인을 만들거나 누군가에게 만들어 달라고 의뢰할 자유가 있다는 것을 의미합니다 — 그리고 원한다면 그렇게 할 수 있는 이 자유는 제가 Discourse를 매우 사랑하는 이유 중 하나입니다.

감사합니다

[MikeNolan]

개인적 의견이지만, Discourse에서도 모더레이터에게 상당한 권한이 부여되어 있다고 생각합니다. 다만, 제가 이전까지 사용하던 phpbb3 환경에서는 모더레이터의 권한이 훨씬 제한적이었거든요. (또한 20년 넘게 Mailman 사이트를 운영해 왔고, 20년치 메시지를 Discourse로 어떻게 이전할지 방법을 알아내자마자 바로 이주할 계획입니다.)

저는 몇 년 전 은퇴했지만, 그 phpbb3 사이트의 유일한 시스템 관리자로서 15년 넘게 운영해 왔습니다. 사실 그 플랫폼이 Discourse로 전환되는 것을 기대하고 있습니다. 다른 사람이 관리자가 될 것으로 예상하기 때문이죠. 저는 그곳에서 모더레이터조차 되고 싶지 않고, 그저 참여자로서 활동하길 원합니다. 그동안 우리가 겪어온 포럼 관리 관련 문제들을 프로젝트 리더에게 조언해 왔는데, 그중 일부는 그가 선택할 설정에 영향을 미칠 수 있고, 다른 일부는 해당 조직이 사용자 및 직원에게 적용할 정책에 영향을 줄 수 있습니다.

그럼에도 불구하고, ‘대리 로그인(impersonate)’ 버튼을 사용할 수 있는 대상에 제한을 두는 것은 나쁜 아이디어라고 생각하지 않습니다. 다만, 경험이 많은 관리자가 된다면 그 제한은 상징적 의미에 그칠 가능성이 크다고 봅니다. 그리고 물론, 개발 팀이나 시스템 관리자(자체 호스팅 시스템의 경우)는 충분한 노력을 기울인다면 사실상 무엇이든 할 수 있을 것입니다.

[MarcP]

임페르소네이트(Impersonating)는 관리자にとって 필수적이고 널리 사용되는 도구입니다. 저는 웹 호스팅 업계에 종사하며, 결제 패널에서 고객들을 대신해 로그인(“Log in as”)하는 임페르소네이트를 매우 자주 사용합니다. 이러한 기능이 결정적으로 중요한 경우가 충분히 많으며, 이 경우 다음과 같은 시나리오가 발생할 수 있습니다:

1. 사용자를 지원하면서 해당 사용자의 화면에서 어떤 일이 일어나고 있는지 확인해야 할 때
2. 모든 사용자에게 발생하지 않는 버그를 디버깅해야 할 때
3. 사용자 관점에서 프론트엔드를 확인해야 할 때
4. 사용자 경험/플로우를 테스트해야 할 때

Discourse는 결제 패널이 아니지만, 사용 사례는 어느 정도 유사합니다. 관리자는 버그를 디버깅하거나 특정 그룹이나 사용자의 관점에서 포럼이 어떻게 보이는지 확인해야 할 수 있습니다. 저는 보통 특정 그룹에 속해 있거나 특정 TL/모더레이터/카테고리 모더레이터 상태를 가진 제 자신의 대용 계정을 임페르소네이트하여, 그들의 관점에서 모든 것이 어떻게 보이는지, 그리고 눈에 띄는 설정을 놓치지 않았는지 확인합니다.

또는 임페르소네이트 없이 불가능한任何事情에 대해 사용자를 지원하는 경우도 있습니다. 임페르소네이트 없이 접근할 수 없는 사용자 설정이 있는지 확실하지는 않습니다?

어쨌든 루트 관리자는 이미 데이터베이스의 모든 정보에 접근할 수 있습니다. 이는 관리자가 본질적으로 가진 접근 권한 중 하나입니다. 임페르소네이트 기능은 관리자의 업무를 더 쉽게 만들기 위해 존재하며, /admin/ 인터페이스의 다른 설정들이 관리 작업을 용이하게 하듯 마찬가지입니다.

[ClawdiaWolf (Claudia)]

@MarcP

또는 단순히 임의의 사용자로의 변장이 없이는 불가능한 작업에 사용자를 돕는 것입니다. 변장 없이 접근할 수 없는 사용자 설정이 있는지 확실하지 않네요?

문제가 되는 설정으로 제가 아는 것은 관리자 권한으로 변경할 수 있지만, 몇몇 곳에서는 상대방의 설정 대신 내 설정이 표시된다는 점입니다. 인터페이스 탭에서는 사용자의 테마와 색상 스킴 설정 대신 내 설정이 표시되므로, 정확한 값을 확인하려면 사용자로 변장해야 합니다.

[RGJ (Richard - Communiteq)]

인스페르소네이션(impersonation) 없이는 불가능한 또 다른 기능은 구독 설정입니다. Make u/username/billing/ accessible to admins

[satonotdead]

@RGJ

impersonation(대리 로그인) 없이는 불가능합니다

impersonation(대리 로그인) 기능을 제거하자는 이야기는 아닙니다.

참고로, 제 토픽이 처음부터 제기해 온 유일한 질문에 답변해 주실 분 계신가요?

@satonotdead

하지만 질문은 왜 클릭 한 번의 거리(1-click distance)에 있는가입니다.

그것이 Discourse의 방식이며, 명확한 결정입니다.

[RGJ (Richard - Communiteq)]

저는 그저 질문에 대한 답변을 드린 것입니다.

@MarcP

가짜 사용자 계정을 사용하지 않고는 접근할 수 없는 사용자 설정이 있다면 어떻게 하나요?

[Canapin (Coin-coin le Canapin)]

@satonotdead

하지만 질문은 왜 클릭 한 번 거리인지에 대한 것이죠?

이 질문에 이미 답하지 않았나요?

@awesomerobot

가장자리(Impersonate) 버튼을 제거하는 것은 계정을 더 안전하게 만드는 데 아무런 도움이 되지 않습니다. 가장자리 기능이 허용하는 모든 작업은 해당 기능이 없는 관리자도 수행할 수 있습니다.

"가장자리 버튼을 제거하는 것"을 "가장자리 버튼을 덜 쉽게 사용할 수 있게 하는 것"으로 바꾸면, 문장의 의미가 유지되지 않나요?

[Lhc_fl (Linca)]

다시 한번 상기시켜 드리고 싶은 것이 있습니다:

10줄도 안 되는 작은 플러그인을 설치하는 것만으로 관리자 위장(impersonation) 기능을 완전히 비활성화할 수 있다는 사실을 많은 분들이 실제로 잊고 계신 건 아닌지 궁금합니다.

@renato

플러그인이 필요하시다면, Guardian.can_impersonate?를 오버라이드하는 것부터 시작해 보세요. 이 메서드는 위장 버튼의 존재 여부를 결정하는 시리얼라이저뿐 아니라 백엔드 체크에서도 사용됩니다. 제 개발 인스턴스에서 간단한 테스트를 해본 결과 작동했습니다:

# plugin.rb
after_initialize do
  class ::Guardian
    def can_impersonate?(target)
      false
    end
  end
end

위장 기능이 다른 모든 기능들처럼 사이트 설정에 온/오프 스위치가 있었으면 좋겠다는 생각이 듭니다. 귓속말, 태그, 사용자 페이지, DM 접근 로그 등 다른 기능들과 마찬가지로 말이죠.

[MikeNolan]

@Lhc_fl

역할 대행 기능이 속삭임, 태그, 사용자 페이지, PM 접근 로그 등 다른 모든 기능처럼 사이트 설정에 토글 스위치를 가질 수 있다고 생각합니다.

그 스위치가 사이트 설정에 있다면, 어떤 관리자든 다시 켤 수 있으므로 이제 1클릭이 몇 번의 클릭으로 늘어납니다. 이것이 문제로 보는 사람들의 관점에서 문제를 해결하는지 확신할 수 없습니다. 하지만 주변을 몰래 들여다보기 위한 유혹을 줄이는 데는 도움이 될 수 있습니다.

[Heliosurge (Dan DeMontmorency)]

@jimkleiber

종단 간 암호화를 자주 원했던 이유는 정확히 이것 때문입니다: 관리자로서 제가 가진 권한을 줄이고, 그 권한으로 인해 발생할 수 있는 두려움을 줄이기 위함입니다(예: 메시지 읽기/수정 능력, 사적인 대화에서 사람들이 말하는 내용을 보고해야 하는 법적 책임 등).

Sam은 PM/DM을 위해 훌륭한 Emcrypt 플러그인을 만들었습니다.

[Heliosurge (Dan DeMontmorency)]

이 기능에 대해, 사이트에서 해당 기능을 접근할 수 있는 관리자(Admin)를 명령줄을 통해 설정할 수 있으면 좋겠습니다. elevated access(특권 접근 권한)이 필요한 관리자가 있을 수 있기 때문이죠. 다만 @jimkleiber 님의 간단한 아이디어인 CSS를 사용해 X+ 권한을 가진 사용자를 제외한 모든 사용자에게 버튼을 숨기는 방식도, 단순히 보임으로써 생기는 유혹을 제거하는 것이 목적이라면 대부분의 경우에 충분할 것입니다. 다만, 같은 원리라면 플러그인 serializer를 사용하는 방식이 더 나을 것 같습니다. 왜냐하면 보이지 않는 버튼을 우연히 클릭할 수도 있기 때문이죠.

@MikeNolan

그 스위치가 사이트 설정에 있다면, 어떤 관리자가든 다시 켤 수 있으므로, 이제 원클릭이 몇 번의 클릭이 됩니다.

맞습니다. 그런 경우 루트(root) 명령줄 옵션이 적합할 것입니다. 다만, 단순히 "유혹"의 문제라면 대부분의 사용자는 그 설정을 그대로 둘 것입니다.

[sam (Sam Saffron)]

@Lhc_fl

대리 기능에 대해 다른 모든 기능들처럼, 속삭임, 태그, 사용자 페이지, PM 접근 로그 등처럼 사이트 설정에 스위치를 추가할 수 있다고 생각합니다.

이 주제에 대해 정말 많은 논쟁이 있었네요.

이를 비활성화하는 전역 설정에 대한 PR을 올립니다. 이것이 적절한 수준의 세팅이라고 생각합니다. 클러스터를 설치하고 운영하는 사람이 클러스터 전체에 적용하고 싶어 하는 것이기 때문입니다.

FEATURE: allow site owners to disable impersonation (#20783)

[piffy]

훌륭한 PR입니다! 다만 이 새로운 기능으로 인해 impersonation 설정을 켜고 끄는 것이 너무 쉽다는 느낌을 받습니다. 대부분의 사용자는 관리자가 마음만 먹으면 impersonation을 언제든 켜고 끌 수 있다는 사실에 불편함을 느낄 것 같습니다.

아마도 이 새로운 allow_impersonation 설정을 켜고 끌 수 있도록 하는 추가 설정을 고려해 보는 것이 좋겠습니다. 그러면 allow_impersonation 설정을 "on"으로 변경하고 싶은 유혹에 쉽게 빠지지 않을 것입니다. allow_allow_impersonation과 같은 설정이요. 어떻게 생각하시나요?

(이건 농담입니다 )

[HAWK]

고객을 지원할 때, 문제가 브라우저/OS/애드블로커와 관련이 없는지 확인하기 위해 가끔 관리자 계정으로 임의의 상황에서 로그인(impersonate)을 수행합니다. 이러한 경우 해당 기능은 매우 유용하면서도 무방비적입니다. 관리자가 고객 대신 게시물을 작성하거나, 고객이 원래 볼 수 없었던 정보에 접근할 수 있는 권한을 부여하지 않기 때문입니다.

[Ed_S]

@sam

이 주제에 대해 정말 많은 논쟁이 벌어지고 있습니다.

기술적 관점과 사회적 관점 사이에서 많은 혼란이 일어나고 있다고 봅니다. 기술적 관점에서는 위장이 유용하며, 이를 끄는 것만으로는 충분히 막을 수 없다는 입장입니다. 반면 사회적 관점에서는 위장이 너무 쉽게 사용될 수 있으며, 일부 포럼의 문화에서는 이것이 사회적 계약을 위반한다고 봅니다.

위장이 유용하거나 심지어 필수적이라는 점은 사회적 유용성이나 메시지 전달 방식에 대해 아무것도 말해 주지 않습니다. 그래서 사람들은 서로 다른 이야기를 하고 있는 셈입니다. 특히 다양한 문화에서의 사회적 기대를 고려해 생각해 본 경험이 없는 사람들에게서 이런 현상이 두드러질 수 있습니다.

전체적인 스위치를 제공해 주셔서 감사합니다. (여전히 중간 경고 화면을 추가하는 것이 개선책이라고 생각합니다!)

[kynic]

아니면 이 설정을 허용하기 위해 콘솔에 있어야 합니다. 아니면 소스 코드에 있어야 합니다. 아니면 몇 가지 경고 메시지가 있어야 할까요? 어쨌든 뭘 해야 할지 유혹이 계속되네요