Pode ser social e/ou cultural e eu tento compartilhar meus pensamentos - sem julgar ninguém - por causa disso.
Algumas pessoas vivem em países que são resistentes a mudanças e totalmente censurados (então elas poderiam normalizar coisas que atacam diretamente a liberdade de diferentes perspectivas ou culturas).
Mas o Discourse quer ser a principal plataforma de fóruns do mundo e eu acho que discutir sobre esse tipo de tópico é sempre uma coisa boa para todos.
Obrigado pelo espaço. Espero que possa ser revisado para não prejudicar os casos de uso, mas também a confiança no Discourse por parte dos usuários e comunidades
Estamos falando em prevenir usos eventualmente muito ruins em grandes comunidades e não prejudicar a confiança que os usuários dão ao Discourse.
Não estamos falando de fóruns cegos ou de impedir que os administradores tenham os dados, porque isso é impossível a partir da base centralizada que usa um único banco de dados.
Acho que essa questão se encaixa muito bem em ‘SIM, mas’ e não no debate ‘SIM ou NÃO’.
Desculpe, mas esse não é o ponto do meu tópico. Você pode abrir outro e perguntar o que quiser.
Remover a personificação não impede isso, é tão fácil sem ela. O principal efeito da remoção da personificação seria dificultar a solução de problemas específicos da conta.
Você deveria iniciar uma demonstração e experimentar alguns dos recursos de administração, você não precisa de acesso ao banco de dados ou se passar por outra pessoa para mudar as palavras de alguém ou ler suas mensagens.
Se é um clique ou uma dúzia de cliques, faz pouca diferença, ainda é possível. Conheço alguém que trabalha em casa com frequência e tem que passar por cerca de meia dúzia de senhas, IDs de dois fatores e outras burocracias para acessar os sistemas internos de sua empresa, mas leva apenas alguns minutos para fazer isso.
Ou você e seus usuários confiam nos desenvolvedores e administradores, ou você/eles não confiam. E se você não confia no sistema, então como você o usa provavelmente mudará.
Da minha perspectiva, isso provavelmente valida que o Discourse leva em consideração a privacidade e a liberdade.
Gerenciar manualmente um banco de dados é aceitável para um desenvolvedor. Um único botão para que todo administrador possa se passar por outro é desnecessário e não é aceitável.
No meio, pode haver um sistema simples que mostre de forma transparente que o impersonate foi usado ou algo assim.
Quero dizer, você pode pensar em opções ou reduzir tudo à sua própria perspectiva.
Você precisa voltar e ler minhas últimas postagens antes de responder novamente, os administradores ainda podem fazer tudo isso sem se passar por outros usuários ou ter acesso ao banco de dados. A personificação e a maioria das ações administrativas já são registradas caso outro administrador precise de um rastro para encontrar um administrador mal-intencionado.
Ou simplesmente feche essa função aberta com o plugin Encrypt. No final das contas, ter opções em funções que as pessoas podem achar problemáticas é uma coisa boa. Falsa sensação de segurança, proteção, etc. O único sistema seguro para Citar Adama é um terminal offline que não está conectado a outros sistemas.
Todos os prós e contras têm um ponto de vista válido. O compromisso é a melhor solução para todas as partes. O Plugin Encrypt, imagino, foi desenvolvido para apaziguar o desejo e, em alguns lugares, possivelmente um requisito para ter uma camada de privacidade para o subsistema PM/DM.
Talvez, se não for incluído no Core como uma opção, um plugin que realize o efeito desejado para aqueles sistemas auto-hospedados que desejam tranquilidade.
Poderia-se dizer que o script para fazer emblemas personalizados não precisa ser desabilitado, pois apenas o Administrador tem acesso direto para criá-los. No entanto, isso tem que ser habilitado a partir do Root, a menos que isso tenha mudado.
Concordo que, em circunstâncias ideais perfeitas, as pessoas deveriam poder confiar em pessoas em posições. Infelizmente, a confiança às vezes é mal colocada e só é descoberta posteriormente.
Essa é uma medida de desempenho, para garantir que clientes hospedados em um ambiente compartilhado não possam derrubar o site uns dos outros. Isso permite distinguir entre o administrador do servidor e o administrador do fórum.
Clicar uma vez ou uma dúzia parece ser semelhante, mas não é o mesmo e, por causa disso, muitas corporações perdem muito dinheiro por não habilitarem um simples botão dizendo ‘Cancele minha inscrição’.
Provavelmente estamos falando do oposto, mas do ponto de vista moral e ético.
Estou usando o Discourse como administrador há 4 anos e sei do que você está falando (casos totalmente diferentes de se passar por usuários).
O que você disse não habilita a possibilidade de postar como outra pessoa com um único clique. Isso é como usar um IP ou ID de terceiros e é diferente de editar suas postagens para moderação.
Aliás, espero que a criptografia pare e quebre a possibilidade de ler as mensagens privadas dos usuários, mas isso é para outro tópico e estou aguardando atualizações para testar
Vou citar isso novamente, pois parece que você adicionou o modo lento…
Tenho pensado em alguns exemplos práticos de ‘mudar de proprietário’ e/ou ‘editar sua postagem e ocultar a revisão’ para demonstrar que este é principalmente um argumento moot sobre o método usado para fazer parecer que você disse algo que não disse sem tocar no botão de impersonar, mas decidi contra isso.
Mas certamente existem mais de algumas maneiras de eu ser um completo idiota com todos os botões mágicos que tenho apenas na interface do usuário, sem falar em brincar com o console do rails. Acho que muito depende da confiança da comunidade, não apenas do administrador, pois muitos desses recursos também estão disponíveis no nível TL4/catmod/mod. Acho que, em geral, o grupo ‘staff’ geralmente não se esforça para ser destrutivo com nenhuma das ferramentas, pois seria um ato de auto-sabotagem em sua própria comunidade.
Como tal, não sei por que o recurso de impersonar em si está sendo destacado como antiético?
Sério, todos esses comentários que alegam uso indevido e outras coisas não fazem sentido para mim, não há razão para desabilitar essa funcionalidade específica. Um administrador ainda pode fazer tudo, como outros apontaram.
Mas, ainda assim, você não quer ouvir os outros e quer criar um problema do nada. Eu ainda não entendo qual é realmente o problema. Você vai perder seus usuários? Ou você tem medo que seu outro administrador use essa funcionalidade contra você? Se for o caso, então você não deveria nomear administradores em quem você não confia, tão simples quanto isso.
Serei perfeitamente honesto, Richard, você e @merefield têm cenários de uso positivos muito válidos. Mas sinto que ambos estão vendo apenas como a alteração de elementos com configurações opcionais prejudicaria seus fluxos de trabalho. O que realmente não faria, pois se você estiver fornecendo hospedagem, o recurso não mudaria para nenhum de vocês.
Exceto, por exemplo, se eu postasse um problema com o qual precisasse de ajuda, com acordos de compensação monetária ou pro bono. Você ou Robert ou qualquer pessoa que ofereça ajuda pode apresentar as ferramentas necessárias de um Discourse auto-hospedado.
ou seja, “Dan, posso te ajudar por R$X para resolver seu problema. Precisarei do seguinte. Para criar uma conta no seu site e conceder acesso de administrador, também precisarei de acesso para me passar por outro usuário (com uma lista de usuários autorizados a usar o recurso para que eu possa diagnosticar e corrigir o problema de forma adequada e eficiente). Se você tiver a opção de se passar por outro usuário desativada, precisará que seu administrador raiz a ative. Se você concordar com meus termos, podemos iniciar este processo.”
Eu automatizaria isso, então não me preocupo com isso (na verdade, tenho um script shell que recebe o nome do host e o nome de usuário de uma instalação do Discourse hospedada por nós como argumento, e ele me dá um link de login (incluindo 2FA e login).
Já expliquei minhas objeções há mais de duas horas (mas ficarei feliz em repeti-las para evitar mais confusão sobre minhas motivações)
Na minha melhor tentativa de resumir manualmente o que estou lendo com o GPT-4:
Alguns querem maior atrito para se passar por outros
Alguns querem o nível atual de baixo atrito para se passar por outros
Para aqueles que querem um pouco mais de atrito (eu estou nesse grupo, porque pessoalmente não quero ser tentado a clicar no botão, semelhante ao Tempo de Uso e outros truques no iOS para me ajudar a evitar a tentação):
Adicione um componente de tema muito simples ao seu site com o seguinte CSS:
.btn-impersonate {
display: none;
}
Talvez você queira ainda mais atrito do que isso, e talvez alguém possa criar um plugin ou um componente de tema mais avançado para fazer isso, mas eu quero experimentar e ver se isso me proporciona atrito suficiente para evitar qualquer tentação indesejada.
Para mim, este é o ponto principal. Os administradores ainda podem “se passar por” usuários com as outras ferramentas disponíveis, literalmente a poucos cliques de distância.
Mas, no final das contas, o Discourse é um projeto de código aberto com um sistema de plugins, você sempre pode fazer as coisas funcionarem da maneira que achar certa para sua própria comunidade.
Se você quiser um plugin, eu começaria com um que substitui Guardian.can_impersonate?, ele é usado pelo serializador que determina a presença do botão “Fazer login como usuário” e também pelas verificações de back-end. Pelo menos a partir de um teste rápido na minha instância de desenvolvimento, funcionou:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
