Suite à un signalement hors sujet sur le fil Discobot, je me demande si la communauté Discourse souhaite discuter de la possibilité d’autoriser l’usurpation d’identité d’utilisateurs en un seul clic comme étant acceptable ou si cela devrait être réservé à des scénarios spécifiques.
De mon point de vue, c’est comme utiliser l’adresse IP ou l’identité de quelqu’un d’autre. Ce sont des comportements qui ne sont pas alignés avec l’éthique ou la morale (avant d’être légaux ou illégaux).
Je pense que la même chose s’applique à l’usurpation d’identité en tant que solution en un clic, où les administrateurs pourraient publier comme d’autres utilisateurs en un seul clic.
Je veux dire, changer certaines choses dans Discourse nécessite d’entrer manuellement dans l’application, d’utiliser Postgres et de travailler sur les données à partir de nombreuses requêtes.
Pourquoi l’usurpation d’identité est-elle si facile, alors qu’elle implique un fil de discussion avec de multiples perspectives et des intérêts juridiques différents ?
C’est probablement quelque chose que la majorité des utilisateurs ignorent, et nous savons tous que les administrateurs peuvent accéder à la base de données et modifier des choses, mais c’est totalement différent de cliquer sur un bouton et de publier comme un autre utilisateur.
Les administrateurs peuvent suspendre et bannir les utilisateurs si quelque chose de mal se passe sur le forum et ils sont légalement responsables du site web.
Je ne le suis pas. Donc, quelque part c’est vrai, quelque part ça ne l’est pas. La même chose que la limite d’âge de 13 ans. Ou l’enregistrement de ses propres appels téléphoniques.
Parce que c’est un outil puissant pour résoudre les problèmes, techniques ou autres.
Pour moi, l’acte en soi n’est pas illégal. Ce que je fais en prétendant être quelqu’un d’autre peut l’être, cependant. Ça dépend.
Et l’adresse IP n’est pas la propriété de la personne.
En tant que développeur, Impersonate est une fonction absolument brillante et utile qui aide au processus de développement, me permettant de sortir rapidement d’un rôle d’administrateur et d’endosser le rôle d’un nouvel utilisateur pour vérifier ce qu’il verrait…
Je pense que l’idée est que l’usurpation d’identité facile (et silencieuse) pourrait violer les attentes, du moins dans certaines communautés.
Nous ne devrions pas considérer cela comme une question de droit - c’est une question de politique et de culture, et c’est peut-être le genre de politique où un administrateur de site pourrait choisir une approche ou une autre.
Il est parfois utile d’usurper l’identité, mais peut-être que la personne en question devrait recevoir une notification. Peut-être que dans de nombreux cas, la personne en question pourrait approuver une demande d’usurpation d’identité.
Honnêtement, à mon avis, la fonctionnalité n’est pas nécessaire et devrait être supprimée. Mais je suis sûr que l’équipe a ses raisons. Par exemple, passer à un compte utilisateur de test.
Quant à la fonctionnalité utilisée pour usurper l’identité d’un autre utilisateur, au moins publiquement, on pourrait simplement utiliser trois clics pour changer de propriétaire.
En fin de compte, n’ayez que des administrateurs bien choisis.
Cela pourrait être problématique car certains administrateurs ne font que maintenir l’interface, comme dans le cas de @pfaffman avec ses clients. Tous les administrateurs ont les pleines permissions mais n’utilisent pas les choses en dehors de leur travail. Comme mentionné, il faut vérifier les lois de sa région ; cependant, il faut peut-être faire attention aux déplacements.
Créer l’API proposée pour accorder à un utilisateur des fonctions d’administrateur partielles dont un concepteur/mainteneur a besoin.
C’est vrai, mais cela pourrait être fait en utilisant spécifiquement des comptes de test. C’est là que tout dépend de l’intégrité de l’utilisateur final. Cela pourrait, comme le suggère l’OP, être abusé et corrompu.
Je me souviens de l’avertissement dans Linux lorsque la commande sudo est utilisée pour la première fois :
Nous sommes convaincus que vous avez reçu la conférence habituelle de l'administrateur système local. Elle se résume généralement à ces trois points :
#1) Respectez la vie privée des autres.
#2) Réfléchissez avant de taper.
#3) Un grand pouvoir implique une grande responsabilité.
C’est-à-dire que lors de la première utilisation d’Impersonate, ou à chaque fois, un administrateur pourrait se voir présenter un message à accepter, avec un message sur le respect de la vie privée et l’intégrité.
La fonction d’usurpation est une bonne chose si l’on y réfléchit un instant, mais pas seulement pour les raisons déjà évoquées.
L’usurpation enregistre son utilisation dans le journal d’administration. Bien sûr, un administrateur pourrait supprimer l’entrée avec la console Rails ou par une requête SQL directe dans Postgres, mais cela laisse sa propre trace (un écart dans les identifiants du journal que d’autres membres du personnel verront s’ils le recherchent).
L’absence d’usurpation encouragerait activement les administrateurs à abuser de l’alternative beaucoup plus sinistre qui ne sera pas enregistrée, et je soupçonne que tout développeur lisant ce que je viens d’écrire a déjà compris ce que je m’apprête à dire.
Vous voulez une seule entrée de journal facilement cachée et même faite des mois à l’avance pour que les autres membres du personnel du forum ne les associent pas ? Vous créez une clé API pour tous les utilisateurs. 1 entrée de journal, et vous faites ce que vous voulez en tant que qui vous voulez quand vous voulez, et à moins que ce ne soit quelque chose qui serait normalement enregistré pour l’utilisateur en tant que tel, cela ne laisserait aucune trace.
Ce sont souvent des comptes de test dans un environnement de développement, mais la configuration de comptes de test en développement représente un travail supplémentaire. Cela vous évite d’avoir à vous déconnecter et à vous reconnecter, ce qui ralentit votre flux de travail et est particulièrement agaçant d’avoir à configurer plusieurs mots de passe, ce qui n’est pas une expérience agréable, vous ralentit et n’ajoute aucune valeur au développement. Avec l’usurpation d’identité, vous n’avez qu’à vous souvenir du mot de passe administrateur.
J’illustre simplement un avantage supplémentaire de cette fonctionnalité pour ce cas d’utilisation spécifique.
La création de comptes de test ne prend vraiment pas de temps et, dans cette idée, ils feraient partie intégrante de l’installation de Discourse, tout comme Discobot et le système. La fonction « Impersonate » serait conservée, elle ne fonctionnerait qu’avec, par exemple, 3 ou 4 comptes nuls de test qui pourraient être modifiés pour simuler des utilisateurs de différents niveaux.
Comme il a été dit, les personnes ayant des valeurs élevées et une grande intégrité n’utiliseraient pas « Impersonate » à des fins néfastes. Bien que l’utilisation soit tentante néanmoins. De plus, si les membres d’un site savaient que l’administrateur pouvait utiliser leur compte pour les usurper, ils pourraient perdre confiance dans la plateforme. Actuellement, « Impersonate » repose uniquement sur l’intégrité et n’a pas de solution alternative, contrairement à la façon dont « Encrypt Plugin » résout les problèmes des utilisateurs d’un forum Discourse pour rendre les messages privés/DM privés, comme les utilisateurs d’un forum s’y attendent, à moins qu’il ne soit clairement indiqué que les DM/PM ne sont pas sécurisés et privés comme le fonctionnalisme attendu par une communauté. En outre, j’ai demandé spécifiquement si « Impersonate » pouvait être utilisé pour contourner « Encrypt Plugin », ce à quoi Sam a expliqué et confirmé qu’il ne pouvait pas contourner la protection car il s’agit d’un chiffrement de bout en bout.
J’utilise « Impersonate » uniquement sur mes comptes de test.
C’est faux. Créer des utilisateurs de test à chaque fois est une corvée. Je crée souvent de nouvelles installations de développement et j’utilise les fixtures de développement pour plus d’efficacité. (Ces utilisateurs de fixtures n’ont pas de mots de passe connus, à ma connaissance) Ensuite, il suffit d’ajouter un compte administrateur et l’impersonation me permet de passer facilement de l’un à l’autre depuis l’interface utilisateur. Travail terminé.
Je suis un peu perplexe face à votre négativité ici… Je complimentais simplement la plateforme pour avoir une fonctionnalité utile que j’utilise régulièrement dans mon travail, et maintenant vous attaquez cette fonctionnalité et mon approche dans le but de quoi ? De nous compliquer la vie ? Je n’apprécie pas vraiment cela !
Quel est réellement le problème avec la fonctionnalité « usurper l’identité » ? pourquoi faites-vous une montagne d’une taupinière ? Quoi qu’il en soit, celle-ci est très utile et même les grandes entreprises technologiques utilisent ces fonctionnalités. Si vous parlez de confidentialité, l’administrateur peut tout voir et faire ce qu’il veut avec le contenu du site. Google, Facebook et toutes les grandes entreprises technologiques font de même. Ce n’est rien de nouveau de toute façon.
Et pourquoi un développeur créerait-il un compte si le problème vient de l’utilisateur ? Dans ces cas, cette fonctionnalité est très utile. Si vous avez un problème, ne l’utilisez pas.
Je n’attaque rien du tout. Je souligne simplement qu’il s’agit d’une fonctionnalité facilement détournable qui peut créer une multitude de problèmes. L’intégration de comptes de test pour une utilisation directe résout le potentiel d’abus en la rendant indisponible. Quant à la création d’un compte de test. J’ai ouvert un 2ème onglet, créé un compte avec une fausse adresse e-mail non valide, puis suis revenu à mon compte administrateur connecté et validé.
L’impersonnalisation est définitivement un outil utile qui, si des comptes de test par défaut ou une option d’administrateur dans le panneau d’administration pouvaient créer des comptes nuls utilisables avec l’impersonnalisation. Cela fermerait le potentiel d’abus.
Comme mentionné, si une communauté est informée que les comptes du personnel peuvent les usurper, elle pourrait ne pas faire confiance à la plateforme communautaire.
D’après ce que j’ai lu de vous et d’une pléthore d’autres personnes formidables ici, il est peu probable qu’elles abusent de la fonctionnalité. Mais avoir la fonctionnalité ouverte de cette fonctionnalité pourrait rendre les communautés moins confiantes envers Discourse en tant que plateforme de forum.
Une discussion ouverte ne devrait pas être considérée comme négative, mais comme une pesée des avantages et des inconvénients.
Le plugin Sam’s Encrypt empêche les administrateurs et les modérateurs de voir les messages directs/privés, un peu comme les applications comme WhatsApp annoncent qu’elles ne peuvent pas voir les conversations à moins d’y être invitées. Cela ferme donc la fonction de visualisation des messages directs/privés qui pourrait être considérée comme une violation de la confidentialité attendue, qui n’est pas clairement indiquée comme n’étant pas vraiment privée.
Alors faites de la publicité ouvertement dans toutes les communautés que les administrateurs peuvent les usurper. L’efficacité est remplacée par la méfiance.
@simon a publié une solution en partie acceptable dans l’environnement de développement.
Ceci est totalement sans objet. Si vous voulez vraiment lire les communications privées des utilisateurs, en tant qu’administrateur, vous pouvez aller jeter un œil dans la base de données (sauf si vous activez le chiffrement).
En tant que propriétaire d’un site Web, vous avez dans tous les cas accès à tout, pouvez appliquer les modifications que vous souhaitez, activer et désactiver le chiffrement, peu importe.
Lorsque vous utilisez un système tiers en tant qu’utilisateur, vous n’avez aucun contrôle direct sur ce que les gens peuvent faire de vos données.
Dans tous les cas, je ne discute pas de la production, mon point était seulement de dire que cette fonctionnalité a également ses avantages en développement et qu’ils sont faciles à démontrer.
Donc, de mon point de vue, +1 pour cela. Je suis maintenant trop occupé pour argumenter davantage. Bonne journée.
Alors n’utilisez pas Google, Facebook, Microsoft et tous les autres puisque tous le font. Ils ne disent pas ouvertement qu’ils peuvent vous « usurper votre identité ». Ils peuvent faire tout ce que vous pouvez imaginer, mais vous leur faites toujours confiance et vous les utilisez toujours en sachant qu’ils peuvent tout faire, donc je ne sais pas quel est le vrai problème, mec. peut-être que vous êtes inquiet pour vos modérateurs et administrateurs de forum, mais toujours est-il que toutes les actions sont enregistrées si un administrateur utilise la fonctionnalité « usurper l’identité ». donc je ne parviens pas à comprendre où est le problème. si cette fonctionnalité était problématique, l’équipe de Discourse ne l’aurait pas mise en place en premier lieu.
Ce qui a bien sûr du mérite. Mais avoir cela disponible dans un environnement de production est risqué.
Il serait donc formidable, comme pour d’autres fonctionnalités, que cette fonction soit ajustée pour qu’elle doive être activée sur le serveur Root.
Je vois bien comment cela peut avoir de la valeur dans un environnement de développement, car les utilisateurs y sont probablement conscients qu’il s’agit d’un environnement de test.
J’ai déjà mentionné l’utilisation du chiffrement pour fermer cette fonction ouverte.
