Este es un tema fascinante, que parece deberse en gran medida a malentendidos.
Sin embargo, esto no es un problema de Discourse, este problema impregna cualquier sistema en línea donde no haya cifrado de extremo a extremo y firmas digitales / validación en los mensajes. Discourse no tiene ninguna de esas cosas listas para usar.
En realidad, tampoco estás debatiendo aquí, ni esto se relaciona realmente con ninguna decisión tomada por Discourse como producto o por el equipo de CDCK. Hay toneladas de ideas erróneas, simplemente estás aprendiendo que el software no puede controlar el nivel máximo de autoridad en un sistema, algo que muchos de nosotros hemos sabido en diversos grados durante décadas.
La reputación de una comunidad no depende de las características de Discourse, sino casi por completo de a quién le entregas las llaves. Si un administrador malintencionado hace algo que provoca un alboroto en la comunidad, a nadie le importará lo fácil que fue para él cometer dichos actos porque, en última instancia, fuiste tú y no un botón en particular quien le dio el poder de hacerlo.
Suena más como si la gente se hubiera vuelto ajena al poder que tiene el administrador. Suplantar identidades es solo la punta del iceberg.
Agradezco cómo has planteado esto, ya que sí, para mí, me ha sorprendido bastante (y a menudo bastante asustado) descubrir cuánta autoridad tengo como administrador.
Por qué a menudo he deseado tener cifrado de extremo a extremo es precisamente eso: para reducir el poder que tengo como administrador y reducir el miedo a lo que podría suceder con ese poder (por ejemplo, la capacidad de leer/cambiar mensajes, la responsabilidad legal de tener que informar sobre lo que la gente dice en las conversaciones privadas, etc.).
Sin embargo, estos no son problemas que el software libre y de código abierto pueda resolver fácilmente, ni siquiera el que existe desde hace una década.
En algún momento, todo se reduce a un equilibrio de riesgo y confianza entre las aplicaciones que componen su servicio y las personas que tienen las llaves de dicho reino.
Ser consciente del nivel de acceso que tiene es, de hecho, un buen primer paso.
¿Tiene alguna experiencia con la enorme cantidad de ingeniería necesaria para que esas cosas parezcan simples y fáciles de usar?
Suficiente para saber que tengo un gran respeto por los ingenieros de Signal y mucho miedo de implementar mi propia criptografía Construí una aplicación de diario cifrado en 2012/13 y eso era un usuario hablando consigo mismo en un solo dispositivo… y todavía fue un dolor, probablemente no muy fácil de usar, y no estoy seguro de qué tan seguro.
Así que, sí, estoy de acuerdo, la tecnología de comunicación multiusuario simple, fácil de usar y segura puede ser extraordinariamente difícil de crear y mantener. Quizás por eso me sorprendió gratamente que existiera el plugin Discourse Encrypt.
En cualquier caso, tus comentarios me recuerdan que sí, esta plataforma es gratuita y de código abierto, lo que significa que si el equipo principal decide no hacer algo (por ejemplo, cifrado de chat o prohibición de suplantación de identidad) por la razón que sea, soy libre de crear un plugin yo mismo o pagarle a alguien para que lo cree, y esa libertad de hacerlo si quiero es una de las cosas que tanto me encantan de Discourse.
En mi humilde opinión, incluso los moderadores tienen mucho poder en Discourse, pero vengo de un entorno phpbb3 donde los moderadores tenían muchos menos poderes. (También he administrado un sitio de Mailman durante más de 20 años, que estoy migrando a Discourse tan pronto como pueda averiguar cómo mover 20 años de mensajes a Discourse).
He sido el único administrador de sistemas de ese sitio phpbb3 durante más de 15 años, aunque me jubilé hace varios años; de hecho, espero con ansias que esa plataforma se traslade a Discourse porque asumo que otra persona será la administradora y realmente no quiero ser ni siquiera un moderador allí, solo un participante. He estado asesorando al líder del proyecto sobre problemas de administración de foros que hemos enfrentado a lo largo de los años, algunos de ellos pueden afectar la configuración que él elija usar, otros pueden afectar las políticas que la organización implemente para usuarios y personal.
Dicho esto, tener restricciones para quienes pueden usar el botón de suplantación no me parece una mala idea, solo una que es en gran medida simbólica una vez que se es un administrador experimentado. Y, por supuesto, el equipo de desarrollo o el administrador del sistema (en un sistema autoalojado) probablemente puedan hacer cualquier cosa si se esfuerzan lo suficiente.
Suplantar la identidad es una herramienta esencial y generalizada para los administradores. Trabajo en el sector de la web y suplanté la identidad (“Iniciar sesión como”) de clientes MUCHO en mi panel de facturación. Hay suficientes casos en los que una función como esta es crucial, y en este caso pueden ocurrir los siguientes escenarios:
Estás ayudando al usuario y necesitas ver qué está sucediendo en su lado.
Estás solucionando un error que no ocurre para todos tus usuarios.
Necesitas ver el frontend desde la perspectiva de un usuario.
Estás probando la experiencia/flujo del usuario.
Ahora bien, Discourse no es un panel de facturación, pero los casos de uso son algo similares. Los administradores pueden necesitar solucionar un error o ver cómo se ve el foro desde un grupo o usuario específico. Normalmente, suplanté la identidad de mis propias cuentas alternativas que pertenecen a grupos específicos o tienen un estado específico de TL/mod/mod de categoría, para ver cómo se ve todo desde su lado y si me he perdido alguna configuración obvia.
O simplemente ayudar al usuario con cualquier cosa que no sea posible sin suplantar la identidad: ¿no estoy seguro de si hay configuraciones de usuario a las que no se pueda acceder sin suplantar la identidad?
Aparte del hecho de que cualquier administrador raíz ya puede acceder a cualquier información en la base de datos. Este es uno de los derechos de acceso que tiene un administrador por naturaleza. La función de suplantación de identidad está ahí para facilitar la vida del administrador, al igual que cualquier otra configuración, están ahí para facilitar las tareas administrativas: desde la interfaz de /admin/.
La única configuración que sé que es un problema, creo que puedes cambiarla como administrador, pero muestra tu configuración en lugar de la suya en algunos lugares. En la pestaña Interfaz, muestra tu tema y la configuración del esquema de colores en lugar de los del usuario, por lo que tienes que suplantar su identidad para asegurarte de que estás viendo los valores correctos.
Si reemplazas “Quitar el botón de suplantación” con “Hacer que el botón de suplantación sea menos accesible”, la oración mantendrá su significado, ¿no?
Solo quiero recordar:
¿Podría ser que muchas personas hayan olvidado la posibilidad de deshabilitar completamente la suplantación de administrador simplemente instalando un pequeño plugin de menos de diez líneas de código?
Quizás creo que la función de suplantación puede tener un interruptor en la configuración del sitio como todas las demás funciones, al igual que susurrar, etiquetar, página de usuario, registro de acceso a mensajes privados, etc.
Si ese interruptor está en la configuración del sitio, entonces cualquier administrador puede volver a activarlo, por lo que ahora un clic se convierte en unos pocos clics. No estoy seguro de que eso resuelva el problema en la mente de quienes consideran que esto es un problema. Pero podría hacer que sea menos tentador usarlo para husmear.
Creo que en esto sería genial poder configurar qué administrador(es) en el sitio a través de la línea de comandos pueden acceder a esta función. Ya que puede tener administradores que necesiten acceso elevado. Aunque la simple idea de @jimkleiber de usar CSS para ocultar el botón a todos excepto a X+ sería suficiente para la mayoría, ya que solo se trata de eliminar la tentación de que se vea. Aunque el serializador de complementos con la misma idea probablemente sería mejor, ya que imagina que podrías presionar el botón invisible (?).
De hecho, en ese caso, una opción de línea de comandos raíz. Aunque la mayoría lo dejaría si es solo un problema de “tentación”.
Aquí hay una PR a una configuración global para deshabilitarla. Creo que esta es la fidelidad correcta. Es algo que la persona que instala y ejecuta el clúster quiere establecer a nivel de clúster.
¡Gran PR! Sin embargo, creo que la capacidad de activar y desactivar la configuración de suplantación es demasiado fácil de hacer con esta nueva función. ¡Creo que la mayoría de los usuarios se sentirían incómodos al saber que la suplantación se puede activar y desactivar a voluntad de un administrador!
Quizás deberíamos considerar una configuración adicional que permita activar o desactivar esta nueva configuración allow_impersonation. De esa manera, no me tentaré tan fácilmente a establecer la configuración allow_impersonation en “on”. Algo como una configuración allow_allow_impersonation. ¿Qué opinas?
Cuando damos soporte a clientes, ocasionalmente hacemos que un administrador se haga pasar por ellos en situaciones extrañas para asegurar que el problema no esté relacionado con el navegador/sistema operativo/bloqueador de anuncios. En esos casos, es muy útil y discreto: no publican en su nombre ni tienen acceso a nada que no pudieran ver de todos modos.
Veo mucha confusión entre lo técnico y lo social. La visión técnica es que la suplantación de identidad es útil y desactivarla no previene lo suficiente. La visión social es que la suplantación de identidad es demasiado fácil de usar y, en la cultura de algunos foros, viola el contrato social.
Señalar que la suplantación de identidad es útil, o incluso esencial, no dice nada sobre su utilidad social o el mensaje que transmite. Y así tenemos gente que habla sin entenderse, especialmente quizás aquellos que no están acostumbrados a pensar en términos de expectativas sociales en diferentes culturas.
Gracias por el interruptor global. (¡Todavía creo que una advertencia intermedia sería una mejora!)
O debería estar en la consola para permitir esta configuración. O debería estar en el código fuente para permitirlo. ¿O algunas advertencias? De todos modos, la tentación sigue ahí, ¿qué hacer?
Construí una aplicación de diario cifrado en 2012/13 y eso era un usuario hablando consigo mismo en un solo dispositivo… y todavía fue un dolor, probablemente no muy fácil de usar, y no estoy seguro de qué tan seguro.
)