Seguindo uma marcação de tópico irrelevante no tópico do Discobot, pergunto-me se a comunidade Discourse quer discutir se permitir fingir ser usuários com um único clique é aceitável ou se poderia ser algo movido para cenários específicos.
Do meu ponto de vista, isso é como usar o IP ou ID de outra pessoa. São comportamentos que não estão alinhados com a ética ou moral (primeiro do que legal ou ilegal).
Penso que o mesmo se aplica a fingir ser outro usuário como uma solução de um clique, onde os administradores poderiam postar como outros usuários com um único clique.
Quero dizer, mudar algumas coisas no Discourse requer entrar manualmente no aplicativo, usar o Postgres e trabalhar com dados de muitas consultas.
Por que fingir ser outro usuário é tão fácil, quando envolve um tópico com múltiplas perspectivas e diferentes interesses legais?
Isso provavelmente não é conhecido pela maioria dos usuários e todos sabemos que os administradores podem entrar no banco de dados e mudar as coisas, mas isso é totalmente diferente de clicar em um botão e postar como outro usuário.
Os administradores podem suspender e banir usuários se algo ruim estiver acontecendo no fórum e eles são legalmente responsáveis pelo site.
Eu não sou. Então, em algum lugar isso é verdade, em algum lugar não é. Mesma coisa que o limite de idade de 13 anos. Ou gravar chamadas telefônicas próprias.
Porque é uma ferramenta poderosa ao resolver problemas, técnicos e outros.
Para mim, o ato em si não é ilegal. O que estou fazendo ao fingir ser outra pessoa pode ser, no entanto. Depende.
Como desenvolvedor, Impersonate é uma função absolutamente brilhantemente útil que ajuda no processo de desenvolvimento, permitindo que eu saia rapidamente de uma função de Administrador e entre na função de um novo usuário para verificar o que ele veria…
Acho que o ponto que está sendo feito é que a personificação fácil (e silenciosa) pode violar as expectativas, pelo menos em algumas comunidades.
Não deveríamos estar olhando para isso como uma questão de lei - é uma questão de política e cultura, e talvez seja o tipo de política em que um administrador do site poderia escolher uma abordagem ou outra.
Às vezes, é útil se personificar, mas talvez a pessoa em questão deva receber uma notificação. Talvez, em muitos casos, a pessoa em questão possa aprovar uma solicitação para se personificar.
Sinceramente, na minha opinião, o recurso não é necessário e deveria ser removido. Mas tenho certeza de que a equipe pode ter razões para ele existir. Por exemplo, alternar para uma conta de usuário de teste.
Quanto ao recurso usado para se passar por outro usuário, pelo menos publicamente, seria possível simplesmente usar 3 cliques para alterar a propriedade.
Resumindo, tenha apenas Administradores escolhidos a dedo.
Isso pode ser problemático, pois alguns administradores apenas mantêm a interface, como no caso do @pfaffman com clientes. Como todos os administradores têm permissões totais, mas não usam nada fora de sua função. Como mencionado, é preciso verificar as leis de sua região; no entanto, pode ser necessário ter cuidado com viagens.
Criar a API proposta para conceder a um usuário funções parciais de administrador que um designer/mantenedor requer.
Verdade, mas isso poderia ser feito usando contas de teste específicas. É aí que entra a integridade do usuário final. Isso pode ser, como o OP sugere, abusado e corrompido.
Lembro-me do aviso no Linux quando o comando sudo é usado pela primeira vez:
Esperamos que você tenha recebido a palestra usual do Administrador de\nSistema local. Geralmente, ela se resume a estas três coisas:\n\n #1) Respeite a privacidade dos outros.\n #2) Pense antes de digitar.\n #3) Com grandes poderes vêm grandes responsabilidades.\n```\n\nOu seja, ao usar o Impersonate pela primeira vez, ou sempre, um administrador poderia ser apresentado a um aviso para clicar, com alguma mensagem sobre respeitar a privacidade e agir com integridade.
A função impersonate é uma coisa boa se você pensar um pouco sobre isso, mas não apenas pelas razões já mencionadas.
O impersonate registra seu uso no log de administrador. Claro, um administrador poderia excluir a entrada com o console do Rails ou por uma consulta SQL direta no Postgres, mas isso deixa seu próprio rastro (uma lacuna nos IDs do log que outros funcionários verão se procurarem por ela).
A falta de impersonate incentivaria ativamente os administradores a abusar da alternativa muito mais sinistra que não será registrada, e suspeito que qualquer desenvolvedor que leia o que acabei de escrever já descobriu o que estou prestes a dizer.
Quer ter uma única entrada de log facilmente oculta e até mesmo feita meses antes para que outros funcionários do fórum não associem as duas coisas? Você cria uma Chave de API para Todos os Usuários. 1 entrada de log, e você faz o que quiser como quem quiser quando quiser, e a menos que seja algo que normalmente seria registrado para o usuário que você está agindo, não deixaria nenhum rastro.
Elas geralmente são contas de teste em um ambiente de desenvolvimento, em qualquer caso, mas configurar contas de teste no desenvolvimento é um trabalho extra. Isso evita que você precise sair e fazer login novamente, o que retarda seu fluxo de trabalho e é especialmente irritante ter que configurar várias senhas, o que não é uma experiência agradável, te atrasa e não adiciona nada de valor no desenvolvimento. Com a opção de “Impersonate”, você só precisa se lembrar da senha do administrador.
Estou simplesmente ilustrando um benefício adicional dessa funcionalidade para este caso de uso específico.
Contas de teste realmente não levam tempo para serem criadas e, nesta ideia, elas seriam uma parte padrão da instalação do Discourse, muito parecido com o Discobot e o sistema. A função “Impersonate” seria mantida, ela só funcionaria com, digamos, 3 ou 4 contas nulas de teste que poderiam ser modificadas para simular usuários de vários níveis.
Como foi dito, pessoas com altos valores e integridade podem não usar o Impersonate para fins nefastos. Embora o uso seja tentador, não obstante. Isso e se os membros de um site soubessem que o administrador poderia usar sua conta para se passar por eles, eles poderiam perder a confiança na plataforma. Atualmente, o impersonate depende unicamente da integridade e não tem uma correção opcional, ao contrário de como o “Encrypt Plugin” corrige os problemas dos usuários de um Fórum Discourse para tornar PM/DM privado, como os usuários de um fórum esperam, a menos que seja claramente explicado que DM/PM não são seguros e privados como a funcionalidade esperada por uma comunidade. No lado positivo, perguntei especificamente se o Impersonate poderia ser usado para contornar o “Encrypt Plugin”, ao que Sam explicou e confirmou que não poderia contornar a proteção, pois é criptografia de ponta a ponta.
Eu uso o Impersonate apenas em minhas contas de teste.
Não é verdade. Criar usuários de teste toda vez é uma chatice. Frequentemente crio novas instalações de desenvolvimento e executo os fixtures de desenvolvimento por questão de rapidez. (Acredito que esses usuários com fixtures não tenham senhas conhecidas) Então, só preciso adicionar uma conta de administrador e a personificação me permite alternar entre eles pela interface de forma agradável. Trabalho feito.
Estou um pouco perplexo com sua negatividade aqui… Eu estava simplesmente elogiando a plataforma por ter uma funcionalidade útil que uso regularmente em meu trabalho, agora você está atacando essa funcionalidade e minha abordagem com o objetivo de quê? Tornar nossas vidas mais difíceis? Não tenho certeza se aprecio muito isso!
Qual é realmente o problema com o recurso de "fingir ser"? Por que vocês estão fazendo um problema do nada? De qualquer forma, este é bastante útil e até mesmo as grandes empresas de tecnologia usam esses recursos. Se você falar sobre privacidade, o administrador pode ver tudo e fazer qualquer coisa com o conteúdo do site. Google, Facebook e todas as grandes empresas de tecnologia fazem isso. Isso não é nada novo, de qualquer forma.
E por que qualquer desenvolvedor criaria uma conta se o problema for do lado do usuário? Nesses casos, esse recurso é bastante útil. Se você tiver um problema, não o use.
Não estou atacando nada. Simplesmente apontando que é um recurso facilmente abusado que pode criar uma infinidade de problemas. Integrar contas de teste para uso direto corrige o uso indevido potencial por não estar disponível. Quanto à criação de uma conta de teste. Abri uma segunda aba, criei uma conta com um endereço de e-mail falso e voltei para minha conta de administrador logada e validei.
O Impersonate é definitivamente uma ferramenta útil que, se contas de teste padrão ou uma opção de administrador dentro do painel de administração pudessem criar contas nulas que podem ser usadas com Impersonate. Fecharia o uso indevido potencial.
Como mencionado, se uma comunidade for informada de que as Contas de Staff podem se passar por eles, eles podem não confiar na plataforma da comunidade.
Pelo que li de você e de uma infinidade de outras ótimas pessoas aqui, provavelmente nunca usariam indevidamente o recurso. Mas ter a funcionalidade aberta deste recurso pode fazer com que as comunidades confiem menos no Discourse como plataforma de fórum.
Ter uma discussão aberta não deve ser visto como negativo, pesando prós e contras.
O Plugin Sam’s Encrypt impede que Administradores e Moderadores visualizem DMs/PMs, assim como aplicativos como o WhatsApp anunciam que não podem visualizar conversas, a menos que sejam convidados. Portanto, isso fecha a função de visualização de DM/PM que pode ser vista como uma violação da privacidade esperada que não está claramente declarada que não são verdadeiramente privadas.
Isso é totalmente irrelevante. Se você realmente quer ler as comunicações privadas dos usuários, como administrador, você pode dar uma olhada no banco de dados (a menos que você ative a criptografia).
Como proprietário de um site, você tem acesso a tudo de qualquer maneira, pode aplicar quaisquer modificações que desejar, ativar e desativar a criptografia, o que for.
Quando você usa um sistema de terceiros como usuário, você não tem controle direto sobre o que as pessoas podem fazer com seus dados.
De qualquer forma, não estou discutindo sobre Produção, meu ponto era apenas dizer que essa funcionalidade também tem seus benefícios em Desenvolvimento e eles são fáceis de demonstrar.
Portanto, da minha perspectiva, +1 nisso. Agora estou muito ocupado para discutir isso mais. Tenha um bom dia.
Então não use Google, Facebook, Microsoft e todos os outros, já que todos eles fazem isso. Eles não dizem abertamente que podem “se passar por você”. Eles podem fazer tudo o que você imaginar, mas ainda assim você confia neles e ainda os usa sabendo que eles podem fazer qualquer coisa, então não sei qual é o verdadeiro problema, cara. talvez você esteja preocupado com seus moderadores e administradores de fórum, mas ainda assim, todas as ações são registradas se algum administrador usar o recurso de “se passar por”. então não consigo entender onde está o problema. se este recurso fosse problemático, a equipe do Discourse não o teria implementado em primeiro lugar.
