Existem coisas como Whatsapp e outras que não têm essa função e você tem certeza de que eles podem ou está presumindo que eles podem porque você pode em outros aplicativos que usa?
Apenas um lembrete educado do seu moderador vizinho para manter a discussão civil, e geralmente tranquila, calma e ponderada. 
Os recursos de Debating Discourse não devem ser uma experiência tensa. 
10 curtidas
Sendo totalmente honesto, eu não teria escolhido o Discourse como base da comunidade que fundei na primeira vez se soubesse desse bug/recurso.
Na minha humilde opinião, é inaceitável de todos os pontos de vista ter isso habilitado por padrão E com um único clique ou toque de distância.
Liberdade e privacidade são tudo o que realmente importa na Internet hoje em dia. E espero que a equipe principal possa revisar o fluxo de trabalho porque sei que isso não foi habilitado para quebrar a confiança no Discourse, mas para bons casos de uso!
O tópico, como Jammy disse, aponta para boas discussões, não para ser rude ou levar opiniões diferentes como algo pessoal 
Eu não uso, e uso Mac apenas para tocar música ou coisas triviais.
2 curtidas
Aliás, você conhece uma plataforma LMS bem grande chamada Moodle? Sim, a personificação é uma das ferramentas. Ninguém reclama. Posso agir em nome dos meus clientes no WordPress.
Então… Se a personificação é um impeditivo, não restam muitas opções.
E você ainda nem descobriu a função de “mudar o proprietário da postagem”! 
Piadas à parte. Você quer proibir facas em todas as casas porque é possível matar pessoas com elas. Não se trata da ferramenta, mas de como ela é usada. Se você faz parte de uma comunidade, precisa confiar nos administradores, por muitas e muitas razões. Se não consegue, então você precisa sair da comunidade. É duro, mas é simples assim.
Mudar uma linha no código-fonte do Discourse permitiria que um administrador coletasse silenciosamente todas as senhas digitadas, que tal? Você pode remover recursos o quanto quiser, mas não tem como verificar o código que está rodando no servidor. Confiança é a única solução para isso.
Como alguém que faz muitas soluções de problemas em nome de clientes e seus usuários, posso dizer que uma “conta de teste” não resolve. Existem tantas opções e configurações que importam que a personificação é muitas vezes a única maneira. Dito isso, temos um acordo de processamento de dados em vigor que nos proíbe de usar indevidamente esses recursos.
8 curtidas
Então, como você disse, esse recurso só é conhecido por estar em uso e, ao escolher usar a plataforma, você concorda com isso.
Realmente, este tópico tem muito mérito. Ter uma maneira de desativar a função via acesso ao Servidor Root pela linha de comando faz todo o sentido. Aqueles que querem usar a função a têm disponível para seu caso de uso específico. Aqueles que não querem ter a função ativada podem desativá-la. Como muitas vezes apenas um número muito limitado de administradores em um site tem acesso root, isso pode funcionar bem.
Assim como temos que usar uma linha de comando para habilitar a criação de emblemas personalizados que usam scripts, se bem me lembro.
É uma solução muito simples que pode agradar a todos os pontos de vista a favor e/ou contra a função. Um ótimo compromisso para uma plataforma de fórum aberto. Por padrão, mantenha-a desativada com instruções claras sobre como ativá-la ou até mesmo tenha-a como uma pergunta durante a instalação para ativá-la ou não, com detalhes sobre como ativar/desativar via root.
3 curtidas
E se alguém acredita que Google, Facebook, Apple e todos os outros não fazem essas coisas, então não sei o que dizer.. 
Então uma chave de API poderia ser usada nesse caso. Se bem me lembro, não tenho certeza se você mencionou uma solução para usar uma API para que os designers não tenham acesso administrativo completo. Mas houve uma boa discussão sobre isso.
Mudar Propriedade certamente poderia ser usado. Mas a função não funciona, digamos, no recurso Novo Chat.
Nós realmente não deveríamos fazer comparações de maçãs e laranjas. Enquanto facas não têm requisitos legais de armazenamento, armas de fogo e munições sim. Armas de fogo e facas não matam pessoas, é a pessoa que as usa para esse fim.
Quaisquer ferramentas podem ser abusadas e não há mal em ter salvaguardas opcionais em vigor.
1 curtida
Em qualquer sistema, sempre há um grupo de pessoas que têm acesso e conhecimento suficientes para se passar por outras sem o conhecimento ou consentimento delas.
Tudo se resume à confiança e responsabilidade; você tem que confiar que sua equipe sênior de administradores ou desenvolvedores agirá com responsabilidade.
Nos sistemas sob minha autoridade, se houver um recurso de ‘simular usuário’ (que concordo ser muito útil), nossos procedimentos operacionais para a equipe afirmam que ele só pode ser usado após informar o usuário sobre seu uso e obter o consentimento desse usuário. A falha em fazê-lo seria considerada motivo de demissão. Como é quase sempre feito para resolver um problema, muito poucos usuários recusaram dar-nos esse consentimento.
Vemos perguntas ocasionais de usuários sobre se moderadores ou administradores de sistema podem ler suas mensagens ‘pessoais’. Nosso conselho é que qualquer sistema pode ser violado ou hackeado, portanto, não coloque nada em mensagens pessoais que você não gostaria que fosse tornado público.
Aliás, nossos consultores jurídicos nos dizem que, em caso de procedimentos de descoberta legal, TUDO pode ser solicitado.
4 curtidas
Claro, eles podem muito bem fazer isso, assim como o WhatsApp, que afirma o contrário. Esta é claramente uma questão de software de código fechado, onde se espera que você confie na palavra deles. Sem uma maneira de verificar, como você poderia fazer com código aberto.
O pai de Linus interrogou a Microsoft sobre essa questão de ninguém poder auditar o código para garantir que não houvesse backdoors.
Como já expliquei, mesmo que algo seja de código aberto, você não tem como verificar qual código está sendo executado no servidor.
Como você imagina isso? Não entendo como uma chave de API pode me ajudar a solucionar problemas que um usuário vê ou não vê.
Você sabe o que acontece quando não há um recurso de “fingir ser usuário” ou quando é difícil acessá-lo? O pessoal de suporte começará a pedir senhas aos usuários novamente. Você simplesmente jogou o bebê fora com a água do banho.
5 curtidas
Não, desculpe, mas não é isso que estou pedindo (e eu não quero nada).
Por favor, discutam.
1 curtida
Eu não estava ridicularizando nada. Estava procurando uma comparação e encontrei um exemplo em facas, que são muito úteis e também muito fáceis de usar mal, mas todos aceitam que elas estão em toda parte.
2 curtidas
Verdadeiro, pois pode-se alterá-lo antes do uso.
Nunca disse uma remoção completa. Uma chave de API poderia ser usada para conceder temporariamente a opção quando necessária para aqueles que precisam dela.
Como afirmado, ter uma opção para desativá-la via acesso root de linha de comando é uma solução fácil para aqueles que preferem não ter uma função aberta. Poderia até ser feito de forma que a função de fingir ser usuário pudesse ser configurada via linha de comando como uma opção para restringir seu uso a 1 administrador, por exemplo.
Estou surpreso com a resistência apresentada a simplesmente ter opções para limitar ou desativar a função como uma escolha. Por exemplo, com o seu uso de fornecer serviços de hospedagem, você obviamente não desativaria ou mesmo limitaria seu uso por necessidade.
Agora, se quisermos uma opção direta também, o sistema poderia simplesmente enviar um e-mail ao usuário informando que ele foi personificado pelo administrador x. Assim como a 2FA, criaria uma camada de transparência sobre o uso da função. Para o qual o usuário que foi personificado já estaria ciente de que seria usado para resolver um problema.
1 curtida
Minha “resistência” é dupla:
- remover o recurso ou dificultar o acesso a ele fornece uma falsa sensação de segurança
- quando tal funcionalidade é difícil (ou mais difícil) de acessar, o pessoal de suporte encontra uma maneira de contorná-la, e o compartilhamento de senhas é muito pior, pois não é registrado, as senhas podem ser mantidas e as senhas podem ser válidas para outros serviços.
Alguém com acesso suficiente também poderia impedir o envio desse e-mail.
E todo e-mail pode ser um vetor de ataque também (conheço um exemplo específico de um fórum Discourse que foi comprometido por uma notificação falsa de “backup criado” enviada a um administrador).
Então você quer usar uma chave de API para desbloquear isso. Agora os administradores podem criar chaves de API que lhes dão acesso total e, quando questionados por outros administradores sobre por que criaram/usaram uma chave de API, eles podem alegar que foi para solução de problemas.
1 curtida
Não estamos falando de Google, Facebook ou Apple. Estamos falando de Discourse, que é de código aberto e permite auto-hospedagem.
Isso deveria ser o oposto.
Eu entendo totalmente.
Mas a questão é por que está a apenas um clique de distância quando a alteração do título dos níveis de confiança implica o uso do explorador de consultas ou o gerenciamento manual do banco de dados?
EDIT: duas postagens unificadas.
1 curtida
Isso se aplica a qualquer coisa, até mesmo a dispositivos de proteção de segurança, como proteção contra quedas. Então, devemos abandonar o EPI, pois ele cria uma falsa sensação de segurança total se usado?
Opções não são absolutas. Simplesmente configurações opcionais para tranquilidade, mesmo que qualquer coisa possa ser contornada. Sam revelou que, embora não seja fácil de fazer, até mesmo o plugin de criptografia pode, como qualquer esquema de criptografia, ser quebrado.
3 curtidas
Bem, esse não é o ponto do tópico, mas você pode abrir um novo se quiser
Na minha opinião, esse é o ponto do tópico: você pode e deve confiar nos administradores das comunidades em que participa?
Não acho que haja muita novidade saindo da conversa neste ponto… um administrador mal-intencionado não precisa se passar por alguém para fazer isso, eles também poderiam fazer uma postagem e alterar a propriedade dela. Eles poderiam editar suas postagens existentes e alterar suas configurações sem se passar por você. Eles também podem excluir o histórico de edições para ocultar esse fato de outros usuários não administradores. Um administrador também não precisa se passar por um usuário para ver tudo o que a conta dele faz, e eles também não precisam de acesso ao console para isso.
Remover o botão de se passar por alguém não faz nada para tornar sua conta mais segura. Tudo o que o recurso de se passar por alguém permite pode ser feito por um administrador sem esse recurso.
Se você não pode confiar em um administrador com medo de que ele leia suas mensagens pessoais ou altere o que você posta para prejudicá-lo, você não deve usar o site.
10 curtidas