Este é um tópico fascinante, que parece ser em grande parte resultado de mal-entendidos.
Esta não é uma questão de Discourse, no entanto, essa questão permeia qualquer sistema online onde não há criptografia de ponta a ponta e assinaturas digitais / validação de mensagens. O Discourse não possui nenhum desses recursos nativamente.
Você também não está realmente debatendo aqui, nem isso se relaciona com quaisquer decisões tomadas pelo Discourse como produto ou pela equipe da CDCK. Existem muitas concepções errôneas por aí, você está apenas aprendendo que o software não pode policiar o nível máximo de autoridade em um sistema - algo que muitos de nós sabemos em graus variados há décadas.
A reputação de uma comunidade não depende dos recursos do Discourse, ela se resume quase inteiramente a quem você entrega as chaves. Se um administrador mal-intencionado fizer algo que cause revolta na comunidade, ninguém se importará com a facilidade com que ele cometeu tais atos, porque, em última análise, foi você e não um botão específico que o capacitou a fazê-lo.
Parece mais que as pessoas se tornaram alheias ao poder que o administrador tem. Se passar por outros é apenas a ponta do iceberg.
Agradeço a forma como você apresentou isso, pois sim, para mim, fiquei bastante chocado (e muitas vezes bastante assustado) ao saber o quanto de poder eu tenho como admin.
É por isso que muitas vezes desejei ter criptografia de ponta a ponta: justamente para reduzir o poder que tenho como admin e reduzir o medo do que pode acontecer com esse poder (por exemplo, a capacidade de ler/alterar mensagens, a responsabilidade legal de ter que relatar o que as pessoas dizem nas conversas privadas, etc.).
No entanto, estes não são problemas que o software livre e de código aberto possa resolver facilmente, mesmo aqueles que existem há uma década.
Em algum momento, tudo se resume a um equilíbrio de risco e confiança entre os aplicativos que compõem seu serviço e as pessoas que detêm as chaves desse reino.
Estar ciente do nível de acesso que você tem é, na verdade, um bom primeiro passo.
Você tem alguma experiência com a enorme quantidade de engenharia necessária para fazer essas coisas parecerem simples e fáceis de usar?
Elas não são omitidas devido a alguma simples falha.
O suficiente para saber que tenho um respeito imenso pelos engenheiros do Signal e muito medo de criar minha própria criptografia Eu construí um aplicativo de diário criptografado em 2012/13 e era um usuário falando consigo mesmo em apenas um dispositivo… e ainda assim foi uma dor, provavelmente não muito fácil de usar, e não tenho certeza de quão seguro.
Então, sim, concordo, tecnologia de comunicação multiusuário simples, fácil de usar e segura pode ser extraordinariamente difícil de criar e manter. Talvez por isso fiquei tão agradavelmente surpreso que o plugin Discourse Encrypt existisse.
Independentemente disso, seus comentários me lembram que sim, esta plataforma é gratuita e de código aberto, o que significa que, se a equipe principal decidir não fazer algo (por exemplo, criptografia de chat ou banir impersonação) por qualquer motivo, sou livre para criar um plugin eu mesmo ou pagar alguém para criá-lo — e essa liberdade de fazer isso se eu quiser é uma das coisas que eu amo tanto sobre o Discourse.
IMHO, até mesmo os moderadores têm muito poder no Discourse, mas venho de um ambiente phpbb3 onde os moderadores tinham muito menos poderes. (Também administrei um site Mailman por mais de 20 anos, que estou migrando para o Discourse assim que conseguir descobrir como mover 20 anos de mensagens para o Discourse.)
Sou o único administrador de sistema desse site phpbb3 há mais de 15 anos, embora tenha me aposentado há vários anos; estou ansioso para que essa plataforma migre para o Discourse porque assumo que outra pessoa será a administradora e eu realmente não quero nem ser um moderador lá, apenas um participante. Tenho aconselhado o líder do projeto sobre questões de administração de fóruns que lidamos ao longo dos anos, algumas delas podem impactar as configurações que ele escolher usar, outras podem impactar as políticas que a organização implementa para usuários e funcionários.
Dito isso, ter restrições para quem pode usar o botão de personificação não me parece uma má ideia, apenas uma que é em grande parte simbólica quando se é um administrador experiente. E, claro, a equipe de desenvolvimento ou o administrador do sistema (em um sistema auto-hospedado) provavelmente podem fazer qualquer coisa se quiserem dedicar esforço suficiente.
Fingir ser outra pessoa é uma ferramenta essencial e amplamente utilizada para administradores. Trabalho com hospedagem na web e finjo ser (“Faça login como”) clientes MUITO no meu painel de faturamento. Existem casos suficientes em que um recurso como esse é crucial, agora neste caso os seguintes cenários podem acontecer:
Você está auxiliando o usuário e precisa ver o que está acontecendo do lado dele
Você está solucionando um bug que não está ocorrendo para todos os seus usuários
Você precisa ver o frontend da perspectiva de um usuário
Você está testando a experiência/fluxo do usuário
Agora o Discourse não é um painel de faturamento, mas os casos de uso são um tanto semelhantes. Os administradores podem precisar solucionar um bug ou ver como o fórum se parece de um grupo ou usuário específico. Eu geralmente finjo ser minhas próprias contas alternativas que estão em grupos específicos ou têm status específico de TL/mod/mod de categoria, para ver como tudo parece do lado deles e se não perdi nenhuma configuração óbvia.
Ou simplesmente auxiliando o usuário com qualquer coisa que não seja possível sem fingir ser outra pessoa - não tenho certeza se existem configurações de usuário que não podem ser acessadas sem fingir ser outra pessoa?
Além do fato de que qualquer administrador root já pode acessar qualquer informação no banco de dados. Este é um dos direitos de acesso que um administrador tem por natureza. O recurso de fingir ser outra pessoa está lá para facilitar a vida do administrador, assim como qualquer outra configuração, eles estão lá para facilitar as tarefas administrativas: a partir da interface /admin/.
As únicas configurações que sei que são um problema, acredito que você pode alterar como administrador, mas ele mostra suas configurações em vez das deles em alguns lugares. Na guia Interface, ele mostra suas configurações de tema e esquema de cores em vez das do usuário, então você tem que se passar por ele para ter certeza de que está vendo os valores corretos.
Se você substituir “Remover o botão de personificação” por “Tornar o botão de personificação menos facilmente disponível”, a frase manterá seu significado, não é?
Só quero lembrar:
Será que muitas pessoas realmente esqueceram a possibilidade de desativar completamente a personificação de administrador simplesmente instalando um pequeno plugin de menos de dez linhas de código?
Talvez eu pense que a função de personificação possa ter um interruptor nas configurações do site como todas as outras funções, assim como sussurrar, marcar, log de página do usuário, log de acesso a PM, etc.
Se esse interruptor estiver nas configurações do site, qualquer administrador poderá reativá-lo, então um clique se torna alguns cliques. Não tenho certeza se isso resolve o problema na mente daqueles que consideram isso um problema. Mas pode torná-lo menos tentador de usar para bisbilhotar.
Eu acho que neste seria ótimo poder configurar quais Administradores no site via linha de comando podem acessar este recurso. Como você pode ter Administradores que precisam de acesso elevado. Embora a simples ideia do @jimkleiber de usar CSS para ocultar o botão para todos, exceto X+, seria suficiente para a maioria, pois é apenas para remover a tentação de ser visto. Embora o serializador de plugin na mesma ideia provavelmente seria melhor, pois imagine que você poderia apertar o botão invisível(?).
De fato, nesse caso, uma opção de linha de comando raiz. Embora a maioria o deixaria se for apenas uma questão de “tentação”.
Aqui está um PR para uma configuração global para desativá-lo. Acho que esta é a fidelidade correta. É algo que a pessoa que instala e executa o cluster deseja definir em todo o cluster.
Ótimo PR! No entanto, acho que a capacidade de ativar e desativar a configuração de personificação é um pouco fácil demais de fazer com este novo recurso. Acho que a maioria dos usuários ficaria desconfortável em saber que a personificação pode ser ativada e desativada ao bel-prazer de um administrador!
Talvez devêssemos considerar uma configuração adicional que permita que esta nova configuração allow_impersonation seja ativada ou desativada. Dessa forma, não serei tão facilmente tentado a definir a configuração allow_impersonation como “on”. Algo como uma configuração allow_allow_impersonation. O que você acha?
Ao dar suporte aos clientes, ocasionalmente temos um administrador que se passa por eles em situações estranhas para garantir que o problema não esteja relacionado ao navegador/SO/bloqueador de anúncios. Nesses casos, é muito útil e discreto - eles não postam em nome do cliente nem têm acesso a nada que eles não pudessem ver de qualquer forma.
Vejo muita confusão entre o técnico e o social. A visão técnica é que a impersonação é útil e desativá-la não impede o suficiente. A visão social é que a impersonação é muito fácil de usar e, na cultura de alguns fóruns, viola o contrato social.
Observar que a impersonação é útil, ou mesmo essencial, não diz nada sobre a utilidade social ou a mensagem. E assim temos pessoas falando umas com as outras - especialmente talvez daqueles que não estão acostumados a pensar em termos de expectativas sociais em diferentes culturas.
Obrigado pelo switch global. (Ainda acho que um aviso intersticial seria uma melhoria!)
Ou deveria estar no console para permitir essa configuração. Ou deveria estar no código-fonte para permitir. Ou alguns avisos? De qualquer forma, a tentação ainda existe, o que fazer
Eu construí um aplicativo de diário criptografado em 2012/13 e era um usuário falando consigo mesmo em apenas um dispositivo… e ainda assim foi uma dor, provavelmente não muito fácil de usar, e não tenho certeza de quão seguro.
)