Cela pourrait être social et/ou culturel et j’essaie de partager mes réflexions - sans juger personne - à cause de cela.
Certaines personnes vivent dans des pays qui sont résistants aux changements et entièrement censurés (donc elles pourraient normaliser des choses qui attaquent directement la liberté de différentes perspectives ou cultures).
Mais Discourse veut être la plateforme de forum de premier plan dans le monde et je pense que discuter de ce genre de sujets est toujours une bonne chose pour tout le monde.
Merci pour cet espace. J’espère qu’il pourra être révisé pour ne pas nuire aux cas d’utilisation, mais aussi à la confiance que les utilisateurs et les communautés accordent à Discourse
Nous parlons de prévenir des utilisations potentiellement très néfastes dans les grandes communautés et de ne pas nuire à la confiance que les utilisateurs accordent à Discourse.
Nous ne parlons pas de forums aveugles ou d’empêcher les administrateurs d’avoir les données car c’est impossible à partir de la base centralisée qui utilise une seule base de données.
Je pense que cette question s’inscrit très bien dans un débat « OUI mais » et non dans un débat « OUI ou NON ».
Désolé, mais ce n’est pas le but de mon sujet. Vous pouvez en ouvrir un autre et demander ce que vous voulez.
Supprimer l’usurpation d’identité n’empêche pas cela, c’est tout aussi facile sans elle. L’effet principal de la suppression de l’usurpation d’identité serait de rendre plus difficile le dépannage des problèmes spécifiques au compte.
Vous devriez lancer une démo et essayer certaines des fonctionnalités d’administration, vous n’avez pas besoin d’accéder à la base de données ou d’usurper l’identité de quelqu’un pour modifier ses propos ou lire ses messages.
Que cela prenne une seule pression du doigt ou une douzaine, cela fait peu de différence, c’est toujours possible. Je connais quelqu’un qui travaille fréquemment à domicile et qui doit passer par une demi-douzaine de mots de passe, des identifiants à deux facteurs et d’autres formalités pour accéder aux systèmes internes de son entreprise, mais cela ne lui prend que quelques minutes.
Soit vous et vos utilisateurs faites confiance aux développeurs et aux administrateurs, soit vous n’en faites pas. Et si vous n’avez pas confiance dans le système, votre façon de l’utiliser changera probablement.
De mon point de vue, cela valide probablement que Discourse tient compte de la vie privée et de la liberté.
La gestion manuelle d’une base de données convient à un développeur. Un simple bouton pour que chaque administrateur puisse usurper l’identité est inutile et ne convient pas.
Au milieu, il peut y avoir un système simple qui montre de manière transparente que l’usurpation d’identité a été utilisée ou quelque chose de similaire.
Je veux dire, vous pouvez réfléchir à des options ou réduire l’ensemble à votre propre perspective.
Vous devez revenir en arrière et lire mes derniers messages avant de répondre à nouveau. Les administrateurs peuvent toujours faire tout cela sans usurper d’identité ni accéder à la base de données. L’usurpation d’identité et la plupart des actions administratives sont déjà enregistrées dans le cas où un autre administrateur aurait besoin d’une piste pour trouver un administrateur malveillant.
Ou simplement fermez cette fonction ouverte avec le plugin Encrypt. En fin de compte, avoir des options sur les fonctions que les gens pourraient trouver problématiques est une bonne chose. Fausse idée de sécurité, de sûreté, etc. Le seul système sécurisé pour citer Adama est un terminal hors ligne qui n’est pas connecté à d’autres systèmes.
Tous les arguments pour et contre ont un point de vue valable. Le compromis est la meilleure solution pour toutes les parties. Le plugin Encrypt a été développé pour satisfaire le désir et, dans certains endroits, peut-être l’exigence d’avoir une couche de confidentialité pour le sous-système PM/DM.
Peut-être que s’il n’est pas intégré au noyau comme option, un plugin qui accomplit l’effet désiré pour les systèmes auto-hébergés qui veulent la tranquillité d’esprit.
On pourrait dire que le script pour créer des badges personnalisés n’a pas besoin d’être désactivé car seul l’administrateur y a un accès direct. Cependant, cela doit être activé depuis Root, à moins que cela n’ait changé.
Je suis d’accord, dans des circonstances idéales, les gens devraient pouvoir faire confiance aux personnes en position. Malheureusement, la confiance est parfois mal placée et n’est découverte qu’après coup.
C’est une mesure de performance, pour s’assurer que les clients hébergés dans un environnement partagé ne peuvent pas mettre à genoux les sites les uns des autres. Cela permet de distinguer l’administrateur du serveur et l’administrateur du forum.
Cliquer une fois ou une douzaine de fois semble similaire mais ne l’est pas et à cause de cela, de nombreuses entreprises perdent beaucoup d’argent en n’activant pas un simple bouton disant ‘Désabonnez-moi’.
Nous parlons probablement du contraire mais du point de vue moral et éthique.
J’utilise Discourse en tant qu’administrateur depuis 4 ans et je sais de quoi vous parlez (cas totalement différents de l’usurpation d’identité d’utilisateurs).
Ce que vous avez dit n’active pas la possibilité de publier comme un autre en un seul clic. C’est comme utiliser une IP ou un ID tiers et c’est différent de la modification de leurs publications pour la modération.
Au fait, j’espère que le chiffrement s’arrêtera et brisera la possibilité de lire les MP des utilisateurs, mais c’est pour un autre fil de discussion et j’attends des mises à jour pour tester
Je cite à nouveau car il semble que vous ayez ajouté le mode lent…
J’ai réfléchi à l’idée de quelques exemples pratiques de « changement de propriétaire » et/ou « modifier votre message et masquer la révision » pour démontrer que c’est principalement un argument sans fondement quant à la méthode utilisée pour faire croire que vous avez dit quelque chose que vous n’avez pas dit sans toucher au bouton d’usurpation d’identité, mais j’ai décidé de ne pas le faire.
Mais il y a certainement plus d’une façon d’être un parfait connard avec tous les boutons magiques que j’ai juste dans l’interface utilisateur, sans parler de jouer avec la console Rails. Je pense que beaucoup repose sur la confiance de la communauté, pas seulement sur l’administrateur, car bon nombre de ces fonctionnalités sont également disponibles au niveau TL4/catmod/mod. Je pense qu’en général, le groupe « staff » ne fait pas d’efforts particuliers pour être destructeur avec l’un de ces outils, car ce serait un acte d’auto-sabotage envers leur propre communauté.
Par conséquent, je ne comprends pas pourquoi la fonctionnalité d’usurpation d’identité elle-même est considérée comme contraire à l’éthique ?
Sérieusement, tous ces commentaires qui prétendent une mauvaise utilisation et d’autres choses n’ont aucun sens pour moi, il n’y a aucun intérêt à désactiver cette fonctionnalité particulière. Un administrateur peut toujours tout faire comme d’autres l’ont souligné.
Mais alors, vous n’écoutez toujours pas les autres et vous voulez faire une montagne d’une souris. Je ne comprends toujours pas quel est le véritable problème. Allez-vous perdre vos utilisateurs ? Ou avez-vous peur que votre autre administrateur utilise cette fonctionnalité contre vous ? Si c’est le cas, alors vous ne devriez pas nommer des administrateurs en qui vous n’avez pas confiance, tout simplement.
Je serai parfaitement honnête Richard, vous et @merefield avez des scénarios d’utilisation positifs très valables. Mais je pense que vous ne voyez tous les deux que la façon dont la modification des éléments avec des paramètres optionnels pourrait entraver vos flux de travail. Ce qui ne changerait vraiment rien, car si vous fournissez l’hébergement, la fonctionnalité ne changerait pour aucun de vous deux.
Sauf par exemple si je postais un problème pour lequel j’avais besoin d’aide avec des accords de compensation monétaire ou pro bono. Vous ou Robert ou quiconque offre de l’aide pouvez présenter les outils nécessaires à partir d’un Discourse auto-hébergé.
c.-à-d. “Dan, je peux vous aider pour X $ à résoudre votre problème. J’aurai besoin de ce qui suit. Pour créer un compte sur votre site et accorder l’accès administrateur, j’aurai également besoin d’accéder à la fonction d’impersonation (avec une liste d’utilisateurs autorisés à utiliser la fonction afin que je puisse diagnostiquer et résoudre le problème de manière appropriée et efficace. Si vous avez désactivé l’impersonation, vous devrez demander à votre administrateur racine de l’activer. Si vous acceptez mes conditions, nous pouvons commencer ce processus.”
J’automatiserais cela, donc je ne m’en inquiète pas du tout (en fait, j’ai un script shell qui prend le nom d’hôte et le nom d’utilisateur d’une installation Discourse hébergée par nous comme argument, et il me donne un lien de connexion (y compris l’authentification à deux facteurs et la connexion).
J’ai déjà expliqué mes objections il y a plus de deux heures (mais je les répéterai volontiers pour éviter toute confusion supplémentaire sur mes motivations)
Dans ma meilleure tentative pour résumer manuellement ce que je lis avec GPT-4 :
Certains souhaitent une friction plus élevée pour usurper l’identité
Certains souhaitent le niveau actuel de faible friction pour usurper l’identité
Pour ceux qui souhaitent un peu plus de friction (je suis de ce camp, car personnellement, je ne veux pas être tenté de cliquer sur le bouton, similaire à Screen Time et à d’autres astuces sur iOS pour m’aider à éviter la tentation) :
Ajoutez un composant de thème très simple à votre site avec le CSS suivant :
.btn-impersonate {
display: none;
}
Peut-être souhaitez-vous encore plus de friction que cela, et peut-être que quelqu’un pourrait créer un plugin ou un composant de thème plus avancé pour le faire, mais je veux essayer cela et voir si cela me procure suffisamment de friction pour éviter toute tentation indésirable.
Pour moi, c’est le point principal. Les administrateurs peuvent toujours « usurper l’identité » des utilisateurs avec les autres outils disponibles, littéralement à quelques clics.
Mais en fin de compte, Discourse est un projet open-source avec un système de plugins, vous pouvez toujours faire en sorte que les choses fonctionnent comme vous le pensez pour votre propre communauté.
Si vous voulez un plugin, je commencerais par un qui surcharge Guardian.can_impersonate?, il est utilisé par le sérialiseur qui détermine la présence du bouton « Usurper l’identité » ainsi que par les vérifications backend. Au moins d’après un test rapide sur mon instance de développement, cela a fonctionné :
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
… Je ne savais pas qu’il était si facile de cliquer sur la liste complète des messages de n’importe quel utilisateur depuis son profil…
Oui, une autre raison pour laquelle j’aime Discourse Encrypt et j’aimerais qu’il soit étendu aux conversations personnelles/privées également.
Cependant, il ne semble pas aussi facile pour moi, en tant qu’administrateur, de voir les conversations personnelles d’un utilisateur, mais est-ce le cas ?
