C’est un sujet fascinant, qui semble découler en grande partie d’incompréhensions.
Cependant, il ne s’agit pas d’un problème de Discourse, ce problème imprègne tout système en ligne où il n’y a pas de chiffrement de bout en bout et de signatures numériques / validation des messages. Discourse n’a ni l’un ni l’autre par défaut.
Vous ne débattez pas vraiment ici non plus, et cela n’a pas vraiment de rapport avec les décisions prises par Discourse en tant que produit ou par l’équipe CDCK. Il y a des tonnes de idées fausses, vous apprenez simplement que le logiciel ne peut pas contrôler le niveau d’autorité ultime sur un système - quelque chose que beaucoup d’entre nous savent à des degrés divers depuis des décennies.
La réputation d’une communauté ne dépend pas des fonctionnalités de Discourse, elle dépend presque entièrement de qui vous confiez les clés. Si un administrateur malveillant fait quelque chose qui met la communauté en émoi, personne ne se souciera de la facilité avec laquelle il a pu commettre de tels actes, car en fin de compte, c’est vous et non un bouton particulier qui lui a donné le pouvoir de le faire.
Il semble plutôt que les gens soient devenus inconscients du pouvoir qu’a l’administrateur. L’usurpation d’identité n’est que la partie émergée de l’iceberg.
J’apprécie la façon dont vous avez formulé cela, car oui, pour moi, j’ai été assez choqué (et souvent assez effrayé) de découvrir l’étendue de mon pouvoir en tant qu’administrateur.
La raison pour laquelle j’ai souvent souhaité avoir le chiffrement de bout en bout est précisément celle-ci : réduire le pouvoir que j’ai en tant qu’administrateur et réduire la peur de ce qui pourrait arriver avec ce pouvoir (par exemple, la capacité de lire/modifier des messages, la responsabilité légale de devoir signaler ce que les gens disent dans les conversations privées, etc.)
Cependant, ce ne sont pas des problèmes que les logiciels libres et ouverts peuvent résoudre facilement, même ceux qui existent depuis une décennie.
À un moment donné, tout se résume à un équilibre entre le risque et la confiance entre les applications qui composent votre service, et les personnes qui détiennent les clés dudit royaume.
Être conscient du niveau d’accès que vous avez est en fait une bonne première étape.
Avez-vous de l’expérience avec les quantités massives d’ingénierie nécessaires pour que ces choses paraissent simples et conviviales ?
Elles ne sont pas omises en raison d’un simple oubli.
Assez pour savoir que j’ai un immense respect pour les ingénieurs de Signal et beaucoup de crainte à l’idée de créer ma propre cryptographie J’ai construit une application de journalisation cryptée en 2012/13 et il s’agissait d’un utilisateur qui se parlait à lui-même sur un seul appareil… et c’était quand même une galère, probablement pas très convivial, et je ne suis pas sûr de la sécurité.
Alors oui, je suis d’accord, une technologie de communication multi-utilisateurs simple, conviviale et sécurisée peut être extraordinairement difficile à créer et à maintenir. C’est peut-être pourquoi j’ai été si agréablement surpris que le plugin Discourse Encrypt existe.
Quoi qu’il en soit, vos commentaires me rappellent que oui, cette plateforme est gratuite et open-source, ce qui signifie que si l’équipe principale décide de ne pas faire quelque chose (par exemple, le cryptage du chat ou l’interdiction de l’usurpation d’identité) pour quelque raison que ce soit, je suis libre de créer moi-même un plugin ou de payer quelqu’un pour le faire — et cette liberté de le faire si je le souhaite est l’une des choses que j’aime tant chez Discourse.
IMHO, même les modérateurs ont beaucoup de pouvoir dans Discourse, mais je viens d’un environnement phpbb3 où les modérateurs avaient beaucoup moins de pouvoirs. (J’ai aussi géré un site Mailman pendant plus de 20 ans, que je migre vers Discourse dès que j’aurai trouvé comment déplacer 20 ans de messages vers Discourse.)
Je suis l’unique administrateur système de ce site phpbb3 depuis plus de 15 ans, même si j’ai pris ma retraite il y a plusieurs années ; j’ai hâte que cette plateforme migre vers Discourse car je suppose que quelqu’un d’autre sera l’administrateur et je ne souhaite même pas être modérateur là-bas, juste un participant. J’ai conseillé le chef de projet sur les problèmes d’administration de forum que nous avons rencontrés au fil des ans, certains d’entre eux pourraient avoir un impact sur les paramètres qu’il choisit d’utiliser, d’autres pourraient avoir un impact sur les politiques que cette organisation met en place pour les utilisateurs ainsi que pour le personnel.
Cela dit, avoir des restrictions sur qui peut utiliser le bouton d’impersonnification ne me semble pas une mauvaise idée, juste une idée largement symbolique une fois que l’on est un administrateur expérimenté. Et bien sûr, l’équipe de développement ou l’administrateur système (sur un système auto-hébergé) peuvent probablement tout faire s’ils font suffisamment d’efforts.
L’usurpation d’identité est un outil essentiel et répandu pour les administrateurs. Je travaille dans l’hébergement web et j’usurpe (“Me connecter en tant que”) les clients BEAUCOUP dans mon panneau de facturation. Il y a suffisamment de cas où une fonctionnalité comme celle-ci est cruciale, maintenant dans ce cas, les scénarios suivants peuvent se produire :
Vous aidez l’utilisateur et avez besoin de voir ce qui se passe de son côté.
Vous dépannez un bug qui ne se produit pas pour tous vos utilisateurs.
Vous avez besoin de voir le frontend du point de vue d’un utilisateur.
Vous testez l’expérience utilisateur/le flux.
Maintenant, Discourse n’est pas un panneau de facturation, mais les cas d’utilisation sont quelque peu similaires. Les administrateurs peuvent avoir besoin de dépanner un bug ou de voir à quoi ressemble le forum du point de vue d’un groupe ou d’un utilisateur spécifique. J’usurpe généralement mes propres comptes alternatifs qui font partie de groupes spécifiques ou qui ont un statut TL/mod/modérateur de catégorie spécifique, pour voir à quoi tout cela ressemble de leur côté et si je n’ai pas manqué de paramètres évidents.
Ou simplement aider l’utilisateur avec tout ce qui n’est pas possible sans usurper son identité - je ne suis pas sûr s’il existe des paramètres utilisateur auxquels on ne peut pas accéder sans usurper son identité ?
Outre le fait que tout administrateur root peut déjà accéder à toute information dans la base de données. C’est l’un des droits d’accès qu’un administrateur a par nature. La fonctionnalité d’usurpation d’identité est là pour faciliter la vie de l’administrateur, tout comme tout autre paramètre, ils sont là pour faciliter les tâches administratives : depuis l’interface /admin/.
Les seuls paramètres qui posent problème, je crois que vous pouvez les modifier en tant qu’administrateur, mais ils affichent vos paramètres au lieu de ceux de l’utilisateur à quelques endroits. Dans l’onglet Interface, il affiche vos paramètres de thème et de schéma de couleurs au lieu de ceux de l’utilisateur, vous devez donc usurper son identité pour être certain de voir les bonnes valeurs.
Cette question n’a-t-elle pas déjà reçu de réponse ?
Si vous remplacez « Supprimer le bouton d’impersonnification » par « Rendre le bouton d’impersonnification moins facilement accessible », la phrase conservera son sens, n’est-ce pas ?
Juste un rappel :
Serait-il possible que beaucoup de gens aient oublié la possibilité de désactiver complètement l’usurpation d’identité d’administrateur en installant simplement un petit plugin de moins de dix lignes de code ?
Peut-être que je pense que la fonction d’usurpation d’identité pourrait avoir un interrupteur dans les paramètres du site comme toutes les autres fonctions, tout comme le murmure, le marquage, la page utilisateur, le journal d’accès aux MP, etc.
Si cet interrupteur est dans les paramètres du site, alors n’importe quel administrateur peut le réactiver, donc un clic devient quelques clics. Je ne suis pas sûr que cela résolve le problème dans l’esprit de ceux qui considèrent cela comme un problème. Mais cela pourrait rendre moins tentant de l’utiliser pour fouiner.
Je pense qu’il serait formidable de pouvoir configurer quels administrateurs du site via la ligne de commande peuvent accéder à cette fonctionnalité. Car vous pourriez avoir des administrateurs qui ont besoin d’un accès élevé. Bien que l’idée simple de @jimkleiber d’utiliser CSS pour masquer le bouton à tous sauf X+ suffirait pour la plupart, car il s’agit seulement d’éliminer la tentation de le voir. Bien que le sérialiseur de plugin dans la même idée serait probablement meilleur, car imaginez que vous puissiez appuyer sur le bouton invisible (?)
En effet, dans ce cas, une option de ligne de commande root. Bien que la plupart le laisseraient s’il s’agit juste d’un problème de “tentation”.
Voici une PR pour un paramètre global afin de le désactiver. Je pense que c’est la bonne fidélité. C’est quelque chose que la personne qui installe et exécute le cluster veut définir à l’échelle du cluster.
Super PR ! Cependant, je trouve que la possibilité d’activer et de désactiver le paramètre d’usurpation est un peu trop facile à faire avec cette nouvelle fonctionnalité. Je pense que la plupart des utilisateurs seraient mal à l’aise de savoir que l’usurpation peut être activée et désactivée au gré d’un administrateur !
Peut-être devrions-nous envisager un paramètre supplémentaire qui permettrait d’activer ou de désactiver ce nouveau paramètre allow_impersonation. De cette façon, je ne serai pas si facilement tenté de régler le paramètre allow_impersonation sur « on ». Quelque chose comme un paramètre allow_allow_impersonation. Qu’en pensez-vous ?
Lorsque nous apportons notre soutien aux clients, il nous arrive occasionnellement qu’un administrateur se connecte à leur place dans des situations inhabituelles afin de s’assurer que le problème n’est pas lié au navigateur, au système d’exploitation ou à un bloqueur de publicités. Dans ces cas-là, c’est très utile et discret : ils n’agissent pas en leur nom et n’ont accès à rien qu’ils ne pourraient pas voir de toute façon.
Je vois beaucoup de confusion entre le technique et le social. La vision technique est que l’usurpation d’identité est utile et que la désactiver n’empêche pas suffisamment. La vision sociale est que l’usurpation d’identité est trop facile à utiliser et que, dans la culture de certains forums, elle viole le contrat social.
Noter que l’usurpation d’identité est utile, voire essentielle, ne dit rien de son utilité sociale ou de son message. Et ainsi, nous avons des gens qui se parlent sans se comprendre - en particulier peut-être de la part de ceux qui n’ont pas l’habitude de penser en termes d’attentes sociales dans différentes cultures.
Merci pour le commutateur global. (Je pense toujours qu’un avertissement interstitial serait une amélioration !)
Ou il devrait être dans la console pour autoriser ce paramètre. Ou il devrait être dans le code source pour l’autoriser. Ou quelques avertissements ? Quoi qu’il en soit, la tentation est toujours là, que faire
J’ai construit une application de journalisation cryptée en 2012/13 et il s’agissait d’un utilisateur qui se parlait à lui-même sur un seul appareil… et c’était quand même une galère, probablement pas très convivial, et je ne suis pas sûr de la sécurité.
)